What a model sees: MCP GitHub vs the OIP directory

The question this answers

When a model connects to the official GitHub MCP (Model Context Protocol) server, what does it actually see on the wire? And what does the same job look like through OIP? Real payloads, side by side.

MCP GitHub: the wire exchange

MCP runs JSON-RPC 2.0 over a session (stdio or HTTP). The model first performs a handshake:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2025-03-26",
  "capabilities":{},
  "clientInfo":{"name":"claude","version":"1.0"}}}

Then it asks what tools exist:

{"jsonrpc":"2.0","id":2,"method":"tools/list"}

The server answers with tool descriptors like:

{"name":"create_issue",
 "description":"Create a new issue in a GitHub repository",
 "inputSchema":{"type":"object","properties":{
   "owner":{"type":"string"},"repo":{"type":"string"},
   "title":{"type":"string"},"body":{"type":"string"}},
   "required":["owner","repo","title"]}}

To act, the model sends:

{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{
  "name":"create_issue",
  "arguments":{"owner":"massoumicyrus","repo":"miscsubjects-pages","title":"Bug","body":"Details"}}}

And gets back content blocks: {"result":{"content":[{"type":"text","text":"Created issue #46..."}]}}.

The same job through OIP

No handshake and no session. The directory row IS the tool descriptor, readable by URL:

curl 'https://miscsubjects.com/api/dispatch?key=GITHUB_CREATE_ISSUE&format=markdown'

The invocation is one call:

curl 'https://miscsubjects.com/api/dispatch?invoke=GITHUB_CREATE_ISSUE&body=miscsubjects-pages|Bug|Details&share=<TOKEN>'

The response carries what MCP does not have: invocation.invocation_id, a receipt URL with the full request and response preserved forever, proof.ok computed from the real result, and replay/repair links.

The honest comparison

Same in both: a catalog of tools with input schemas; the model picks one and calls it with arguments.

Different: MCP needs a session and a client that speaks JSON-RPC — so only MCP-capable hosts can use it. OIP needs the ability to open a URL — so ANY model with web access can use it, including ones that cannot POST. MCP calls are not receipted or replayable by the protocol itself; every OIP call lands in an append-only ledger with a receipt, replay, and repair lineage. MCP tool lists live inside one server; the OIP directory is one catalog across every runner — shell, HTTP, models, agents, devices.

See both catalogs live

The build's GitHub objects: OIP system: GITHUB. The full tree: curl 'https://miscsubjects.com/api/dispatch?map=1&format=markdown'.

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:20 · model gemini/gemini-2.5-flash · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/10

- gaps named: token boundary; receipt loop

• 2026-07-03 02:19 · model @cf/meta/llama-3.3-70b-instruct-fp8-fast · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/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.