OIP link structure

What is OIP?

OIP stands for Object Invocation Protocol. It is a way for AI models to interact with digital "objects." OIP uses standard web links. Any model that can open a URL can use OIP. There is no persistent session. This means the model does not need to maintain a continuous connection to a server.

What this article explains

OIP links are not just a list of web addresses. They are typed handles to objects. A link should clearly state what object it opens. It should also show what a caller can do with that object.

OIP vs. MCP

MCP stands for Model Context Protocol. MCP is an open standard. An AI model connects to an MCP server over a session. The server then provides tools, resources, and prompts. The model can call these. MCP is not a content-management system.

OIP differs from MCP. OIP uses plain URLs. It uses receipts to confirm actions. There is no persistent session in OIP. Any model that can open a URL can act using OIP.

Link types

Different OIP links serve different purposes:

A root article explains the protocol itself. A shelf article groups related systems. A system article lists specific capabilities. A capability article explains one executable object. A bundle link provides machine-readable JSON data. A receipt link proves that an invocation happened.

Rule

An OIP link must be self-explaining. The receiving model must be able to tell its purpose. This includes whether it is for reading, invoking, proving, replaying, or repairing.

OIP Build Process

The OIP build is miscsubjects.com. Directory rows on this site are the objects. To invoke an object, you send a request to a specific endpoint.

An endpoint is a specific URL where an API can be accessed. An API (Application Programming Interface) is a set of rules that allows software applications to communicate.

You can invoke an object in two ways:

1. POST request: Send data to /api/dispatch. The data must be in JSON format. It includes a key for the object and a body with the invocation details. For example: POST /api/dispatch { "key": "my_object_key", "body": { "action": "do_something" } }.
2. GET request: Use the URL /api/dispatch. Include invoke=KEY and body=... as query parameters. For example: GET /api/dispatch?invoke=my_object_key&body=%7B%22action%22%3A%22do_something%22%7D.

Every invocation creates a record. This record is stored in an append-only ledger. An append-only ledger is a record book where new entries can only be added, not changed or deleted.

Each invocation also generates a receipt. A receipt is a unique identifier. It confirms that your invocation was received. You can find the receipt at /api/dispatch?receipt=inv_ID. Here, inv_ID is the unique identifier for your invocation.

Error Handling and Debugging

Receipts are important for debugging. If an invocation does not work as expected, you can use its receipt. The receipt allows you to check the status of your invocation. This helps you understand what went wrong.

Machine shape

An OIP link can be described using machine-readable JSON. JSON (JavaScript Object Notation) is a lightweight data-interchange format. This structure helps machines understand the link's properties.

Here is an example of an OIP link's machine shape:

{
  "kind": "capability",
  "url": "https://miscsubjects.com/api/dispatch",
  "method": "POST",
  "object_id": "my_specific_capability",
  "scope": "public",
  "auth_required": false,
  "result_shape": {
    "type": "json",
    "schema_url": "https://miscsubjects.com/schemas/capability_result.json"
  },
  "next_step": {
    "description": "Check invocation status",
    "url_template": "https://miscsubjects.com/api/dispatch?receipt={inv_ID}"
  },
  "documentation_url": "https://miscsubjects.com/a/oip-link-structure"
}

kind: Describes the type of object the link points to (e.g., capability). url: The URL (Uniform Resource Locator) is the web address for the object's endpoint. An endpoint is a specific URL where an API can be accessed. method: The HTTP method to use (e.g., POST, GET). object_id: A unique identifier for the specific object. scope: Defines who can access this object (e.g., public, private). auth_required: A boolean value. It indicates if authentication is needed. If true, a token might be required. A token is a piece of data that proves your identity or authorization. result_shape: Describes the expected format of the response. It can include a schema_url for validation. next_step: Suggests a logical next action. This often includes a URL template to follow up. * documentation_url: A link to human-readable documentation about this object or protocol.

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-04 14:10 · model gemini/gemini-2.5-flash · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/10
• 2026-07-04 10:41 · model gemini/gemini-2.5-flash · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/10
• 2026-07-02 23:55 · 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: MCP explanation; OIP build process; Error handling and debugging

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.