Ten MCP servers stay reviewable on one open-source platform

Two servers can each publish a tool called create_issue. Nothing in MCP keeps tool names unique across servers. The model picks from the list the client hands it, so a flat list of forty names with two create_issue entries leaves the choice open. A reviewer has the same problem. Which rule covers the call?

Kortix settles it at the connector. The first field is "a slug, unique in the project ([a-z0-9][a-z0-9_-], up to 128 characters)". It starts with a letter or a digit. Then come letters, digits, underscores and dashes, with no uppercase and no leading dash. A connector also carries a display name, a provider, its actions as <slug>.<action> and its policies, and it lives in kortix.yaml under connectors: (Connectors). Kortix proposes the slug from what it can read: the document's title, or else the URL's domain. An MCP server added from its URL is named after its domain, so https://mcp.linear.app/mcp arrives as linear.

The action name carries the namespace. linear.create_issue and atlassian.create_issue are different tools in the transcript, in a policy pattern and in an approval. One rule cannot catch the other by accident. At ten servers that distinction is what keeps the set readable, since the tool list is not the only place it has to exist.

A rule that must hold across ten servers is the first thing that strains. Take one: nothing may delete. Written into ten connector entries, it is ten chances to miss one. The eleventh server ships with whatever its author remembered.

Kortix evaluates every call against four levels. The first match wins:

1. Project-wide policies: in kortix.yaml, with fully qualified patterns such as gmail.send_email or *.delete*. A connector rule cannot override them.
2. The connector's own policies:, with patterns relative to that connector, such as send_*.
3. sensitive: true on the connector, after which every action no rule matched needs approval, reads included.
4. policy.default_mode: allow_all (the default) runs every remaining action, while risk runs reads and holds writes and destructive actions for approval.

Put the cross-cutting rule at the first level and local habits at the second. *.delete* at the top blocks a delete on every server in the project. On docs-search, get_* can run while * asks. A generous Allow on one connector cannot reopen what the project blocked.

The last two levels spare a team a rule per tool, and they are not the same gate. sensitive: true sends a connector's remaining actions to approval, reads included, which fits a server whose tools nobody has read yet. policy.default_mode: risk is the looser of the two: it runs reads and holds writes and destructive actions for approval, across every connector with no rule of its own.

Order matters here. A connector rule is read before sensitive, so a get_* Allow on a sensitive connector still lets reads through. Check that when a connector looks stricter than it behaves.

Not every connector is an MCP server. Kortix connects 3,000+ apps in a click, plus MCP, OpenAPI, Postman, GraphQL and raw HTTP. One project-wide pattern covers all of them. *.delete* reaches a managed Gmail connector and a remote MCP server with the same line.

Actions are always_run, require_approval, block, shown as Allow, Ask, Block. Approval holds the call; the agent's turn pauses and resumes.

Reach is decided again at the agent. agents.<name>.connectors lists the slugs an agent may call, or all; an omitted value means none (Give an agent a connector). Ten connectors in a project and three on the release agent take one line in that file.

all is the value that changes a review. It covers every connector in the project, including the ones someone adds next month. A reviewer who approved all approved a list that keeps growing. A slug list has to be edited before reach changes, and the edit arrives as a diff beside the agent that gains the server.

What an agent can reach through a connector is the tool list, the grant and the account behind the call. At ten servers the grant is the cheapest of the three to read. It is also the one most often left at all.

Every action is recorded. Reading, exporting and streaming the audit log depend on the plan. One log across ten servers answers a question once: which agent called which action, as which account, at what time. Ten logs answer it in ten places. The specification only asks clients to log tool usage, so a set of servers can leave the record thinner than a team assumes.

The plan point deserves a plain line. Recording happens on every plan. A team that expects to read, export or stream the record during an incident should confirm the plan includes it first. A log nobody can open answers nothing.

The first servers arrive one at a time, usually for one team and one job. The fourth is where a set either stays reviewable or turns into ten entries nobody has read together. Five steps, each one a field.

1. Name it. Give the connector a slug that names the system it reaches, and check it is unique in the project. Field: slug, under connectors:.
2. Place the rule. A pattern that must hold across servers goes in the project-wide policies:. A habit for this server alone goes in the connector's own policies:. Field: the project's policies: or the connector's policies:.
3. Grant it. Add the slug to the agents that need it and leave all alone. Field: agents.<name>.connectors.
4. Attach the account. Choose a shared account for work a team or a schedule owns. Use a private one only for a person's own sessions. Connector credentials are brokered server-side and never enter the machine, so this step decides identity. Field: the account's owner type, and whose permissions a call carries.
5. Check the record. Send one read and find it in the log before the server carries real work. Field: the audit view of the session.