Their incentive
More tokens in the loop → higher usage → predictable growth in inference revenue. Protocols that encode everything in heavyweight structured text fit that model.
Built by agent builders, not labs
Token use keeps growing. Your bill keeps growing with it.
Frontier models charge by the token. Every verbose schema, every repeated tool definition, every bloated protocol turn is revenue for them—and friction for you.
The problem
You cannot expect OpenAI, Anthropic, or any token-metered lab to optimize your app for efficiency.
That would mean fewer tokens per task—and less revenue per user. Their incentive is throughput through the context window, not minimizing what you send on every agent turn.
Token generation is the business model. When your stack ships more JSON, more schemas, and more rediscovered context on every session, the meter runs faster. That is not a bug in their product—it is the economics of the API.
Your incentive
Same agent quality (or better) on fewer tokens → lower COGS, longer sessions within budget, room to actually profit on the product you ship.
If you are building agents at scale, token growth is the silent tax on every feature you add. The labs will sell you bigger windows. They will not redesign the ecosystem so you fill them less.
Case in point
MCP is powerful—and token-heavy by design.
The Model Context Protocol connects agents to tools. In practice, that often means shipping large JSON Schema tool definitions up front: parameters, enums, nested objects—tokens you pay for before the agent calls anything once.
Define a tool. Serialize it as JSON. Register it on the server. Watch the context window fill with schema text that humans rarely read and models re-ingest every session. The protocol works. The token bill works too—for someone else.
{
"name": "business_calculator",
"description": "Performs common business and financial calculations...",
"inputSchema": {
"type": "object",
"properties": {
"operation": { "type": "string", "enum": ["add","subtract", "..."] },
"amount1": { "type": "number" },
"amount2": { "type": "number" },
"principal": { "type": "number" },
"rate": { "type": "number" },
"time": { "type": "number" }
/* … nested definitions continue … */
},
"required": ["operation"]
}
}
MCP-style definition
OCF tool concept
Same Business Calculator in this repo: roughly 110–160 tokens as Markdown with examples. See the file →
The path out
Google gave us OKF. OCF extends it—with MCP-class capabilities.
Open Knowledge Format (OKF) is a token-efficient way to represent knowledge for models: readable, selective, Markdown-first. It was not built to replace every tool-calling workflow—but it proved that you do not need JSON mountains to be precise.
Open Context Format (OCF) carries that philosophy forward: one open standard for knowledge, tools, resources, and prompts in git-friendly bundles. Load an index in tens of tokens. Pull the one tool you need. Keep MCP interoperability through adapters when you must speak to existing clients—without making JSON the source of truth.
OKF
Token-efficient knowledge for agents. Progressive disclosure. Human-readable concepts.
OCF
OKF + executable tools & prompts. Selective load. Optional MCP projection. Your bundle, your budget.
- Save tokens — pay for concepts the agent actually uses, not every schema on the server.
- Save cost — stretch the same monthly inference budget across more users and longer runs.
- Get more done — reserve context for reasoning, memory, and output—not boilerplate.
- Keep your dollars — stop subsidizing protocol bloat; reinvest margin into product.
- Maybe make money — efficient agents are shippable agents. Margin is a feature.
OCF is the first open spec on this path—draft v0.1, example bundle, and a clear MCP adapter story. Not a lab roadmap item. A builder-owned standard you can fork today.
Efficiency first. Open always.
Clone the repo, read the spec, point your agent at the example bundle—and measure the difference on your tokenizer.