你的智能体默认加载所有工具 schema，该决定它能看到哪些

Before you change anything about your agent config, answer two questions:

# 1. how many prompt tokens does your harness send on a cold start?
# 2. how many of those tokens are tool schemas?
# measure with your provider tokenizer, not by counting characters.

Most teams cannot answer either question.
The reason is not that the information is hard to get.
It is that nobody decided who owns it.

On October 1, 2026, Earendil shipped Pi 1.0. The release notes list
seven additions. Two of them change a decision you probably thought was
made for you:

• Deferred tool loading
• Codemode, a JavaScript sandbox where the model composes tool calls

Both turn tool visibility into a per-tool setting. That is the whole
point of this post, and it is a bigger change than it looks.

What changed, and what did not

Pi spent a year saying it did not need MCP. The landing page said it
plainly, and the creator wrote a post arguing the protocol was
unnecessary. Then 1.0 shipped with native MCP support, and Earendil
published an explanation titled "You Said No, MCP!"

The stated reasons were that MCP had matured, and that the tool loading
work Pi needed anyway would cover MCP. The technical reason is more
useful: Pi had added deferred loading and mid-conversation system
messages, so a tool now needs metadata saying whether it is exposed to
the model directly, loaded on demand, or callable only from codemode.
A regular MCP extension cannot see enough of the tool loadout to make
that call.

So the reversal was less a change of heart than a collision between two
features that needed the same plumbing.

Why visibility is a budget decision

A tool schema is not free. It sits in the system prompt or the tool
block on every single request, including the ones where the tool is
irrelevant. Connect enough servers and the schemas alone can eat a large
share of your context window before the user has typed anything.

That cost shows up in three places.

Money. Every request pays for those tokens again.

Attention. A long tool list is noise the model has to read past on
every turn. More tools means more chances to pick the wrong one.

Reproducibility. When a result changes between runs, the first
suspect is often the tool set, not the model.

Pi reports a figure for its own codemode change: the changelog gives an
example of a request dropping from roughly 5,300 to 3,300 prompt
tokens, about 40 percent. That is a vendor example under one
configuration, not a benchmark. Read it as a shape, not a number.

The three exposures, and when each one is right

Pi's metadata makes a tool one of three things. The choice is yours per
tool.

Direct. The model sees the schema and calls it itself. Use this for
tools used most turns.

Deferred. The tool is declared only when the task calls for it. Use
this for the long tail: the specialist API you touch once a week.

Codemode only. The model never sees the schema. It writes code that
calls the tool inside the sandbox. Use this when the output needs
filtering before the model reads it, or when the tool is only useful in
combination with others.

The third mode is the interesting one, because it changes what reaches
the context. In Earendil's demo, a script pulls issues from a Linear MCP
server, runs a classifier over the comments, and returns a ranked list.
Hundreds of tool calls happen. The context window sees the summary.

Do the audit before you tune anything

Do not start by rearranging tools. Start by measuring.

Count the prompt tokens your harness sends on a cold start, with tools
loaded and with none. The difference is the tax. Do it with a real
request against your provider's tokenizer, not by estimating from
character counts, because a schema is mostly punctuation and your
estimate will be wrong in the direction that flatters you.

Then sort every tool into one of the three buckets, and write the list
down. The exercise is worth doing even if you never change a thing,
because the tools nobody can classify are the ones quietly inflating
the prompt.

Two questions settle most cases:

• Does the model need to choose this tool by name? If no, it belongs in codemode or deferred.
• How often is it called? Frequent means direct. Rare means deferred.

What codemode does not fix

Earendil is unusually candid about this, and you should read the caveat
before you rewrite your config around it.

The problem is largely on the server side. Many MCP servers were built
for harnesses that dump every tool schema into context, so they return
text blobs optimised for token count rather than structured data. A
harness-side sandbox changes where composition runs. It does not change
what the server puts in your context when the harness asks for tools.

Earendil's own framing is that MCP should look closer to OpenAPI with
intelligent tool discovery: structured returns, tools discoverable by
their documentation. Until that lands, you are measuring your own
servers.

So the practical order is: expose less, and where you control the
server, return structure instead of prose.

Where I am unsure

I have not run these benchmarks. The 40 percent figure is Pi's own
changelog example, and the demo numbers come from the vendor's post.
What I have done is treat the three-exposure model as a design question
worth asking, because the cost of an unnecessary schema is paid on every
request and the cost of a missing tool is paid once.

Two things I would want before trusting any of this in production: the
first request's token count from my own harness, and a before-and-after
comparison on a fixed task with the model pinned.

Sources

• Pi 1.0 release post, Earendil, October 1, 2026. https://earendil.com/posts/pi-1-0/
• You Said No, MCP!, Earendil engineering blog, late September 2026. https://earendil.com/posts/you-said-no-mcp/
• Pi 1.0 release guide, Developers Digest, October 2, 2026. Secondary coverage; used for the install commands and the credential-per-server detail.
• The Register, coverage of the MCP reversal, October 2, 2026.

This post was written with AI assistance. The author is responsible for its content.

The permission half of the same decision

Visibility and authority are not the same thing, and a release can move
both at once.

Pi 1.0 also hardened OAuth for MCP: credentials are stored per server
name and URL, issuer checks follow RFC 9207, and step-up sign-in
preserves the scopes a server was already granted. Those are real
improvements, and they are authentication measures. They do not tell you
whether a given connector is trustworthy, and they do not stop a model
from acting on hostile instructions that arrive inside a tool result.

Treat the two separately in your own review. Ask, per server: what is
this allowed to reach, and who approved installing it. A connector you
enabled for a narrow read is still a connector the model can call.

This is also why "expose less" is a safety measure and not only a cost

One more thing worth writing down: the audit has a second output. Once
the tools are sorted, the shape of your own usage is visible, and that
tells you which single tool to fix first. On most teams it is not the
model. It is the one connector added for a deadline, still enabled,
still loading its schema, rarely used.
measure. A tool the model cannot see is a tool it cannot choose to call
by mistake.