MCP Is Easy to Build. The Spec Sets the Rules First.

What does the MCP spec require before a server goes live?

Building a basic MCP server takes little code. The harder part is meeting the security rules in the official specification. Some rules are hard requirements, written as MUST. Others are recommendations, written as SHOULD, and some are left to whoever builds and deploys the server. This guide sorts them into those groups, based on the authorization and tools pages (2026-07-28 revision) and the official security best practices page ^[1][2][3].

The spec is also not the only source of guidance. The OWASP MCP Security Cheat Sheet adds controls that the spec does not require, and some of them are stricter ^[4]. Keep the two apart when you plan a launch, because a server can pass a spec review and still be exposed.

Which token rules are mandatory?

Authorization is optional in the spec, but a remote server that uses it has to check who a token was issued for. HTTP servers that follow the authorization specification SHOULD conform to it ^[1]. The spec says servers MUST validate that access tokens were issued specifically for them as the intended audience, according to RFC 8707 Section 2 ^[1]. Servers also MUST only accept tokens valid for their own resources, and MUST NOT accept or transit any other tokens ^[1].

In practice, this rules out a common shortcut: forwarding the token a client sent to a downstream API. A token issued for your server is not a token for someone else's service, and your server should not hand it on. If you cannot tell whose token a request carries, treat the request as unauthorized.

OWASP makes the same point from the other side. It says to validate authorization on every protected request, because the Streamable HTTP transport has no protocol-level sessions ^[4]. Check the token on each call, not once at connection time.

Do proxy servers need consent for each client?

Yes, when the server sits in front of a third-party API. The security best practices page says MCP proxy servers MUST implement per-client consent and proper security controls to prevent confused deputy attacks ^[3]. The page explains the risk: attackers can exploit MCP proxy servers that connect to third-party APIs, which creates confused deputy vulnerabilities ^[3].

The failure looks like this. A proxy holds a broad credential for a third-party API. A client that was never approved asks the proxy to act, and the proxy uses its own privileges rather than the permissions of the user who should have been asked. Per-client consent is the control that stops one client from using access a user granted to a different client.

Does the spec require human approval for tool calls?

No. The tools page says the protocol does not mandate any specific user interaction model. What it does say is that clients SHOULD prompt for user confirmation on sensitive operations, and SHOULD show tool inputs before calling the server ^[2].

The same page lists sanitizing tool outputs as a MUST for servers ^[2]. So the mandatory part for the server is the output check, and the approval step is a recommendation for the client.

OWASP takes a stricter line. It says to never auto-approve tool calls, especially in multi-server setups ^[4]. If a tool can delete data, spend money or share personal information, build the confirmation step into your server or your own client rather than relying on whatever the client does by default. Keep the prompts for those tools only. Prompting on every read request risks teaching users to click through, so treat that as a design judgment rather than a spec rule.

Do local MCP servers follow the same rules?

Not always. The authorization page separates transports. Implementations that use HTTP are expected to follow the authorization specification. Implementations that use the STDIO transport SHOULD NOT follow it, and instead retrieve credentials from the environment ^[1].

That difference matters for a local tool. A server started as a child process does not need an OAuth flow to reach its own API, but it still needs its credentials kept out of the code and out of logs. Avoid putting secrets in the command line, because shell history and process listings are easy places for them to leak. If you later expose the same server over HTTP, HTTP servers SHOULD follow them.

What do security guides add on top of the spec?

Security guides go further than the spec's minimum. The OWASP MCP Security Cheat Sheet recommends pinning tool definitions with cryptographic hashes and verifying them before each execution ^[4]. It also says to treat every tool response as untrusted data, including responses from servers you have already approved ^[4].

It adds a least-privilege rule as well. Grant each MCP server the minimum permissions it needs for its function, and use scoped, per-server credentials rather than sharing one token across servers ^[4]. A server that reads mail should not hold a token that can also modify it.

These controls are not conformance requirements, so a server can pass a spec check without them. They matter most when a tool description or a tool result comes from a party you do not control.

What does the spec leave out?

The spec leaves several decisions to the builder. It does not require validation of tool description text. The tools page requires servers to validate tool inputs, implement access controls, rate limit tool invocations and sanitize tool outputs, but it has no MUST on the description text itself ^[2]. Your server has to decide how it reviews the descriptions it publishes, and your client has to decide how much to trust them.

The spec leaves the approval interface to implementers. The tools page also recommends logging tool usage for audit purposes ^[2], so the approval design and the audit trail are yours to build. Two clients can handle the same risky tool in very different ways, which is why the behavior of each client needs testing, not just the server.

What should you check before you ship an MCP server?

Use this list as a pre-launch check. Each item says where the requirement comes from.

• Token audience: reject any token that was not issued for your server. This is a spec MUST ^[1].
• No passthrough: do not forward a client's token to an upstream API. This is a spec MUST ^[1].
• Consent: if you proxy a third-party API, store consent for each client separately. This is a spec MUST for proxy servers ^[3].
• Outputs: sanitize tool outputs before you return them. This is a spec MUST for servers ^[2].
• Authorization on every call: check the token on each protected request, not once per connection ^[4].
• Confirmation: prompt the user before sensitive actions, and show the parameters that will be sent. This is a client SHOULD in the spec, and OWASP recommends explicit confirmation for destructive, financial or data-sharing operations ^[2][4].
• Scope: give each server the narrowest permissions and its own credentials ^[4].
• Definitions: pin tool definitions, verify them before each run, and ask for review again whenever they change ^[4].

What should a launch review record?

A short written record makes the review repeatable. For each server, keep a list of its tools and mark each one with its impact: read only, changes data, or affects money or personal data. Next to each tool, note whether it needs a confirmation step and who owns that decision. Record which transport the server uses, where its credentials come from, and which clients are allowed to call it.

The record should also point to the test results from the next section. A reviewer who sees a tool marked as affecting personal data, with no confirmation step and no test evidence, has found the gap without having to read the code.

How do you test each rule before launch?

Turn each mandatory rule into a test you can run against a staging server:

• Wrong audience: send a token issued for a different resource. The server should reject it, and the error should follow the OAuth 2.1 error handling rules ^[1].
• Unregistered client: send a request from a client that has no recorded consent to a proxy. The request should fail until consent exists ^[3].
• Hostile output: return a tool result that contains an instruction, such as a line telling the model to ignore earlier rules. Check that your sanitization step removes or labels it before it reaches the model ^[2][4].
• Burst of calls: send many calls to one tool in a short time. Check that the rate limit holds, since servers must rate limit tool invocations ^[2].
• Log review: search logs and error messages for tokens and credentials. The search should find none.

Run these tests on every release, and again after any change to a tool definition. OWASP recommends asking for review again when definitions change ^[4].

Treat the list as a floor rather than a ceiling. It covers what the sources require or strongly recommend, and your own threat model may add more. Run the tests above against a staging server before the first release.