Open-source connectors carry the rule; MCP servers publish the tools

Merge sells a connector product and defines the term this way: "An MCP connector is an MCP server that's either provided by the software solution or built and maintained by a 3rd-party" (Merge). The sentence is accurate about supply. Something builds the server, and tools hang off it. It says nothing about the buyer's side of the connection, where a person decides that this agent, on this account, may run this action.

The rest of Merge's workflow fills that gap without naming it. The agent picks a connector and a tool. It asks the person to authenticate, then invokes the tool. Authentication appears as a step the client runs, which is the entry doing its work inside a definition that started at the server. The definition names a supplier. The entry, with its rules, is the part a team configures, and the account behind it is a connection the team opens on that connector. What an MCP connector is covers that entry in full. The narrow point is enough: a supplier is not the gate in front of it.

The tool list is the server's first statement about itself. A client sends tools/list and gets a name, a description and an input schema for each tool. That reply is the argument surface a reviewer can read before anything runs. tools/call invokes one (specification). One server can publish forty tools and another three. Two servers fronting the same product often publish different lists.

The spec puts four duties on the server and writes them as requirements. Servers must validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitize tool outputs. The second duty is where a claim about MCP permissions gets tested. The protocol defines no permission system, so access control happens at the server or nowhere.

Merge says the same in one line: "Tool access control is handled at the MCP server level, since MCP doesn't offer a built-in permissions system" (Merge). That is why a tool description cannot tell you what the credential behind the tool may do. The server decides which tools exist and who reaches them. The credential decides what the provider behind it permits.

The model picks the tool, and the protocol intends that. "Tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts" (specification). A model's choice is a preference, not a permission. The client side needs a gate of its own.

The spec asks the client to confirm sensitive operations, show tool inputs before calling the server, and log tool usage for audit. Those are SHOULDs. A client can speak MCP correctly and still call a write with nobody watching.

Kortix writes the policy into the connector entry and keeps the account on the connector. A connector has a slug, a display name, a provider, its actions (<slug>.<action>) and its policies. The manifest never holds a credential (Kortix docs). Actions are always_run, require_approval, block, shown as Allow, Ask, Block, and "Approval holds the call; the agent's turn pauses and resumes." Connector credentials are brokered server-side and never enter the machine. "Every action is recorded. Reading, exporting and streaming the audit log depend on the plan."

The entry is one of three layers around a call. Which tools an agent can reach covers the tool list, the agent's grant and the account together. The grant is the layer this entry does not contain.

A product can host connectors and be an MCP server at once. Kortix documents both directions. "A provider: mcp connector is Kortix calling someone else's MCP server. The Kortix MCP server is the other direction: your MCP client calls Kortix."

Direction one puts Kortix on the client side. A provider: mcp entry names a remote server with a url and a transport. The transport is http by default, or sse. Kortix sends the call. The account, the policy and the audit event all belong to Kortix's side of that request. The server's operator sees a call from an account, never a person at a keyboard.

Direction two puts Kortix on the server side. The Kortix MCP server exposes Kortix's own tools, and another client calls it: an IDE, a desktop app or another agent system. There Kortix publishes a tool list and answers tools/call. The policy that governs the call lives with the client on the other end.

So "is this an MCP client or an MCP server" has no useful answer until the direction is named. Ask which side of the call the product sits on, and for which call.

Portkey puts the connector layer inside its gateway. The MCP Gateway is documented as a proxy between MCP clients and MCP servers that handles authentication, access control and logging. Clients authenticate once to Portkey, and the gateway injects credentials, checks permissions and logs requests per server, with tool provisioning per user, rate limits and guardrails (Portkey). The company now presents itself as PRISMA AIRS AI Gateway. Merge's Agent Handler sells the catalog layer: 30+ pre-built connectors, provider-managed credentials, and tools a team reviews after they are generated.

Kortix writes the entry into the project's repo, which is the layer a reviewer can read before a session runs. Each description is accurate about where that product sits. The three describe different places to look for the same decision. A comparison between them is a comparison between a gateway, a catalog and a file.

Each of these names one layer, which is what makes the answer checkable.

• The server publishes the tools; the client sends the call and names the account.
• The credential belongs to the connector's account and stays server-side, so no sandbox holds it.
• The rule that lets a call run is a policy on the connector's action, checked before the provider sees the request.
• The record of the call is the audit log, so ask which layer writes it and who can read it.