An MCP endpoint can respond quickly while the agent's workflow remains slow. Measuring a health request answers whether the server is reachable; it does not tell you how long it takes to create useful work, inspect evidence, or recover from a failed step.
This May 27, 2026 report establishes a narrow public-endpoint baseline for OrgX MCP. It does not establish that OrgX is faster than an issue tracker or that authenticated workflows have the same latency.
What the baseline measured
The original run came from a US development machine against the hosted OrgX MCP service, with ten requests per scenario. It reported:
| Public request | Reported p50 | Reported p95 | Reported success |
|---|---|---|---|
| Health | 23 ms | 105 ms | 100% |
| Server metadata | 26 ms | 28 ms | 100% |
| Tool discovery | 24 ms | 29 ms | 100% |
These are historical public-request measurements from one network path, not an authenticated workflow comparison.
These values describe that run and network path. Reported p50 and p95 use the harness’s nearest-rank calculation, rather than an averaged-middle median. Neither is a service-level guarantee or a current production measurement.
The archived samples and benchmark harness are in the OrgX MCP repository. At the report's release, the command was pnpm benchmark:mcp; authenticated discovery required a separately supplied token. Consult the checked-in harness for the version you evaluate, and keep credentials out of published results.
Measure the work the user needs
Suppose an illustrative planning workflow needs an initiative, related tasks, and an owner decision. Comparing one server's health check with another server's complete planning operation would not answer which workflow serves the user better.
Start both systems with the same request and authorized inputs. Define the final state before measuring: which records must exist, which links must resolve, and which work must wait for a person. Then count the calls, response bytes, retries, and elapsed time needed to reach that state.
Inspect the records too. Returning quickly with missing ownership or an unresolved persistence failure is not the same result as returning the requested work. A smaller payload may help an agent, but only if it retains the fields needed for its next action.
Acknowledgment and completion need separate clocks
The original article described a scaffold response mode that acknowledged durable hierarchy creation before later work finished. That design separates the time needed to save the structure from the time needed to assign or execute follow-up work.
The distinction matters to a caller. An acknowledgment should identify what was saved and what remains queued, blocked, or uncertain. It cannot be reported as completed agent work merely because the request returned successfully.
For a current integration, inspect the tools advertised by the installed client profile rather than relying on historical tool names from this post. Creation, launch, and human approval remain distinct operations. Measure each operation's authoritative result instead of treating an HTTP status or rendered widget as proof of completion.
What this report cannot compare
The baseline did not measure an equivalent end-to-end task across competing services. Published Linear API limits and Notion MCP tools describe their own service contracts; they are not latency measurements comparable to this table.
The earlier article's broad speed rhetoric should therefore not be read as an observed multiplier. Replacing several calls with one may remove work, but the gain depends on what the call actually accomplishes, how often it fails, and what the agent must still do afterward.
Choose one small workflow you already perform. Record the requested outcome, client and server versions, sample size, network location, and authentication scope. Measure acknowledgment and final completion separately. Preserve errors and retries, and inspect a sample of the resulting records.
Publish the raw observations alongside the summary. If the workflow has human approval, report that wait explicitly rather than hiding it inside or outside the clock to improve the headline. The next useful number is the cost and reliability of reaching the agreed final state, not another isolated fast request.