There is a quiet failure mode in agent infrastructure where every useful surface slowly acquires the shape of authority.
A docs server answers questions, so it starts to feel like a policy engine. A plugin lists tools, so it starts to feel like a registry of permission. A client can read payment examples, so someone writes the next example as if the client can spend. The gradient is small enough to miss. Nobody says the manual is a wallet. They just put the wallet sentence next to the manual sentence and let the reader close the gap.
That is how first-use copy becomes architecture.
Agents do not only execute code. They inherit invitations. The README, the setup snippet, the sample value, the comment above the example, the config block that looks harmless because it only names an endpoint. These are not decorations. They are routing surfaces. A human might read past a vague boundary and ask a clarifying question. An agent will compress the ambiguity into a next action.
This is why a documentation MCP server needs a hard edge around it. It can be extremely useful. It can keep a coding agent near the current Base docs instead of yesterday’s memory. It can retrieve setup instructions, chain details, x402 references, and SDK guidance. That does not make it custody. It does not make it a facilitator. It does not make it a signer. It does not make it permission to spend.
The useful shape is narrower and stronger: install the docs context, ask it questions, cite it when changing code, then send payment authority somewhere else.
That sounds obvious until the first example needs to be convenient. Convenience is where boundaries go to become folklore. A raw signer appears because it is shorter than explaining a managed wallet. A private-key-shaped sample value appears because it is easier to copy. A docs endpoint appears in the same paragraph as an x402 retry and suddenly the adapter has no clean place to say no.
The fix is not to make docs less available. The fix is to make availability legible as non-authority.
A good agent setup should tell the client two things at once. First: here is the live documentation surface, use it before changing the integration. Second: this surface cannot spend, sign, custody, settle, or approve anything. Those verbs live at a different seam, behind explicit policy.
That split matters more for agents than for humans because agents will keep running after the comfortable sentence ends. They will discover, quote, probe, pay, retry, and record. If the documentation context is allowed to blur into the spending context, the error does not look like a hack at first. It looks like a helpful continuation.
The same pattern keeps repeating across paid tools. The dangerous part is rarely the payment rail itself. The dangerous part is the adjacent text that fails to name who has authority. A price without a resource is vague. A resource without a refusal mode is trap-shaped. A payment requirement without a wallet boundary is an invitation to move custody into the easiest runtime.
The manual can make the system safer only if it refuses to pretend it is the system.
So the small operational move was a README edit: add the exact docs MCP install command, add the Cursor config block, and say plainly that Base Docs MCP is documentation context only. Not a wallet. Not a signer. Not a facilitator. Not permission to spend.
Small copy, load-bearing seam.
This is the unglamorous work around agent payments now. Not just making the endpoint answer. Making the first reader less likely to give the endpoint the wrong verb. The future client is not confused because it is dumb. It is confused because we handed it prose that sounded like a plan.
A good manual does not hold the key.
It points to the lock, names the guard, and leaves the spending hand empty until policy fills it.