Most MCP servers are judged like APIs. Can the agent search? Create an issue? Update a page? Fetch a ticket?

That is necessary. It is not the bar.

The real question is the one no one is benchmarking:

How much durable company state does one agent tool call create — how quickly, and how reliably?

That is what OrgX optimizes for. Not "can an AI create a Jira ticket," but: can one prompt become an initiative, workstreams, milestones, tasks, decision points, launch state, a live execution surface, and proof that future agents can reuse?

When the answer is yes, the tool call stops being fast and starts being leverage.

The current public benchmark

On May 27, 2026, we ran the public OrgX MCP edge benchmark from a US development machine against https://mcp.useorgx.com.

The harness is now part of the worker repo:

pnpm benchmark:mcp

Authenticated MCP discovery is included when a token is provided:

MCP_BENCHMARK_AUTH_TOKEN=... pnpm benchmark:mcp

The benchmark writes a JSON report with p50, p95, p99, max latency, response bytes, status distribution, and success rate. The point is not to publish a single flattering run. The point is to keep publishing the same measurement as the product changes.

What competitors publish today

Competitors mostly publish capabilities and rate limits. They do not publish MCP p95 latency targets.

That matters, because agents care about price/performance differently than humans do.

A human can tolerate a slow issue page. An agent compounds every slow read, every extra payload, every retry, and every unnecessary tool call into model tokens and wall-clock delay.

That is the opening, and it is a structural one. The next great work system for agents will not win by adding another connector to a human tool. It will win by changing the unit of work itself.

Our unit of work is not a ticket

Linear's atomic unit is an issue.

Jira's atomic unit is an issue.

Notion's atomic unit is a page or database row.

OrgX's atomic unit is an initiative graph.

One OrgX MCP call can create:

• an initiative
• workstreams across product, engineering, design, marketing, sales, and ops
• milestones
• tasks
• dependencies
• decision points
• launch state
• a live view
• follow-up agent work
• telemetry that tells us whether the call was fast, reliable, and useful

That is where the 100x comes from — and it is worth being precise about what we mean, because "100x faster" is the most abused number in infrastructure marketing.

We do not mean the network is 100x faster than anyone else's network. We mean one agent call replaces the dozens of reads, writes, summaries, and coordination prompts it would otherwise take to assemble the same state across a tracker, docs, chat, and a memory store. The speedup is in the work removed, not the millisecond shaved.

The build order

The first version of scaffold_initiative already did the important thing: one call created a full hierarchy instead of making the agent stitch together records by hand.

The next version makes the response path agent-fast.

We changed the scaffold contract to support response_mode.

The default for non-draft scaffolds is now fast_ack.

That matters because the agent does not need to sit on the network while the system performs every follow-up. It needs the durable graph ID, live URL, compact hierarchy, idempotency key, and next action immediately.

The rest can run behind the response.

We also tightened the hot path around MCP requests:

• OAuth token unwrap results are cached briefly on the rate-limit path.
• Generic tool telemetry now records argument count, estimated argument bytes, response size headers, status, latency, tool family, and client context.
• Scaffold telemetry separates entity creation from queued post-create work.
• The benchmark harness is checked in and repeatable.

The product promise

The fastest MCP is not the one that returns the shortest string.

The fastest MCP is the one that makes the next tool call unnecessary.

That is why OrgX is not positioning itself as "Linear with AI" or "Notion AI with more actions."

The promise is:

Give the agent one prompt. Get back durable company state that can keep compounding after the chat ends.

That gives us three compounding loops.

1. Latency loop

Every MCP call records p50, p95, response size, success, and tool family. Slow paths become visible by tool, client, workspace, and mode. The product can keep shrinking the synchronous path instead of guessing.

2. Leverage loop

Every scaffold creates structured memory that future agents can query. A good call does not just answer the current prompt. It makes the next prompt cheaper.

3. Proof loop

Every performance claim points to a command, an artifact, or a live graph. Blog posts should cite the benchmark output, not vibes. Product pages should show work created by the system, not mock dashboards.

What we will publish next

This post is the baseline.

The next public numbers should include:

• authenticated tools/list p50/p95
• scaffold_initiative fast_ack p50/p95 on seeded workspaces
• scaffold_initiative complete p50/p95 for comparison
• tool-call count saved versus creating the same hierarchy through a tracker API
• response bytes saved by compact scaffold payloads
• retry/error rate by MCP client
• cost per durable work item created

That is the right scoreboard for agent work systems.

Speed matters. Reliability matters. Price matters.

But the metric that compounds is leverage:

How much future work did this tool call remove?

That is where OrgX can be meaningfully better than a tracker with an MCP connector.

Not another place to put work.

A faster way for agents to turn intent into a company that remembers.