Why ZCP Outperforms MCP

Figure 1. Boundary Protocol Versus Native Runtime

The architecture is intentionally split. MCP remains the outer compatibility contract; ZCP changes the native execution contract inside the same backend.

1. Problem Statement

MCP is an interoperability protocol. Its job is to let tools, resources, prompts, and transports be described in a shared way across hosts and clients. The official Python SDK reflects that goal directly: it builds tool contracts from Python function signatures and serializes them as JSON Schema.

That solves the boundary problem, but it does not solve the model execution problem. The model still pays for every visible tool, every repeated schema field, every prompt-visible result replay, and every loop where runtime state is simulated inside natural language or repeated tool polling.

The right comparison is therefore not 'which protocol can express a tool call?' Both can. The right comparison is 'what does the model need to reason over per turn?' ZCP wins only when the answer to that question becomes smaller.

2. Why ZCP Uses Fewer Tokens

Token cost comes from four recurring sources. First, the model is shown too many tools. Second, each tool is described with too much schema detail relative to the task at hand. Third, large results are replayed into later turns. Fourth, background or long-running state is not held by the runtime, so the model keeps reconstructing it through repeated calls and explanations.

The MCP default path amplifies those four costs because the public tool contract is also the default model-facing contract. `Tool.from_function(...)` creates `parameters = arg_model.model_json_schema(by_alias=True)`, `list_tools()` returns every registered tool with `input_schema` and `output_schema`, and `_handle_call_tool()` turns outputs back into `CallToolResult(content=..., structured_content=...)`.

ZCP reduces those costs by moving policy into the runtime. Tool discovery can be cut down before the first turn. Result values can be represented as `scalar` or as `handle + summary` rather than replaying full payloads. Task state can live in `TaskManager` instead of being re-encoded into prompt-visible loops. The benchmark does not need mystery once that chain is visible in code.

• Fewer visible tools means lower branch factor.
• Smaller registry subsets mean less repeated schema payload.
• Handles keep large artifacts out of subsequent turns.
• Tasks keep long-running state out of the prompt.

3. Canonical Runtime And Context Contract

The decisive ZCP move is architectural: the public MCP-compatible surface is not the native runtime. The native runtime is defined around canonical objects such as `ToolDefinition`, `SessionState`, `CallRequest`, `CallResult`, and `HandleRef` in `src/zcp/canonical_protocol.py`.

Those types store information that matters for model execution but is not central in a schema-first design: `output_mode`, `handle_kind`, `defaults`, `flags`, registry hashes, current tool subset, and live handle references. This is not a naming change. It is a different execution contract.

Because the runtime is canonical first, the same backend can be projected outward in two directions. `/mcp` preserves compatibility. `/zcp` preserves the same business logic but changes discovery, calling discipline, result shape, and state handling. That is why ZCP can keep compatibility without forcing native clients to inherit all of the compatibility surface cost.

4. JSON Schema At The Edge, Not At The Center

ZCP does not literally delete JSON Schema. It still validates arguments and can still compile strict schemas for providers such as OpenAI. The key change is that JSON Schema stops being the primary native planning artifact.

In MCP, schema generation is upstream and central. `func_metadata(...)` builds Pydantic models, `model_json_schema()` becomes the tool contract, and the default `list_tools()` response exposes those schemas directly. In other words, the same rich schema object acts as registration metadata, transport payload, and the model-facing description.

In ZCP, schema becomes one field inside a richer canonical object. `ToolDefinition` still keeps `input_schema`, but the native runtime can reason in terms of tool ids, subsets, handles, and output modes. `OpenAIStrictSchemaCompiler` is then used at the adapter boundary to compile the currently selected `RegistryView` into provider-specific strict function tools only when that provider needs it.

That is the precise meaning of 'de-centering JSON Schema'. The schema is retained for validation and adapters, but it is no longer the sole object around which the whole runtime is organized.

5. How To Read The Figures And Tables

Figure 1 is an architecture boundary diagram. It shows where compatibility lives and where optimization lives. The point of that figure is to make clear that ZCP does not fork business logic; it forks the model-facing execution contract.

Figure 2 is a causal token diagram. It traces where token cost is created: full schema exposure, broad planning, and result replay on the MCP-compatible path; filtered discovery, staged planning, and compact result propagation on the native path.

Table 1 is a token-cost source map. It is not a benchmark table. It tells you which mechanism removes which cost. Table 2 is a code-level mapping between official MCP implementation files and ZCP implementation files. Tables 3 and 4 are empirical: they show the benchmark and the tier breakdown that follow from those architectural choices.

6. Causal Mechanism

The benchmark only makes sense if the following mechanism chain is true. Each step removes one class of prompt-visible waste.

7. Code-Level Comparison

This table compares the official MCP Python SDK implementation style with the local ZCP runtime implementation. The point is not rhetoric; it is where each design places state, schemas, and planning constraints.

Table 1. Principle-Level Comparison

8. Key Code Snippets

These snippets are the shortest path to the real argument. They compare the official MCP code path to the local ZCP code path without relying on the Excel benchmark implementation itself.

