The MCP client injects a server's tool descriptions into the same context as the system prompt

A server advertises tools with names, descriptions and JSON schemas, the client passes those definitions to the model, and the model emits structured calls that the client executes ^[1]. The description is a string authored by whoever wrote the server, and it enters the model's context alongside the user's instructions ^[2]. Tool results arrive by the same route, so fetched web content sits in the same context window as the system prompt ^[3].

A review that checks which model you picked is inspecting the component that reads that text. It leaves the components that supply the text unexamined. The dev.to post makes that its central charge: teams pick a capable model, wire up a handful of MCP servers, and treat the resulting tool calls as internal plumbing ^[6].

The credential is the other half. Many deployments hand the agent a long-lived token or a broad service account so that tools just work, which means one misdirected call carries that full authority ^[4]. The post calls this a confused-deputy problem, with the boundary between data and instruction enforced only by the model's judgment ^[5].

Its example chain: a user asks for a summary of an issue tracker item, and the item body instructs the agent to call `export_repo` with `include_secrets=true` and post the output to a URL. The export tool runs under the agent's service-account permissions and returns repository content including committed configuration files. An outbound HTTP tool posts it to an attacker-controlled endpoint ^[7]. The post says the sequence needs no memory corruption, no authentication bypass and no CVE ^[9].

It also says what the chain is: "a realistic composition of publicly discussed weaknesses rather than a single vendor advisory", offered as a reasoning model, and it does not claim a reproduced exploit ^[8]. For it to describe a given deployment, two conditions have to hold. The agent needs a broad read tool and an outbound network tool live in the same session ^[7]. And nothing in the client can require a human to approve the second call ^[13]. Teams that already require approval for outbound calls are not exposed to this chain.

Six headings carry the post's recommended controls: separate the data and instruction planes, constrain authority, gate the irreversible, pin and review tool definitions, log the decision, and assume compromise of the content path ^{[11][12][13][14][15][16]}. Five of them change credentials, client behaviour, approval records or logs. One control touches the prompt: delimit retrieved content and tell the model to disregard directives inside it. The post says that helps without solving the problem, because the model still reads both ^[11][1].

The pinning control is the cheapest of the set to implement and the easiest to skip. Record the tool schema and description hash at approval time, then alert on change ^[14]. The alert closes the window on a server rewriting a description after the user approved it ^[10]. The logging control asks for something most agent traces do not capture: which content the model cited when it chose a tool. Without that record, an incident review cannot separate a misconfiguration from an injection ^[15].