Chronos MCP registry

What is the Chronos MCP registry?

Chronos by Intelligex is an open source, self-hosted control plane for AI agents and MCP tools.

The MCP registry is the part the control plane where every tool integration is registered as a Model Context Protocol server, given a slug, brokered through a gateway, and exposed to agents through one credential-managed surface.

Oce you scale past one or two agents, every agent ends up holding its own database password, GitHub PAT, Slack token, and so on. Rotating credentials becomes complex.

Auditing becomes important. Restricting which tools an agent may call becomes also important. Chronos MCP registry aims to address all of these within the product.

What is MCP, in 60 seconds?

The Model Context Protocol is a wire-format spec for tool servers. An MCP server publishes a typed catalog of tools tools/list and accepts invocations tools/call. Each tool has a JSON-Schema input shape, a description, and a typed result. The same protocol describes everything from "query my Postgres" to "post to a Slack channel" to "fetch a row from an internal microservice".

In Chronos, every registered MCP server gets:

• A slug - examples: postgres, github, internal-tools.
• A transport — streamable-http (recommended), sse (legacy), or stdio.
• A URL Chronos can reach over HTTP.
• An outbound auth shape; Bearer or static header, inline or vaulted credentials that Chronos presents to the server on every call.
• An allowedTools list — the operator-side allowlist of which of the server's tools may be exposed at all.

Every tool then becomes addressable across the platform as <server-slug>.<tool-name>. For example: postgres.query, github.create_issue etc. The namespace lets two MCP servers expose tools with the same bare name without colliding.

Why a gateway?

The Chronos inbuilt gateway is what makes the registry useful in production.

When a registered agent wants to invoke a tool, it doesn't talk to the MCP server directly — it calls one platform endpoint:

POST /api/v1/agent-callbacks/<agentId>/tools/invoke

The MCP gateway then:

1. Authenticates the caller. The agent's per-agent callback token is the bearer credential — no separate API key.
2. Resolves the namespaced tool name to the registered MCP server.
3. Authorises the call against the intersection of Agent.allowedTools and the server's allowedTools.
4. Opens or reuses a pooled MCP client keyed by server ID; lazy-open, idle eviction every 60s, error eviction on transport failure.
5. Calls tools/call with the server's own outbound credentials (which never reach the agent).
6. Returns the typed result to the agent.
7. Emits an audit line event=mcp.tool.invoke tagged with agent slug, server slug, tool name, latency, and success state.

Steps 1, 2, 3, 5, and 7 are the policy and observability bits — and they happen for every tool call from every agent, regardless of whether the agent is a BUILT_IN canvas agent or an external HTTP one.

The intersection rule

allowedTools shows up in two places, and the gateway enforces the intersection on every call:

• MCPServer.allowedTools is the platform-side policy — allows control on which of MCP servers tools may be exposed via Chronos MCP gateway.
• Agent.allowedTools is the caller-side policy — per-agent scope on which exposed tools specific agent may call.

authorized = Agent.allowedTools.includes("<slug>.<tool>")
   && MCPServer.allowedTools.includes("<tool>") // empty list = no restriction

Both these lists provide controll, but behave slightly different.

An empty MCPServer.allowedTools means "no restriction" - all given MCP server tools are allowed.

An empty Agent.allowedTools means the agent cannot call any tools.

The split is intentional. The Chronos doesn't know which agents will be built or imported into Agent registry and the agent authors do not know which tools the Chronos platform owners consider safe to expose.

Outbound auth shapes

Chronos's gateway authenticates to the external MCP server using one of the four shapes, all stored as JSON on the MCPServer row:

• Bearer with inline secret — the token sits on the row.
• Bearer with vaulted secret — the row holds a credential ID; the token sits in the encrypted credential vault.
• Static header with inline secret.
• Static header with vaulted secret.

Inline secrets are convenient for local development.

Production deployments mostly choose to reference the vault so credential rotation is a one-row update instead of an MCP-server details edit.

OAuth2 client-credentials is going to be introduced in future Chronos release.

Connection pooling and resilience

Per-server pools keyed by server ID, with three behaviours worth knowing about:

• Lazy open. First call opens a client; subsequent calls reuse it.
• Idle eviction. A reaper runs every 60 seconds and closes any client unused longer than five minutes. Configurable via MCP_CLIENT_IDLE_TIMEOUT_MS.
• Error eviction. A failed tools/call or tools/list evicts the client immediately so the next call reconnects fresh.

Guidence for Chronos admins: if you have a large number of low-traffic MCP servers and idle TCP connections matter, keep the idle timeout low.. If you have a few high-traffic servers, leave the idle timeout long.

Discovery: live tool catalogues

The registration UI has a Discover Tools button.

Clicking it opens a real MCP session against the configured URL, calls tools/list, and populates the allowedTools autocomplete with the server's actual tool names. It pre-populates the allowlist in the dialog, and user can remove unwanted tools before saving MCP server config.

A second endpoint — GET /api/v1/agent-callbacks/<agentId>/tools — returns the static intersection of an agent's allowedTools and each related MCP server's allowedTools. This represents what this specific agent is authorised to access.

Where the registry sits in the bigger picture

The Chronos MCP registry is the tool-layer within Chronos control plane. The agent-runtime is the Chronos agent registry — agents register who invokes, MCP servers register what may be invoked. The gateway brokers the connection.

These are linked to Chronos governance — SSO, RBAC, per-team budgets with stop-switches, persistent audit logs. The MCP gateway emits the audit signals those features enforce against.

The roadmap for the Chronos MCP gateway has maintained reference servers (Postgres, GitHub, Slack, Jira, S3), per-server retry / backoff / rate-limit / circuit-breaker policies, OAuth2 refresh-token management and a tool catalogue browser UI.

This page keeps track of what is already available.

Get hands-on

• Register an MCP server in Chronos by Intelligex — register a Streamable-HTTP MCP server, choose a transport, configure outbound auth, populate allowedTools via Discover Tools.
• Register an HTTP agent in Chronos by Intelligex — wire up the agent side that calls into the gateway.
• Chronos agent registry — the Chronos agent-runtime.
• Chronos governance — what governance the gateway audit signal will eventually feed into.