class Tool(BaseModel):
    fn: Callable[..., Any] = Field(exclude=True)
    name: str = Field(description="Name of the tool")
    parameters: dict[str, Any] = Field(description="JSON schema for tool parameters")
    fn_metadata: FuncMetadata = Field(...)

    @classmethod
    def from_function(cls, fn: Callable[..., Any], ...):
        func_arg_metadata = func_metadata(fn, ...)
        parameters = func_arg_metadata.arg_model.model_json_schema(by_alias=True)
        return cls(
            fn=fn,
            name=func_name,
            parameters=parameters,
            fn_metadata=func_arg_metadata,
        )

async def _handle_call_tool(self, ctx, params) -> CallToolResult:
    result = await self.call_tool(params.name, params.arguments or {}, context)

    if isinstance(result, CallToolResult):
        return result
    if isinstance(result, tuple) and len(result) == 2:
        unstructured_content, structured_content = result
        return CallToolResult(
            content=list(unstructured_content),
            structured_content=structured_content,
        )
    return CallToolResult(content=list(result))

@dataclass
class ToolDefinition:
    tool_id: str
    alias: str
    description_short: str
    input_schema: dict[str, Any]
    output_schema: dict[str, Any] | None = None
    output_mode: Literal["handle", "scalar"] = "handle"
    handle_kind: str = "generic"
    defaults: dict[str, Any] = field(default_factory=dict)
    flags: frozenset[str] = field(default_factory=frozenset)
    metadata: dict[str, Any] = field(default_factory=dict)

@dataclass
class SessionState:
    session_id: str
    registry_hash: str = ""
    tool_subset: tuple[str, ...] = ()
    handles: dict[str, HandleRef] = field(default_factory=dict)

def _select_tools(app: FastZCP, params: dict[str, Any]) -> list[Any]:
    tools = app.tool_registry.subset().tools
    profile = _effective_tool_profile(app, params)
    include_groups = _normalize_filter_values(params.get("groups"))
    stages = _normalize_filter_values(params.get("stages"))

    if profile == app.semantic_workflow_profile:
        workflow_tools = [tool for tool in tools if app.semantic_group in _tool_groups(tool)]
        if workflow_tools:
            tools = workflow_tools

    if include_groups:
        tools = [tool for tool in tools if _tool_groups(tool) & include_groups]
    if stages:
        tools = [tool for tool in tools if _tool_stages(tool) & stages]
    return tools

def compile_openai_tools(self, session: SessionState, *, tool_subset=None, strict_mode=True):
    subset_tuple = tuple(tool_subset or ())
    registry_view = self.registry.subset(list(subset_tuple) if subset_tuple else None, limit=self.tool_limit)
    session.registry_hash = registry_view.hash
    session.tool_subset = subset_tuple

    if key not in self._tool_cache:
        tools = self.compiler.compile_registry(registry_view)
        self._tool_cache[key] = tools
    return self._tool_cache[key]

def format_registry(tools: list[ToolDefinition]) -> str:
    entries = []
    for tool in tools:
        params = ",".join(
            f"{name}:{_compact_type(schema)}"
            for name, schema in tool.input_schema.get("properties", {}).items()
        )
        entries.append(f"TOOL @{tool.tool_id} {tool.alias}({params}) -> {tool.output_mode}")
    return "\n".join(entries)

if tool.output_mode == "scalar" and (tool.inline_ok or is_scalar_value(value)):
    return CallResult(
        cid=request.cid,
        status="ok",
        scalar=value,
        summary=summary,
        meta=meta,
    )

handle = self.handle_store.create(
    kind=handle_kind,
    data=value,
    summary=summary,
    meta=meta,
)
return CallResult(
    cid=request.cid,
    status="ok",
    handle=handle,
    summary=handle.summary,
    meta=meta,
)

Figure 2. Where The Token Savings Come From

The token gain is causal: smaller registry subset, tighter calling discipline, compact result propagation, and runtime-held state.

Table 2. Overall Benchmark

Table 3. Tier Breakdown

9. Why The Tier Results Look Like This

10. Limits And Scope

• The `3.83x` headline is a published result on the current Excel workflow benchmark, not a universal theorem for every domain or model.
• ZCP's largest gains depend on using the native runtime features that make schemas peripheral rather than central: profile-based discovery, handles, tasks, and semantic tools.
• This report argues that ZCP has a stronger architectural position for model execution. It does not argue that MCP becomes useless for ecosystem interoperability.
• The fairest formulation is therefore: MCP remains the compatibility contract; ZCP becomes the more efficient execution contract.

11. Conclusion

ZCP is stronger than MCP on planning-heavy workloads because it changes the model-facing execution contract, not because it changed the transport or rewrote the backend business logic.

The official MCP code path is schema-first and compatibility-first. The ZCP code path is canonical-runtime-first: schemas remain available, but they are compiled at the edge, while the native runtime is organized around subsets, handles, output modes, and task state.

That design directly explains the benchmark. Fewer tools are visible, less schema text is repeated, large payloads stop replaying into later turns, and long-running state stops leaking back into prompt-visible loops. The result is lower token use and lower planning entropy for the same backend logic.