Product · MCP governance
Govern MCP — catalog every tool, wire who uses what
Module V, Capabilities. The MCP client introspects each server’s tools/list and resources/list into an internal registry, so you get a versioned catalog of servers, skills and tools — plus a wiring graph of which agent uses which tool. Managed configuration references your secrets by reference; raw secret values never enter the catalog.
In the product
The capabilities console
A genuine screenshot, example data. Tabs for servers, skills, tools, the capability wiring graph and managed configs. Connection state is derived from real signals; approved entries carry a content hash and, where a signing key exists, an Ed25519 signature.
What you govern
A registry for every tool your agents can reach
The MCP client speaks stdio and Streamable HTTP, introspects each server, and records what it finds — so the catalog reflects what the servers actually expose, not what a spreadsheet claims.
Catalog from introspection
The client calls tools/list and resources/list over stdio or Streamable HTTP (SSE is legacy) and writes the result to an internal registry. You get a versioned catalog of MCP servers, skills and tools, with connection state derived from real signals — not hand-maintained.
A capability wiring graph
See which agent is wired to which tool — the “who uses what” graph at the heart of the console. This is a usage map; it is distinct from the read/read-write access map, which is a separate surface answering a different question.
Secrets by reference, never raw
Managed MCP configuration references your secrets by reference (secret_refs). Raw secret values are never stored in or read from the catalog — the configuration points at the secret, it does not contain it.
Annotations are declared, not trusted
MCP servers may declare read_only_hint or destructive_hint on a tool. We surface those as a declared, untrusted signal from the server — never as an authoritative security badge. Treat them as a hint to review, not as security truth.
What’s real
The catalog, graph and managed config are live; full MCP-RC readiness is in progress
We are precise about what the contract guarantees today and what it does not:
- Live (stable v1 contract): the MCP client over stdio and Streamable HTTP, introspection of tools/list and resources/list into the internal registry, the server / skill / tool catalog, the capability wiring graph, and managed configuration that references secrets by reference. Connection state is derived from real signals.
- Approval and integrity: approved catalog entries carry a content hash and an optional Ed25519 signature. Where no signing key is configured, an entry shows as “approved but unsigned” — we state that plainly rather than imply a signature that is not there.
- Not full spec compliance: readiness against the MCP RC (2026-07-28 spec) is in progress, and several spec changes are not yet implemented — we do not claim full or current MCP spec compliance. The public MCP registry is in preview and rejects private servers today; a private sub-registry is on the roadmap.
- Posture: read-first and detective by default. The catalog and graph describe what your servers expose and how tools are wired; they do not silently rewire or actuate anything.
MCP governance — questions
Do the read_only_hint / destructive_hint annotations tell me a tool is safe?
No. Those annotations are declared by the MCP server itself, so they are an untrusted signal — a server can claim anything. We surface them in the catalog as a declared hint to help you decide what to review, never as an authoritative security badge. Do not treat a “read only” annotation as proof a tool cannot write.
How is the wiring graph different from the access map?
The capability wiring graph answers “which agent uses which tool” — it is a usage map of the connections in this console. The read/read-write access map is a separate product surface answering “what level of access does an identity have to a resource”. They are deliberately distinct; we do not conflate one for the other.
Are my secrets stored in the MCP catalog?
No. Managed MCP configuration references secrets by reference (secret_refs) — the configuration points at a secret, it does not contain the raw value. The catalog never stores or reads raw secret material.
Is Olivares fully compliant with the current MCP specification?
Not yet, and we will not claim it before it ships. The live MCP client is a stable v1 contract over stdio and Streamable HTTP (SSE is legacy), but readiness against the MCP RC (2026-07-28 spec) is still in progress with several changes unimplemented. The public MCP registry is in preview and rejects private servers; a private sub-registry is on the roadmap.
Catalog and govern your MCP estate
Deploy Olivares on your own infrastructure, introspect your MCP servers into a versioned catalog, see who is wired to which tool, and keep secrets referenced — never raw.