CAPABILITIES
RouteFreely MCP: Administer Your AI Operation Through AI
Your AI platform can now answer questions about itself. The RouteFreely MCP exposes routing, usage, instruction state, and access to agents, so operating the platform becomes a conversation instead of a console hunt.
What the RouteFreely MCP is
The RouteFreely MCP is the administrative and diagnostic surface of RouteFreely, exposed through the Model Context Protocol. The same protocol RouteFreely governs for connecting AI to your business tools now connects AI to the platform itself.
Through it, an agent can read the state of your AI operation: which backends are healthy, how virtual models map to real providers, where usage and cost concentrate, what recent traffic looks like, which instruction blocks are shaping assistant behavior, and how access actually resolves for any user.
The platform that governs MCP tools is itself operable through MCP. That symmetry is the point.
AI platforms fail opaquely
When something goes wrong in an AI operation, the cause usually lives in a layer nobody can see from the outside. A model misbehaves, and the reason is an injected instruction block. A user loses access, and the reason is a policy resolution chain across groups, overrides, and grants. Costs spike, and the reason is one workflow on one expensive mapping.
Admin consoles were built for clicking through those layers one screen at a time. They were not built for asking.
The result is familiar: diagnosis by guesswork, tribal knowledge about configuration, and expensive questions that take hours because the answer is spread across five views.
Readable by agents, governed on write
The RouteFreely MCP makes the platform inspectable by design. Reads are the working surface: an agent can inventory endpoints, trace mappings, summarize usage, pull recent activity, audit instruction blocks, and resolve effective access, all as answerable questions.
Writes are deliberately different. Administrative changes, group membership, policy updates, overrides, grants, and role changes, require explicit confirmation before they execute. An agent can find the fix and propose it; a person approves the specific change. Diagnosis moves at conversational speed while change stays governed.
Two honest qualifications. This is an operations surface for administrators and operators, not a general business-data system; it answers questions about your AI platform, not your CRM. And agents operating through it work under the same access governance as everything else in RouteFreely: the surface extends administration, it does not bypass it.
The mechanisms of a conversational admin surface
-
Routing and health visibility
Backend endpoints, proxy health, and platform settings are readable on demand, so which backend, since when, is a question with a factual answer.
-
Virtual model catalog
How user-facing model names map to real backends, and where failover coverage exists, is inspectable rather than remembered.
-
Usage and cost analytics
Aggregate usage with model-level and endpoint-level breakdowns supports budgeting, exposure review, and portfolio decisions.
-
Request diagnostics
Recent traffic through the proxy is retrievable for error investigation, slow-request analysis, and load review.
-
DriftHold instruction audit
Injected context blocks are listable and inspectable by scope and class, with change history, making the hidden layer that shapes assistant behavior reviewable.
-
Access resolution and administration
Effective policy resolution shows exactly why a user can or cannot reach a model, and the fix is executable through the same surface, with confirmation.
What a conversational operation changes for the business
-
Diagnosis in minutes
Routing failures, access problems, and behavior questions become factual lookups instead of multi-screen investigations, which shortens incidents and support queues.
-
Governance you can produce on demand
Instruction audits, access mappings, and usage reviews are generated when asked, so oversight stops depending on someone assembling screenshots.
-
Administration without the console hunt
Routine platform questions get answered where the work happens, and administrators spend their attention on decisions rather than navigation.
Two questions, answered in one conversation
A virtual model starts failing mid-afternoon. An operator asks the agent what changed. Endpoint health shows one backend degraded twenty minutes ago; the mapping shows which virtual models depend on it; failover coverage shows where fallback engaged and where it could not. The incident summary writes itself from facts.
A department head asks why the assistant answered a compliance question strangely. The agent inventories the active instruction blocks in scope, inspects the relevant one, and pulls its change history. The behavior traces to a governed instruction updated last week, which is exactly the explainability instruction locking was built to provide.
Shipped, not promised
-
A shipped operations surface
Routing visibility, the model catalog, usage analytics, diagnostics, instruction audit, and access administration are live capabilities of the platform.
-
Read-first by design
The reporting and diagnostic surface is read-only, and administrative writes are confirmation-gated, so inspection never risks accidental change.
-
Audit-grade instruction visibility
DriftHold blocks and their change history are inspectable at runtime, extending instruction governance from policy to proof.
Where the surface has limits
An operations surface answers operational questions. It is not a CRM, an accounting system, or an analytics platform for anything outside AI routing and workspace governance.
Longitudinal views take discipline: trend reporting requires periodic snapshots, and a single read cannot produce a quarter of history. Comprehensive organization-wide inventories may require patient enumeration rather than one call.
And writes remain administrative acts. The confirmation gate is a feature, not friction: a wrongly applied policy change is the most expensive mistake an admin surface can make, so the surface refuses to make it casually.
Frequently asked questions
How is this different from the admin dashboard?
The admin dashboard is the visual console: one place for a person to see and manage the operation. The RouteFreely MCP exposes the same operation to agents, so questions can be asked and reports produced conversationally. They are two doors into the same governed platform, and most teams use both.
Can an agent change platform settings on its own?
No. Reads are open to authorized agents; administrative writes require explicit confirmation of the specific change before execution. An agent can diagnose an access problem and propose the fix, and a person approves it. Inspection is autonomous; change is not.
What can it see about assistant instructions?
Injected instruction blocks are listable and inspectable by scope and class, with change history. That means the question of why the assistant responded a certain way has an audit path: the governed instruction state that was in force, in the version that was in force. See how DriftHold locks that state in the first place.
Is this the same thing as the MCP server registry?
No, and the distinction matters. The MCP server registry governs the external tools your AI can reach. The RouteFreely MCP is the platform itself exposed as a tool surface. One governs outbound connections; the other makes the operation inspectable. Together they mean MCP is governed in both directions.
The operation you can ask questions of
Most AI platforms can only be operated by the people who already know where everything is. RouteFreely can be asked.
Routing, usage, instructions, and access, readable on demand and governed on write. That is what it looks like when an AI platform is built to be operated in the age of agents.
Related pages
-
Admin Dashboard
One console for your AI operation.
-
MCP Server Registry
Governing the tools AI can reach.
-
Drift Control
How DriftHold locks instructions in place.
-
Usage Visibility
Attributable records for AI operations.
-
RouteFreely
The routing and control layer.