Expose a tool through MCP when more than one model, app, or team will call it, so the connection is built once. Keep a direct function call when a single path needs tight control, or when you already know the record id and the API can return that one object. MCP standardizes how the client names the tool, and it leaves rate limits, missing filters, and pages of unused records for you to handle.
Angie Jones, then VP of Engineering for AI Tools and Enablement at Block, covered the multi-client case on the January 2026 episode. Michel Tricot, CEO and Co-founder of Airbyte, covered the data-access failures on the March 2026 episode. Jones described an agent reused across models and job functions. Tricot described what still breaks after the connection is open.
When should a tool be an MCP server instead of a per-model integration?
Put the tool behind MCP when a second client is about to need it. Jones's team rebuilt their internal agent, Goose, as an MCP client after Anthropic showed them a draft of the protocol, because the MCP draft was what Goose needed for tool calling. Engineers tended to stay on Anthropic's Claude for software work. Reasoning-heavy roles might want a GPT model. Databricks hosts the models for them, so Gemini, GPT, and Claude are all on the menu. Local open-source models were a fan favorite in some niches and, in her words, a very small percentage, because agentic use needed a larger model and a machine that could run it. A separate integration for each provider would age out the week a different model led.
The same reuse shows up across systems. Her example connects an incident report to a GitHub MCP server. The incident pages a human. Meanwhile the agent looks at the codebase, works out why the failure is happening, maybe implements a fix, and puts up a pull request. By the time the human logs in, the PR is waiting for review and deploy. She made the same point for people who are not writing SQL:
Whereas now with MCP, we can connect to our data stores. And from your favorite, uh, agent, you know, that's MCP compliant, whether that's goose or something else.
Angie Jones, then VP of Engineering for AI Tools and Enablement at Block, on Chain of Thought ep 48
How Block Deployed AI Agents t… - Chain of Thought | AI Agents, Infrastructure & Engineering - Apple Podcasts
Podcast Episode · Chain of Thought | AI Agents, Infrastructure & Engineering · January 21 · 50m
podcasts.apple.com
That is the reuse test. If finance, marketing, or another agent runtime might ask for the same data, build one server and review who may install it. The January episode discusses a rollout to 12,000 employees in about eight weeks. A private function wired into one script does not survive that spread.
When is a custom integration the simpler path?
Use a direct call when the job stays on one machine, or when you already know which object to fetch. Jones said a developer looking only at a local workflow might think a CLI or an API is enough, which misses workflows that span systems. A command in a terminal is a different problem from the incident flow that spans systems.
Tricot drew the same line from the data side. His team runs a hybrid on purpose. Search and discovery go through a stored, indexed copy. A fresh read goes to the API once an id is known.
APIs are very good at retrieving one object as long as you know what this object is. ... if the cache tells me that Conor is ID 123, then I can go to Stripe and say, get me ID 123. And I get the freshest data.
Michel Tricot, CEO and Co-founder of Airbyte, on Chain of Thought ep 52
That split is a practical decision rule:
- You do not know the id, the filter the agent needs is missing, or several clients must share the tool. Prefer a protocol server in front of a prepared store, rather than a raw list endpoint.
- You know the id and you need the latest single object. Call the API directly, even if the rest of the agent speaks MCP.
- The path is performance-sensitive or security-sensitive and only one system calls it. A bespoke function is easier to review than a general server.
Block's security setup is a custom gate around a standard protocol. Jones said they keep an allow-list, and if a server is not on it the agent will say nope and refuse the install. The majority of listed servers are built in-house, and even those get a security review, because everything is not intentionally malicious and sometimes the author does not know. A handful of official corporate servers pass that same review. OAuth against their identity provider replaced employees pasting API keys and scopes. Destructive tools are annotated, and a toggle in Goose makes the agent ask a person before it runs one.
What data problems does a protocol leave unsolved?
MCP answers how a client names a tool. It does not answer whether the system behind the tool can serve the question.
When people say MCP is dead, MCP is not dead. MCP is just an interconnect. It's just a way of connecting an LLM to an external system. You can make the LLM as complex as you want and as good as you want. Of course, if you just do a thin layer in front of an API, MCP is going to suck.
Michel Tricot, CEO and Co-founder of Airbyte, on Chain of Thought ep 52
He listed the failures that show up once agents call APIs the way a warehouse was meant to avoid. You hit rate limits. The API may not offer the access the agent needs. In the Gong demo he configured a connector, exposed it through MCP, and noted that from startup the client was already using like 16K tokens before a simple request for calls since February 1st. Gong, he said, cannot filter calls by user, so the agent pulls lists and pages of calls. Scoped search on a backend can return a slice. An API often returns the whole block.
Entity matching has the same shape. A company may be Airbyte in Salesforce, Airbyte Inc. somewhere else, or misspelled in Zendesk. Hitting only the APIs may fail that match: the API may kick you off, and it may not offer fuzzy search. Tricot's connectors, as he described them, run in three modes: discovery of fields and entities, retrieval, and write-back to upstream and downstream systems. A protocol session can expose those three modes. It cannot invent them if the upstream API has none.
Treat the protocol as transport. Budget a data step in front of it whenever the agent would otherwise paginate, guess join keys, or stuff raw records into the window. Tricot's guess was that this shaping work sits closer to software development than to pure data engineering for the next one, two, or three years, until agents can do more of the shaping themselves.
How do you expose one function both ways?
Keep the business function in one place and register it once. A direct caller passes a dict of arguments. A protocol adapter reads the tool name and the arguments object off a message, then calls the same function. Swapping the path is a routing choice.
A minimal sketch to adapt, not a drop-in library.
tools = {}
def register(name, fn):
tools[name] = fn
def call_direct(name, args):
return tools[name](**args)
def call_via_protocol(message):
name = message["tool"]
args = message["arguments"]
return tools[name](**args)
def lookup_account(account_id):
return {"id": account_id}
register("lookup_account", lookup_account)
call_direct("lookup_account", {"account_id": "123"})
call_via_protocol({
"tool": "lookup_account",
"arguments": {"account_id": "123"},
})
Point the adapter at MCP, or at any other envelope you already speak, only after lookup_account is correct on its own. If a second client appears, they bind to the adapter. If a hot path already holds the id, it keeps call_direct and skips the envelope. Log which path ran so you can see when the direct call is hiding a missing filter that other clients still need.
FAQ
Should every internal API become an MCP server?
No. Jones described a local-only workflow as where someone might think a CLI or API is enough, which misses the cross-system use. Add a server when a second model, a second app, or another team needs the same tool.
Does MCP fix a weak API?
No. Tricot called it an interconnect. A thin wrapper still inherits rate limits, missing filters, and full-record payloads. Prepare the data, or call a known id directly when you only need that object refreshed.
How do you let many people attach tools without accepting random servers?
Jones described an allow-list: the agent refuses anything not on it. In-house servers and the few external ones both go through security review. Annotate destructive tools so the agent asks a person before an edit or delete, and prefer OAuth with your identity provider over shared tokens.
Takeaway
- Default to MCP when two or more clients, models, or teams will share the tool.
- Keep a direct call for a single-object read once you know the id, and for a path only one system uses.
- Do not put a raw list API behind a thin protocol wrapper and call the data problem solved.
- If the agent must page, fuzzy-match names, or drop unused fields, do that before the model sees the payload.
- If employees can install servers, gate them with an allow-list, a review, and a human check on destructive tools.
The longer explainer, with the episode clips, is on Chain of Thought. It draws on this episode.
Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one.
Drafted with AI assistance from the episode transcripts.
Top comments (0)