Founders keep hearing “we added MCP” the way they used to hear “we added an API.” Both sentences are empty until someone names the permission.
What MCP actually is
MCP, the Model Context Protocol, is an open standard for connecting an AI application to external systems. The first-party docs (tree labelled 2026-07-28, re-read 2026-08-18) say the protocol focuses on context exchange. It does not dictate how the application uses a language model or how it manages the context it just received.
Three participants. The host is the application that coordinates. The client is one connection to one server. The server is the program that exposes context. The host creates one client per server. The host is where policy lives.
Three primitives on the server, in founder English:
- Tools are actions. They can write: send mail, call an API, change a file, move money if you were foolish enough to wire that.
- Resources are context. Read-oriented. A customer record, a spec, a log.
- Prompts are reusable templates. Not a permission.
You do not need the spec memorised. You need three answers in writing for every server you attach to an agent:
- Visibility. What can this tool or resource read? Files, mail, a database, a customer list. Which class of data. Whose credentials.
- Mutation. What can it change, send, merge, close, or delete?
- Log. Where does the call land so a human can reconstruct Tuesday: who, which tool, a summary of arguments, result class, timestamp, a correlator.
If any answer is “it depends,” the server is not ready. “It depends” is how a helpful agent mails a customer from a draft you never approved.
Walk one pair out loud. “List customers” is a read. “Send the renewal reminder” is a write. If both live on the same server with the same credentials, you have already lost the ceiling.
Permission is a blast radius
A ceiling is the worst thing that happens if the model is wrong and the host is sleepy.
Prefer a read-only server before a write server. Split them when you can. Allowlist tools on the host. Do not take “all tools from this server.”
The specification tells clients to treat tool annotations as untrusted unless the server itself is trusted. Do not outsource the ceiling to the server’s self-description.
The override doctrine is the written refuse-list: spend above a ceiling, speak as the company, change production data, close a judgment you still own. It complements the contract. The contract says what this server may do. The doctrine says what it must refuse. Write both before the tool that can send.
Authorization in MCP is optional. The docs recommend it when user data, audit, consent, or per-user limits matter. Optional is the word that should keep you awake. A local server with an environment secret can still be root-shaped.
Write paths and Tuesday’s log
Tools are model-controlled. The protocol does not mandate a specific user interface. Applications should keep a human able to deny a call. “Should” is not a gate you can audit.
Treat send, spend, delete, and production mutation with the seriousness of a payment integration. Review the first ten calls. After that, the log is the review. No log, no write tool.
Ask for Tuesday. “Show me every send from this server between 09:00 and 18:00.” If nobody can, the contract is incomplete. Official security guidance warns about token passthrough for the same reason: a server that accepts a token not issued for it breaks the audit trail. You cannot reconstruct Tuesday if the log belongs to someone else’s audience.
What MCP is not
It is not a moat. Competitors can attach the same open protocol.
It is not safety by itself. A protocol that can write is as dangerous as any other write API. First-party security pages exist because confused-deputy problems, token misuse, and malicious metadata URLs are in scope. The protocol catalogues those risks. It does not remove them.
It is not a model. It is not an agent runtime. An agentic workflow still needs a goal, a charter, and a ceiling. MCP is how that worker is allowed to touch the building, not a substitute for the worker definition in What is an AI agent?.
It is not a substitute for STACK. STACK is the five-layer repo architecture: structure, toolchain, agent configuration, connection, knowledge and quality. MCP sits in the connection layer, with tool contracts, hooks, and a real failure story. If your rules live in five tools and your MCP servers have no owners, you have agentic repo debt. The protocol did not cause it. The missing contract did.
A team that cannot hand work across a boundary will not be saved by a cleaner server. Coordination and connection are different jobs.
A founder review in fifteen minutes
Ask the person who “added MCP” to walk a single tool.
- Who owns this server in the repo?
- Local or remote? Whose credentials?
- What is the authority ceiling?
- What does the override doctrine forbid this tool to do?
- If it sends, spends, or deletes, who reviews the first ten calls?
- If we unplug it at 17:00, what breaks?
- Show me last Tuesday’s log for this tool.
You are not asking for a demo. You are asking for the same things you ask of a new production integration. Treat it that way and MCP becomes boring, which is the goal.
The public specification is the first-party source. The architecture page in the 2026-07-28 docs tree is where host, client, server, and primitives are defined. Re-read both before you pin a version. This page will not keep up with every wrapper.
Where this sits
The Agentic Codebase is the book that treats the agent OS as something you version like the app. The introduction is the book page. MCP is the contract on the connection. Pin a version. Re-read the first-party docs. Then make the server boring.