OIP build overview

Introduction to OIP

OIP (Object Invocation Protocol) helps objects work together. It provides a standard way to describe, invoke, and replay objects. This makes building and maintaining complex systems easier. OIP enables objects to interact in a standard way. This builds robust and scalable systems.

What this article explains

This article explains the miscsubjects.com build as one object system. Site parts like APIs (Application Programming Interfaces), directory rows, prompts, files, ledgers, tools, model calls, self-tests, and the deploy path are all objects. These objects can be described, invoked, proven, replayed, or repaired. A server is a computer that hosts these objects. It provides access through APIs. A token is a unique code. It authenticates and authorizes access to these objects. An endpoint is a specific URL (Uniform Resource Locator). An API uses it to interact with an object.

The whole shape

A caller asks for work. OIP finds the right object. A directory row explains the object. Dispatch runs the object. This happens through the /api/dispatch route. You can use a POST request to /api/dispatch. Send {key, body} in the request. Or you can use a GET request. Send /api/dispatch?invoke=KEY&body=.... A runner does the real work. The ledger records the request and response. It uses JSON (JavaScript Object Notation) format. Every invocation lands in this append-only ledger. A receipt proves what happened. You can find the receipt at /api/dispatch?receipt=inv_ID.

MCP explanation

MCP (Model Context Protocol) is an open standard. An AI model connects to an MCP server over a session. The server exposes tools, resources, and prompts. The AI model can call these. MCP is NOT a content-management system. It provides a rich context for AI models. MCP allows AI models to access specific tools and information during a session. This includes data, models, and computing resources. MCP also provides a dynamic environment. AI models can adapt to changing conditions and learn from experience within this environment.

OIP and MCP differ in their approach. OIP uses plain URLs and receipts. It has no persistent session. Any model that can open a URL can act with OIP. MCP uses a session-based approach. It maintains a continuous connection between the model and the server. OIP focuses on object invocation and interoperability. MCP focuses on providing a dynamic environment for AI models. OIP allows objects to be described, invoked, replayed, and repaired. MCP allows AI models to access specific tools and information during a session.

Why this matters

A model with zero context should not guess how the build works. It should read the object. It should run the exact invocation. This can be done through a CLI (Command-Line Interface) or a REST (Representational State of Resource) API. Then, it should report the receipt. That is the build's operating loop. The build operation can be performed using curl.

To invoke an object with POST:

curl -X POST https://miscsubjects.com/api/dispatch \
     -H "Content-Type: application/json" \
     -d '{ "key": "object_key", "body": "invocation_body" }'

To invoke an object with GET:

curl "https://miscsubjects.com/api/dispatch?invoke=object_key&body=invocation_body"

After invocation, you can check the receipt. Use the invocation ID (inv_ID) from the response:

curl "https://miscsubjects.com/api/dispatch?receipt=inv_ID"

Relationship between OIP and MCP

OIP and MCP are related but distinct protocols. OIP focuses on object invocation and interoperability. MCP focuses on providing a contextual environment for AI models. While they have different focuses, they can be used together. OIP can manage the invocation of objects. MCP can provide the AI model with the necessary tools and prompts to interact with those objects. For more information on MCP, see the OIP MCP explanation article.

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 00:21 · 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 MCP explanation; OIP and MCP differences

• 2026-07-02 23:29 · 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 MCP explanation; OIP and MCP differences

• 2026-07-02 23:15 · 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 MCP explanation; OIP and MCP differences

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.