MCP: tools need limited permissions

An MCP tool can expose an action to an assistant. The protocol describes how to present and call that tool. It does not decide which data your server is allowed to read. A limited action on public information is easier to control as a starting point.

Describe a single action

Imagine a tool that returns a public project’s name from its slug. No free-form SQL query, no file path and no URL supplied by the assistant. The contract stays small.

1{
2  "name": "get_public_project",
3  "description": "Read the name of a public project from its slug.",
4  "inputSchema": {
5    "type": "object",
6    "properties": {
7      "slug": {
8        "type": "string",
9        "pattern": "^[a-z0-9-]{1,80}$"
10      }
11    },
12    "required": [
13      "slug"
14    ],
15    "additionalProperties": false
16  },
17  "annotations": {
18    "readOnlyHint": true,
19    "destructiveHint": false,
20    "openWorldHint": false
21  }
22}

The schema describes the expected arguments. The handler must still validate what it receives. A precise description helps the assistant choose a tool, but does not act as access control.

Enforce the boundary in code

Here is the function the handler can call. The catalogue comes from the server. An unknown slug or a private project returns nothing. Even by guessing its ID, the caller cannot retrieve a confidential name.

1type Project = { name: string; visibility: "public" | "private" };
2
3// Exemple de contrôle dans le gestionnaire serveur, avant toute lecture.
4// Le catalogue est fourni par le serveur, jamais par les arguments de l’outil.
5export function readPublicProject(
6  catalog: Readonly<Record<string, Project>>,
7  input: unknown,
8): { name: string } | null {
9  if (!input || typeof input !== "object" || !("slug" in input)) return null;
10  const slug = input.slug;
11  if (typeof slug !== "string" || !/^[a-z0-9-]{1,80}$/.test(slug)) return null;
12  if (!Object.hasOwn(catalog, slug)) return null;
13  const project = catalog[slug];
14  if (project.visibility !== "public") return null;
15  return { name: project.name };
16}

This code deliberately focuses on the read permission rule. A real server also needs transport, full schema validation, protocol errors and usage limits. A tool that exposes private data must check identity and permissions on every call.

readOnlyHint is still a hint

The annotation declares an intention to read only. It does not prevent a malicious server from writing or deleting data. The specification says to treat these annotations as hints and not trust those from an untrusted server.

Actual protection comes from the account’s permissions, the operations exposed and server checks. If the source is a database, an account restricted to reads limits what the code can do when something goes wrong. For a destructive action, require a separate confirmation and check permissions at execution time.

Test what should be rejected too

In this example, the tests cover a public project, a private project, an unknown slug and malformed arguments. The right result is not just “the assistant found the project”. It is also “it cannot read the one it has no access to”.