🔒 Enterprise / miqromanage plan only. Run unlocks the agent fleet (departments, approvals). Autonomous control of external systems through MCP is a higher gate. This page describes the design; the capability is being built.
This page explains how a Miqro agent can read context and control systems through Model Context Protocol — using our own models — without ever performing an unapproved action on your tools.
Miqro has a single, load-bearing safety property:
An agent is a text producer. Nothing it decides reaches your systems until an action is approved and executed through the action queue.
Today, agents propose; a human (or a policy) approves; only then does the platform act. Agentic MCP control keeps that guarantee intact even when the agent is calling tools live, mid-reasoning. The mechanism is below.
An MCP server publishes a set of tools (a tool is a named capability with a typed
input — search_issues, create_ticket, read_file, open_pull_request, …). With a
self-hosted MCP client, a Miqro agent can:
Because Miqro hosts the MCP client itself, the agent's tool calls run inside our process, where we can apply the approval gate to every write. (We deliberately do not hand MCP brokering to a model provider's managed connector, which would move writes outside our control.)
Every tool an agent can call is classified as read or write, and the two are handled completely differently:
| Tool type | Example | What happens |
|---|---|---|
| Read | list_incidents, search_repo, read_file |
Runs immediately. The agent gets live data and keeps reasoning. No approval needed — reads have no side effect. |
| Write | create_incident, open_pull_request, send_message |
Not executed inline. The call is staged as an approval item in the action queue and the agent is told it's pending. The real action only happens after approval, through the same executor, audit log, and retry machinery every Miqro action already uses. |
So a "write tool" is a first-class thing the agent can call — but calling it means stage it for approval, not do it. This is what preserves the one rule above, even in a live tool-calling loop.
For an MCP server's tools, Miqro treats a tool as a safe read only if the server explicitly declares it read-only. Anything else is treated as a write and routed through approval. A server cannot label a destructive tool "safe" and have it auto-execute — the absence of a clear read-only signal already means "require approval."
agent turn ─▶ model decides to call tools
│ read: list_incidents(...) ─▶ run now, return live data
│ write: create_incident(...) ─▶ stage for approval, return "pending"
▼
model sees the reads + that the write is pending, keeps reasoning
│
▼
finishes with a summary + the list of staged actions awaiting approval
The agent can chain reads freely (search → fetch → decide), stage one or more writes, and explain exactly what it has queued — all in one turn, with zero ability to act on your systems unapproved.
MCP servers are registered by the account owner and allowlisted — an agent cannot point itself at an arbitrary endpoint. Registration validates the server, lists its tools, and arms them for the agent fleet, exactly like connecting a connector today. Low-risk write tools can optionally be put on a per-account auto-approve list, but even those are recorded in the audit log; everything else waits for a human.
This is the same model as connectors, generalized. Connectors are typed, hand-written REST integrations with a declared capability manifest; MCP control reaches any MCP-exposed system and reuses the same risk classification and the same approval gate. If a system already has a Miqro connector, use it; MCP control is for everything that doesn't — including coding sources.