The MCP Plane Is Bilateral

Consuming: any MCP server becomes an agent tool by name

Agentis has always been able to reach an external MCP server over REST, but that alone doesn't put its tools in front of an agent's own reasoning loop. McpToolBridge closes that gap: it resolves the MCP servers registered to a workspace, lists and caches their tools, and offers each one to the agent loop and chat orchestrator by a namespaced id — mcp__<serverSlug>__<toolName> — so a bridged tool can never collide with a built-in platform tool and is always obviously external in logs. A server tagged as granting a specific RAL affordance (a computer-use MCP server, for instance) extends what an agent can actually do, not just what it can call.

Publishing the platform uses progressive disclosure

An external harness does not need the entire internal registry in its prompt. Agentis advertises at most six gateway operations: agentis.orient, agentis.tools.search, agentis.tools.describe, agentis.tools.call, agentis.code.execute, and agentis.task.status. The agent discovers only the contract it needs, then calls it through the same typed registry. Legacy names remain directly callable for compatibility.

Ask, Plan, and Auto policy remains enforced at the registry boundary, including mutations nested inside code execution. Inner calls retain attribution and advance the lease-state frontier, so compact MCP exposure does not create a policy bypass. Results are capped at 12,000 characters by default; explicit full or graph detail is available when the caller genuinely needs it.

Publishing: your workflows are someone else's MCP tools

The other direction: Agentis publishes its own workflows as JSON-RPC 2.0 Streamable-HTTP tools any external MCP client can call — mount once, and a published workflow projects simultaneously as a deterministic workflow node and a live agent tool. "Bilateral" isn't a marketing word here; it's the literal shape of the plane.

Continue