MCP governance
The MCP (Model Context Protocol) governance layer is the only channel between the Agent and the platform: the Agent neither calls backend functions directly nor runs arbitrary shell — it reaches platform capabilities exclusively through MCP tools.
Core idea
Platform capabilities are exposed as MCP tools — with explicit permission scopes, confirmation gates, schema validation, and result-size controls. The Agent can act, but never runs unchecked.
Three-tier permission model
The MCP server statically expands to 56 tools, tiered into read / write / file:
| Tier | Scope | Typical tools | Confirmation |
|---|---|---|---|
| L1 read-only (53 tools) | read | tool schemas database search gene ID mapping motif-to-TF task logs result manifests checkpoint decision-card diagnostics | no |
| L2 controlled write (7 tools) | write | submitting platform actions enrichment & plotting batch jobs | yes (in-conversation confirmation) |
| Workspace file (1 tool) | file | R script updates and similar | session scope |
The static registration count is a catalog figure, not a per-session contract: tool visibility is determined dynamically by session permissions and should be taken from the session’s tools/list (historical observations: 65 tools visible in write sessions, 56 in read sessions).
* Static catalog count as of 2026-10-16, not successful-run count.
Governance mechanisms
| Mechanism | What it does | What you notice |
|---|---|---|
| Schema validation | Validates parameters against the tool schema before every call | The Agent is blocked from submitting malformed parameters — broken calls never run |
| Write confirmation gate | L2 calls require user consent first; workspace file calls follow session scope | A confirmation request appears in the conversation; nothing is submitted until you click confirm |
| Result Store pagination | Large results move to external storage and are returned as paginated references | Big tables never blow up the conversation context; the Agent reads page by page |
| Full audit | Records user, permission scope, confirmation state, and audit metadata | Every tool call is reviewable after the fact, satisfying traceability requirements |
| Checkpoint decision-card diagnostics | An L1 read-only tool reads task decision-card snapshots | Stage-level decision context of multi-stage tasks can be reviewed for diagnosis |
The path of a single call
Agent request
→ MCP session context (bound to user/session/scope)
→ tool visibility filtered by permissions
→ schema validation
→ write → confirmation gate; workspace file → session scope
→ handler execution
→ oversized result → Result Store pagination
→ audit record
Audit records are stored on the backend and can be inspected in task details and logs.
Dual-channel access
The platform exposes two equivalent channels for MCP clients:
- compat channel:
/api/mcp/*, the legacy compatibility transport; - official channel:
/api/mcp-official/*, the official MCP protocol transport.
Both expose the same governed tool set — pick whichever your client supports. The Agent built into the workbench is pre-configured; no manual wiring needed.
Security model
- The Agent never executes arbitrary shell commands — all platform access flows through governed MCP tools;
- LLM-assisted anomaly findings are advisory only; nothing is auto-blocked or auto-approved without evidence;
- Tool visibility follows the permission scope — read-only sessions can only reach L1 tools.
Next steps
- Agent-assisted mode: what confirmation gates feel like in real conversations.
- Databases & regulatory resources: the data resources behind L1 search tools.