The MCP vocabulary, in plain English.

An open protocol that lets an AI assistant discover and call external tools through a standard interface, instead of each assistant needing a bespoke integration for every system.

MCP standardises the transport and the shape of a tool. It deliberately says nothing about who is allowed to call what. That is left to whoever implements the server.

A service that exposes a set of tools over MCP. The assistant connects to it, asks what tools exist, and invokes them.

The side that connects to an MCP server and calls its tools. In practice, that is an assistant such as ChatGPT, Claude, Cursor or Copilot.

A single callable operation exposed over MCP, with a name, a description and a typed input schema. When generated from an OpenAPI spec, one API operation usually becomes one tool.

The description is not documentation. It is a prompt. It is how the model decides whether to call the tool at all.

The list of tools an MCP server returns when an assistant asks what it can do. In a governed server this list differs per user, because a tool a user cannot call should not be listed to them.

One MCP deployment serving many customers, with each customer's tools, credentials and data isolated from the others.

The hard part is making isolation a property of the system, enforced in the database, rather than something every query must remember to do.

One customer of a multi-tenant system. Every row of data, credential and audit record belongs to exactly one tenant.

One upstream API brought under the gateway, with its base URL, credentials, identity model and generated tools. A tenant typically has several.

An identity model where users sign in through the gateway's own identity provider, so you do not have to run one.

An identity model, standardised as RFC 8693, where a token from one issuer is exchanged for another scoped to a specific downstream service. In practice it lets users authenticate against the identity provider your organisation already runs.

An identity model where the gateway redirects users to your own login page, and your product asserts who signed in over a signed contract. You keep your user directory; your users never see a second login.

A long-lived secret, typically an API key, that grants its holder access until someone revokes it. The thing you do not want an assistant to hold.

A standing credential in a client config carries the permissions of whoever it was issued to, not of the person typing, and it commonly outlives that person's access to the systems it opens.

The principle that a caller should be able to do exactly what their task requires and nothing more. For agent access this means the agent inherits the signed-in user's permissions, not a service account's.

Narrowing a tool parameter to the specific values the signed-in user may legitimately choose, before the schema is shown to the model, so the assistant picks from a valid list instead of guessing identifiers and retrying.

It is a usability and cost win as much as a security one, but it is defence in depth: the server still enforces access when the call runs.

An append-only record of what was called, by whom, with what arguments and what came back. For agent access the defining property is attribution to a person rather than to an integration.