MCP (Model Context Protocol)

Model Context Protocol shows up in the Miqro platform in two distinct directions. Keeping them separate is the key to understanding what's live, what's gated, and what's on the roadmap.

Direction 1 — Miqro as an MCP client (the one you want)

The platform already acts on ~21 external systems (Stripe, Gmail, Slack, HubSpot, Jira, ServiceNow, and more) through typed connectors. MCP generalizes that: instead of hand-writing a connector per provider, an agent can drive any MCP-exposed system through a single, self-hosted MCP client — your own control planes, internal tools, SaaS MCP endpoints, and coding sources.

We host the MCP client ourselves rather than delegating to a model provider's managed MCP connector. That is a deliberate safety decision: hosting it in-process is what lets every write still pass through Miqro's approval gate and audit log. See Agentic control via MCP for the full model — the tool-calling loop, the read/write split, and the approval guarantee.

This capability is gated to the Enterprise / miqromanage plan. Run unlocks the agent fleet; autonomous MCP control is a higher tier.

Direction 2 — Miqro as an MCP server (roadmap)

The natural future is to expose the connector capability surface as an MCP server, so an external AI client could discover and call Miqro tools over a standard protocol. Because capabilities are already declared in a typed manifest with risk levels and approval gates, the manifest → MCP mapping is largely mechanical:

• each connector's data_ops → MCP read tools,
• each connector's action_ops → MCP action tools, with the approval gate preserved,
• the catalog → MCP tool discovery.

When that ships it will be documented here with connection details and auth. Until then, integrate via the HTTP API and the connector catalog.

MCP in our own tooling (unrelated to the product)

Separately, we use MCP internally as developer tooling — wiring our own editor/agent environment to our docs vault, database, and infrastructure. That's a build-time convenience for the team; it is not a product surface and nothing in production depends on it.

The CLI is the other face

MCP is the agent entry to the platform's capability core; the miqro CLI is the human/scriptable entry to the same core. Both run on one shared command surface — the same connectors, the same approval gate — so miqro queue approve <id> operates the very queue an agent's MCP writes flow into. Build and learn them together.

Next

• Agentic control via MCP — how an agent drives systems through MCP without ever making an unapproved write.
• Coding sources — the first high-value MCP targets: GitHub and coding-tool servers.
• The miqro CLI — the human/CI twin of this surface.