Start with a public lane and an account lane. Public tools can list released guides, fetch a published resource by stable ID, or run a bounded deterministic instrument. They must return only public data and should work without a token. Account tools—saved resources, private notes, connected agents, or any effect—need an authenticated resource owner, a narrowly scoped token, and a server-side ownership check on every call.
In a hypothetical authenticated service, tool names should reveal the boundary: catalog.list and guide.get are public; account.resources.list and agent.handshake.create are protected. Do not trust a client-supplied account ID, agent identity, or requested scope as authority. Validate every requested resource and permission against the authenticated principal. Resolve the principal from the validated token, bind the request to the intended resource, and return the smallest safe response. Keep public catalog discovery separate from private tool discovery so a crawler cannot infer account contents.
For HTTP MCP, follow the MCP authorization specification: protected servers use OAuth protected-resource metadata and authorization-server metadata. Use authorization code plus PKCE, exact redirect URI matching, short-lived least-privilege tokens, and no open redirects, consistent with RFC 9700. Log a receipt with tool, subject, scope, resource, result class, and time—never token values or private request bodies. Add write/effect scopes only after the read lane is independently tested.