Both directions
Inbound. The platform exposes an MCP endpoint, so an external client - Claude Desktop, Cursor, a custom agent - can reach it. Over eighty registered tools in thirteen groups:
| Group | What an external client can do |
|---|---|
| Query engine | List data models, run a query, read a schema |
| Datasets | List datasets, read one, read its scan results, trigger a re-scan |
| Applications | Read and author application artifacts |
| Scanning | Run and inspect the dataset scan pipeline |
| Memory | Read and write per-user memory |
| Knowledge | Search the knowledge base, with optional reranking |
| Exploration | Analyse the table currently open |
| Skills | Author, publish and review catalogue skills |
| Pages | Read and author pages and widgets |
| Processes | Get a task, its status, a readable summary of what is outstanding |
| Ledger | Read a balance |
| Spreadsheets | Read rows |
| Dashboards | Create a dashboard |
Every one of them declares a risk classification; a completeness test covers all 123 tool names offerable in chat, so a new tool cannot ship unclassified. See The invocation contour.
Outbound. The platform is also an MCP client, which is what an installed proxy skill dispatches through. See Skills.
The same operation is reachable from in-product chat, from a durable workflow and from an external client, because these are one registry with adapters, not three implementations.
The connector bridge
Orchestration owns a registry of roughly eighty-five typed connector operations against processes, the ledger, spreadsheets and external systems. Selected operations are bridged natively into the tool plane: the bridge invokes the connector directly instead of wrapping a workflow around it.
The first six bridged this way are bpm.get_task, bpm.get_task_status, bpm.get_tasks_text,
ledger.balance, workbook.read_rows and dashboard.create - each with a matching agent-tool
skill alias, so the same operation is one entry in the tool plane, one entry in the skill catalogue,
and one implementation.
That collapses what would otherwise be three separate answers to "what can an agent do" - tool registry, skill registry, connector registry - into one surface.
Authority is per caller
Bridging an operation does not widen who may call it.
- Process reads execute under the calling employee's own actor-scoped token, not a tenant service identity. The token is resolved lazily, so the cost is paid only on a call that needs it.
- Balance lookups are self-only for non-administrators.
- Dashboard creation is administrator-only.
- Spreadsheet reads are organisation-scoped, matching the sharing grain of a collaborative sheet.
Underneath, the platform's access control applies unchanged: row policies and column masks compiled into the query plan by the engine, identically for an agent and a person.
Tool scope per agent
An agent receives a filtered tool list, not the catalogue. Domain personas are scoped away from namespaces that are not theirs - a sales or HR persona does not hold platform-authoring tools - and several personas carry a curated list instead of the domain-filtered registry scope. The resolved-config endpoint marks which of the two a given agent uses.
Progressive disclosure
Declared tools are tokens in every request, and a long tool list degrades selection accuracy.
A small core set is activated per session. The rest is discovered on demand through a search tool whose result count is clamped, so a single request cannot pull the catalogue into context. Tool schemas stay a roughly fixed slice of a turn as the catalogue grows - see the token profile in Models and providers.
Agent-to-agent
Two distinct mechanisms:
- Consult - the pinned agent asks another persona a focused sub-question and receives an answer without ceding the conversation. The consulted call runs with no tools and no conversation history: persona-prompt synthesis only.
- Handoff - the rest of the conversation is reassigned to another persona, persisted, effective from the next turn.