{"slug":"oip-mcp-github","title":"What a model sees: MCP GitHub vs the OIP directory","body":"## The question this answers\n\nWhen 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.\n\n## MCP GitHub: the wire exchange\n\nMCP runs JSON-RPC 2.0 over a session (stdio or HTTP). The model first performs a handshake:\n\n```json\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\n  \"protocolVersion\":\"2025-03-26\",\n  \"capabilities\":{},\n  \"clientInfo\":{\"name\":\"claude\",\"version\":\"1.0\"}}}\n```\n\nThen it asks what tools exist:\n\n```json\n{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/list\"}\n```\n\nThe server answers with tool descriptors like:\n\n```json\n{\"name\":\"create_issue\",\n \"description\":\"Create a new issue in a GitHub repository\",\n \"inputSchema\":{\"type\":\"object\",\"properties\":{\n   \"owner\":{\"type\":\"string\"},\"repo\":{\"type\":\"string\"},\n   \"title\":{\"type\":\"string\"},\"body\":{\"type\":\"string\"}},\n   \"required\":[\"owner\",\"repo\",\"title\"]}}\n```\n\nTo act, the model sends:\n\n```json\n{\"jsonrpc\":\"2.0\",\"id\":3,\"method\":\"tools/call\",\"params\":{\n  \"name\":\"create_issue\",\n  \"arguments\":{\"owner\":\"massoumicyrus\",\"repo\":\"miscsubjects-pages\",\"title\":\"Bug\",\"body\":\"Details\"}}}\n```\n\nAnd gets back content blocks: `{\"result\":{\"content\":[{\"type\":\"text\",\"text\":\"Created issue #46...\"}]}}`.\n\n## The same job through OIP\n\nNo handshake and no session. The directory row IS the tool descriptor, readable by URL:\n\n```\ncurl 'https://miscsubjects.com/api/dispatch?key=GITHUB_CREATE_ISSUE&format=markdown'\n```\n\nThe invocation is one call:\n\n```\ncurl 'https://miscsubjects.com/api/dispatch?invoke=GITHUB_CREATE_ISSUE&body=miscsubjects-pages|Bug|Details&share=<TOKEN>'\n```\n\nThe 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.\n\n## The honest comparison\n\nSame in both: a catalog of tools with input schemas; the model picks one and calls it with arguments.\n\nDifferent: 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.\n\n## See both catalogs live\n\nThe build's GitHub objects: [OIP system: GITHUB](https://miscsubjects.com/a/oip-system-github). The full tree: `curl 'https://miscsubjects.com/api/dispatch?map=1&format=markdown'`.\n## Latest clarity reviews (live)\n\nFresh 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.\n\n- 2026-07-03 02:20 · model `gemini/gemini-2.5-flash` · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/10\n  - gaps named: token boundary; receipt loop\n- 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\n  - gaps named: Detailed explanation of MCP; In-depth comparison of OIP and MCP\n\nHow 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.","register":"oip_protocol","tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","primer"],"style":{"accent":"#16324f","measure":860},"claims":[{"id":"oip-c1","tier":"system","text":"The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.","who_claims":"system/oip_articles","source_ids":["oip-s3","oip-s4"]},{"id":"oip-c2","tier":"system","text":"The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.","who_claims":"system/oip_articles","source_ids":["oip-s1"]},{"id":"oip-c3","tier":"system","text":"Every executable capability in the reference implementation is reachable as an OIP object with a human article, a machine document, invocation history, and receipt path.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s3"]},{"id":"oip-c4","tier":"system","text":"Tap & Go is the copy primitive: one drop carries credential, protocol, tree, search, execute, and receipt instructions without a separate token-map-bundle assembly step.","who_claims":"system/oip_articles","source_ids":["oip-s2"]},{"id":"oip-c5","tier":"system","text":"OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s5"]}],"sources":[{"id":"oip-s1","type":"protocol","title":"BUILD_SPEC object invocation path","url":"https://miscsubjects.com/api/file/docs/BUILD_SPEC.md","summary":"Defines directory rows, dispatch, ledger, and the escalation path for changing the build.","quote":"Run anything: POST https://miscsubjects.com/api/dispatch {key, body}","claim_ids":["oip-c2"],"link_status":"ok","hash":"oipbuildspec0001"},{"id":"oip-s2","type":"protocol","title":"Object Invocation Protocol spec","url":"https://miscsubjects.com/api/file/docs/OIP.md","summary":"Defines OIP surfaces, invariant loop, receipt/replay/repair, and invocation envelopes.","quote":"identify, explain, invoke, ledger, yield","claim_ids":["oip-c3","oip-c4","oip-c5"],"link_status":"ok","hash":"oipspec00000002"},{"id":"oip-s3","type":"protocol","title":"Live OIP capability tree","url":"https://miscsubjects.com/api/dispatch?map=1&format=markdown","summary":"Public recursive capability tree.","quote":"root > shelf > system article > capability article > receipt","claim_ids":["oip-c1","oip-c3"],"link_status":"ok","hash":"oipmap0000000002"},{"id":"oip-s4","type":"protocol","title":"Directory row documentation","url":"https://miscsubjects.com/api/dispatch?key=OIP_TREE&format=markdown","summary":"Capability articles are generated from live rows.","quote":"Machine Contract","claim_ids":["oip-c1"],"link_status":"ok","hash":"oiprow0000000003"},{"id":"oip-s5","type":"protocol","title":"Invocation ledger","url":"https://miscsubjects.com/api/invocations","summary":"Append-only invocation records and receipt links.","quote":"invocations","claim_ids":["oip-c5"],"link_status":"ok","hash":"oipinvocations0005"}],"prov":{"model":"system/oip_articles","action":"generate"}}