MCP integration
Expose capabilities without losing your architecture
Model Context Protocol is most useful when it is treated as a deliberate integration boundary. It lets outside agents discover and use capabilities from your application, but the real design work still lives inside your core libraries, loop orchestration, and execution policy.
How MCP fits into the stack
Protocol boundary
MCP is a clean way to expose selected capabilities from your app to external agents, editors, or runtimes without collapsing your internal architecture into one monolith.
Loop integration
MCP should sit beside the agentic loop as one transport and capability surface, not replace the internal orchestration model that actually runs work.
Tool exposure
Only expose tools, resources, and prompts that make sense as a durable public boundary. Keep internal-only helpers behind the host application.
Policy and trust
Treat approvals, permissions, rate limits, and execution policy as first-class concerns when turning internal capabilities into protocol-visible tools.
A good mental model
Think of MCP as the doorway, not the building. The doorway should expose a coherent set of tools and resources, but the building behind it still needs clear ownership: core libraries for reusable capabilities, orchestration for loop execution, and policy layers for safe action.
external agent -> MCP client/server boundary -> curated tools + resources -> policy / approvals -> internal loop + core libraries -> simulator or hardware-backed execution
Important constraint
Do not expose every internal capability just because the protocol allows it. Public protocol surfaces should stay smaller, safer, and more stable than internal APIs.
Suggested implementation sequence
- Choose the host boundary: desktop app, backend service, or dedicated bridge process.
- Define the small set of tools and resources external agents genuinely need.
- Map each protocol-visible tool to an internal library capability with explicit policy checks.
- Return structured results that are useful to both agents and human operators.
- Test the protocol layer against simulator-backed workflows before assuming hardware is present.
Good MCP use cases here
- • Expose curated gesture or haptic capabilities to external coding agents.
- • Allow editor-hosted agents to inspect application context and trigger safe actions.
- • Bridge a simulator or device runtime into a broader agent ecosystem.
- • Publish resources that describe state, session context, or available interaction modes.
Documentation rule for MCP
Use portal docs to explain how the protocol fits into the architecture and when to use it. Use inline Rustdoc to document the exact crates, traits, handlers, and resource types behind the implementation. That keeps the protocol story understandable while keeping API truth close to the code.