Agentic Access (MCP)

Mirox lets an external AI agent operate the platform on your behalf — under your exact permissions — through the Model Context Protocol (MCP). The platform runs an MCP server that exposes its capabilities as agent tools, so any MCP-compatible client can read your data, manage your plants, and run operations the same way you would in the interface or with the REST API, never exceeding what your own access allows.

Concept

MCP (Model Context Protocol) is an open standard that lets an AI agent discover and call the functions a system makes available. Mirox publishes its capabilities as a catalog of MCP tools — each tool is one well-defined operation, such as listing your plants, reading a metric, or proposing a change to a plant's details.

An agent connects to the Mirox MCP endpoint, sees the tools it is allowed to use, and calls them to get work done. Because every tool runs through the same access checks and the same business logic as the interface and the REST API, the agent sees exactly what you would see and can do exactly what you can do — no more.

Note: the agent's token and your underlying role decide which tools succeed — the agent can never reach beyond your own access.

What You Can Do

Through MCP tools, an agent can work across the platform much as you do by hand:

• Read your estate — list and inspect your portfolios, plants, plant events, and tickets.
• Query performance data — read any series of the Data Export metric collection for the plants you can access (production, expected production, irradiation in every lane including satellite, performance ratio, availability, curtailment, money), at any step the series serves, and define, validate and preview organization-wide Metrics written in MetricsQL. The assistant reads the same collection the export page, the reports and the alert rules use, so a number it quotes is the number the page shows.
• Manage plants — propose creating a new plant or updating its basics, dates, address, business details, components, contacts, and performance-ratio values.
• Handle operations — open and list tickets, review a plant's direct-VPN connection state, and propose a safe configuration fix.
• Work with documents — search, read, and attach files in document storage, and read the product documentation.

Write operations follow a propose-then-apply pattern: the agent proposes a change and the result is presented for review and acceptance, rather than being written blindly. This keeps you the decision-maker even when an agent is doing the preparation — and it holds no matter which client drives the agent.

One Capability Layer, Every Model

MCP is not just how external agents reach Mirox — it is how every model reaches Mirox, including the built-in assistant. There is one catalog of capabilities, and whichever AI is answering calls into it the same way.

That single layer is what makes the platform precisely controllable:

• Capabilities are curated, not generated. Each one is a deliberate, well-defined operation with its own access checks — not an endpoint automatically exposed because it happened to exist. What the AI can do is a decision, reviewed capability by capability.
• Reads and writes are separated by design. Write operations are propose-then-apply; the broad fallback access is read-only and rejects anything but GET. An agent cannot invent a way to change data.
• Swapping the model changes nothing about the boundary. Connect a different vendor, or your own hosted model, and it inherits exactly the same catalog and the same checks. Capability is a property of the platform, not of whichever AI you chose this week.
• Secrets are structurally absent. No capability returns a key, certificate, pre-shared key, token, or password — so no model, however it is prompted, can extract one.

The Audit Trail

Every capability call is attributed and recorded the same way any other access to your account is, which means AI activity is reviewable rather than taken on trust:

• Who — the call is attributed to the human whose permissions it ran under. There is no anonymous "the AI did it": an agent acts as you, and the record says so.
• What — which capability ran, and the result it produced.
• Which model — a conversation shows which model answered each message, so an answer can be traced back to the AI that produced it.
• What was proposed and decided — every wizard run keeps its full transcript with each proposed action and your accept-or-reject decision.

Audit records cannot be edited or deleted by users. Combined with the propose-then-apply rule, that gives a reviewer the two things they actually need: what the AI was able to do, and what it actually did.

Connecting an AI Agent

Connecting any MCP-compatible client takes two steps.

1. Create a scoped API token. In your profile, create an API token and choose the permission group that matches the job — Full Access for an agent that needs to operate the platform, or a narrower group (Metric Export, Timeseries Database) for read-only work. The full token value is shown only once, so store it securely. See the API tokens usage guide for the step-by-step flow.

2. Point your MCP client at the Mirox MCP endpoint and authenticate with that token. Mirox uses the same scoped API tokens as the REST API: the client sends the token in the standard Authorization: Bearer <api_token> header. Once connected, your client lists the available tools and can begin calling them.

Permissions & Control

An agent acting through MCP is bound by exactly the same controls as you are — there is no special agent privilege. Three things, together, decide what any tool call may do:

• The API token's permission group. A token scoped to Metric Export or Timeseries Database can only do read/export work; only a Full Access token lets an agent operate the platform. The group can only ever narrow access, never widen it.
• Your underlying role. The token always acts as you. Whatever your organization role (Administrator, Moderator, Asset Manager (Technical), Asset Manager (Commercial), Member, External) and your per-plant job role (Operator, Technical Manager, Asset Manager, Viewer) let you reach is the exact ceiling for the agent — on a per-plant and per-portfolio basis, with cooperations honored exactly as elsewhere.
• The full permission model. Every tool call passes through the same layered checks as a normal request — token scope, platform standing, your organization role, and the per-plant job check — so access is decided the same way it is across the whole permission system.

Two platform guarantees apply to everything an agent does:

• No secrets to the agent. MCP tools never expose VPN keys, certificates, pre-shared keys, tokens, or any other credential. An agent can propose a direct-VPN fix, for example, without ever seeing the underlying keys.
• Everything is audited. Each tool call is attributed to you and recorded, exactly like any other access to your account, so agentic activity stays accountable and reviewable.

Related Features

• AI Assistant & Wizards — the built-in chat assistant and guided wizards that use these same tools from inside the platform
• API Tokens — the scoped, revocable credentials an agent authenticates with
• Permission System — the layered access model and permission groups that bound everything an agent can do
• Audit Logging — where agentic activity is recorded alongside other access to your account
• API Tokens Usage Guide — step-by-step token creation for connecting an agent
• AI FAQ — common questions about AI safety, data handling, and control