Model Context Protocol (MCP)

MCP standardises the connection between an AI application and the tools it can use. A server exposes tools — read a repository, query a database, file a ticket, call an internal service — with names, descriptions and parameter schemas. A client discovers them and can invoke them on the model’s behalf.

It solved a genuine problem. Before it, every AI application invented its own tool integration, and every integration was bespoke.

Why it is the highest-value authority in the setup

Filesystem and network containment govern what an agent can reach on the machine in front of you. MCP is how it reaches everything else: your source control, your production database, your cloud account, your ticketing system, your internal services.

That makes MCP tools, in practice, the most consequential permissions in an agent deployment — and typically the least governed, because approving a server feels like installing a plugin rather than granting standing access to production.

Discovery is not authorization

This is the single most important distinction in MCP security, and the one most clients get wrong.

Everything a server tells you about itself — the tools it offers, their names, their descriptions, their schemas, the effects they claim — is supplied by the server. It is useful information. It is not a decision anybody made.

If a client makes an advertised tool callable because it was advertised, then the server is deciding its own permissions, and “which tools may this agent use” has been answered by the thing being authorized. Tools have to become invocable by explicit registration, and an unapproved discovered tool has to be denied.

The corollary matters too: a tool’s description is not a specification. A server can change what a tool does after you approved it, which is the “rug pull” pattern. Approval has to be tied to identity rather than to a sentence.

Transports

MCP runs over local stdio — the server is a subprocess on your machine — or over HTTP and streaming HTTP for remote servers. The transport changes the trust picture significantly: a local stdio server is a process you can identify by signature and lineage; a remote server is an endpoint, and the questions become transport security, endpoint identity and OAuth scope.

BitShout implements and proves local stdio brokering. Remote transport and OAuth brokering are represented in the domain model but are not part of the proven path, and the site says so rather than implying coverage. See MCP security.