OIP and MCP: Protocol Comparison for GitHub Operations

What is OIP?

The Object Invocation Protocol (OIP) specifies a universal method for invoking work objects. The OIP unit is the work object. The OIP proof is the receipt. The OIP loop is object, invoke, ledger, receipt, replay, repair.

An Object is a named, addressable unit of work. A Directory Row is a Uniform Resource Locator (URL) that describes an object, including its input schema and invocation method. Dispatch is the act of invoking an object via the /api/dispatch route. A Ledger is an append-only record of all object invocations. A Receipt is a proof of invocation, returned by /api/dispatch?receipt=inv_ID, containing the full request, response, and a proof.ok status. An Invocation is the act of requesting an object to perform its defined work. Replay is the mechanism to re-execute a past invocation using its receipt. Repair is the mechanism to correct or modify a past invocation, typically by replaying with adjusted parameters.

OIP specifies object invocation via POST /api/dispatch {key, body} or GET /api/dispatch?invoke=KEY&body=.... Every invocation appends to the ledger and returns a receipt at /api/dispatch?receipt=inv_ID.

What is MCP?

The Model Context Protocol (MCP) specifies how a model connects to a server that exposes tools, resources, and prompts over a session. MCP runs JSON-RPC 2.0 (JavaScript Object Notation - Remote Procedure Call) over a session, which can be standard input/output (stdio) or Hypertext Transfer Protocol (HTTP). MCP defines operations for handshake, tool listing, and tool calling. An MCP tool descriptor specifies the tool's name, description, and input schema.

OIP and MCP: GitHub Issue Creation

This section details the end-to-end mechanism for creating a GitHub issue using both MCP and OIP.

MCP GitHub: Mechanism

MCP requires a session for communication. The model first performs a handshake to establish the session:

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

After handshake, the model requests a list of available tools:

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

The server responds with tool descriptors. A create_issue tool descriptor specifies its properties:

{"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 perform the create_issue operation, the model sends an invocation request:

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

Upon successful execution, the server returns a result containing content blocks:

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

OIP GitHub: Mechanism

OIP operates without a session. The directory row for an object serves as its tool descriptor, discoverable by Uniform Resource Locator (URL). An Application Programming Interface (API) client, such as a Command Line Interface (CLI) tool, discovers the GITHUB_CREATE_ISSUE object:

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

The invocation of the GITHUB_CREATE_ISSUE object is a single Hypertext Transfer Protocol (HTTP) call. The share parameter provides an authentication token, establishing the token boundary for authorization:

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

The OIP response includes invocation.invocation_id, a receipt Uniform Resource Locator (URL) at /api/dispatch?receipt=inv_ID, proof.ok computed from the real result, and links for replay and repair. This constitutes the OIP proof, enabling the OIP loop of object, invoke, ledger, receipt, replay, repair.

Protocol Comparison: OIP and MCP Properties

OIP and MCP provide distinct properties for tool invocation:

Session Requirement: MCP requires a session, established via a handshake. OIP operates without a session, with each invocation being stateless. Client Protocol: MCP requires a client that speaks JSON-RPC 2.0. OIP requires a client capable of issuing HTTP requests (GET or POST) to a Uniform Resource Locator (URL). Invocation Proof: MCP does not provide protocol-level receipts or replayability. OIP appends every invocation to an immutable ledger and returns a receipt, enabling replay and repair. Tool/Object Catalog Scope: MCP tool lists are internal to a single server instance. The OIP directory is a unified catalog across all OIP runners, including shell, HTTP, models, agents, and devices. * Authentication Token Boundary: MCP authentication is typically session-bound. OIP authentication tokens are passed per invocation via the share parameter, defining the token boundary for authorization.

Receipt Rule

An OIP invocation of GITHUB_CREATE_ISSUE via /api/dispatch returns a receipt at /api/dispatch?receipt=inv_ID. This receipt contains the full invocation request, the object's response, and a proof.ok field. A proof.ok value of true indicates successful execution of the GitHub issue creation.

Conformance Rule

An OIP client conforms to the GITHUB_CREATE_ISSUE object specification by constructing a GET or POST request to /api/dispatch with invoke=GITHUB_CREATE_ISSUE, a body parameter containing owner|repo|title|body (where body is optional), and a valid share token. The client processes the returned receipt, verifying proof.ok for successful operation and utilizing invocation.invocation_id for subsequent replay or repair actions.

See both catalogs live

The build's GitHub objects: OIP system: GITHUB. This Uniform Resource Locator (URL) displays the OIP GitHub system objects.

The full tree: curl 'https://miscsubjects.com/api/dispatch?map=1&format=markdown'. This command retrieves the complete OIP directory map.

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-05 19:31 · model gemini/gemini-2.5-flash · PASS · JSON 9/10 · English 9/10 · zero-context human 8/10

- gaps named: OIP Token Minting/Acquisition: How to obtain the <TOKEN> for the share parameter.; OIP Body Parameter Schema: Explicit schema definition for the body parameter (e.g., owner|repo|title|body) for OIP objects, similar to MCP's inputSchema.; OIP Scoped Capabilities: A more detailed explanation of what "scoped capability tokens" mean and how they function.

• 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.