What a model sees: MCP Stripe vs the OIP directory

The question this answers

When a model connects to Stripe's MCP (Model Context Protocol) server, what is on the wire, and how would the same capability look as OIP directory rows?

MCP Stripe: the wire exchange

After the JSON-RPC handshake (same shape as any MCP server — see What a model sees: MCP GitHub), tools/list returns Stripe tool descriptors such as:

{"name":"create_payment_link",
 "description":"Create a payment link in Stripe",
 "inputSchema":{"type":"object","properties":{
   "price":{"type":"string","description":"price ID"},
   "quantity":{"type":"integer"}},
   "required":["price","quantity"]}}

The call:

{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{
  "name":"create_payment_link",
  "arguments":{"price":"price_123","quantity":1}}}

The Stripe API key lives in the MCP server's environment. The model never sees it — but the model also gets EVERY tool the server exposes, all or nothing, for the whole session.

The same capability as OIP rows

In OIP each Stripe operation would be one directory row (STRIPE_CREATE_PAYMENT_LINK, STRIPE_LIST_PRODUCTS, ...) with the key held in the row's auth field, redacted in every ledger entry. The difference that matters is scoping: a capability token can be minted for exactly one row —

curl -H 'x-terminal-key: <KEY>' 'https://miscsubjects.com/api/dispatch?mint_share=1&scope=row&key=STRIPE_LIST_PRODUCTS&ttl=600&uses=3'

— so a model handed that link can list products three times for ten minutes and can do NOTHING else. Not create charges, not read customers. MCP has no per-tool, per-caller, time-boxed grant like this; its unit of trust is the whole server connection.

Standing rule on this build

Stripe rows on this build are read-only by standing order: GET operations only, no POST/PATCH/DELETE without explicit instruction. Every read still produces a receipt in the append-only ledger.

The honest comparison

MCP's strength: a standard adopter ecosystem — one client speaks to many vendors' servers. OIP's strength: receipts, replay, repair, least-privilege per-object tokens, and URL-only operation. They are not enemies; an OIP row can wrap an MCP server, and the OIP tree documents MCP itself: What is MCP.

Latest clarity reviews (live)

Fresh models are sent this article's bundle and asked two separate questions: how clear is the machine JSON, and how clear is the English body. Scores are 0 to 10. The full history is in the append-only ledger.

• 2026-07-03 02:22 · model gemini/gemini-2.5-flash · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/10

- gaps named: JSON-RPC Protocol (as a foundational concept, not just linked to MCP GitHub); Secure Credential Management in OIP (how API keys are stored, redacted, and managed within OIP's auth fields)

• 2026-07-03 02:21 · model @cf/meta/llama-3.3-70b-instruct-fp8-fast · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 6/10

- gaps named: Detailed explanation of MCP; In-depth comparison of OIP and MCP

How the loop self-corrects: a failing review queues a model revision of this article (a new append-only version). A missing concept named by a reviewer queues a brand-new machine-written article, which then enters the same review cycle.