If you are building an agent in code, the framework already has a way to define a tool. A function, a schema, a docstring — three of those and your agent can do something.
So why put a gateway in the middle at all? We build one, so discount accordingly. The honest answer is that for the first few tools you should not.
What writing them yourself buys
Real things, and worth naming before arguing against them.
Exact schemas. You decide what the arguments are, what they are called, and what the description says. Models read tool descriptions the way developers read function signatures, and a tool shaped precisely for your task will beat a generic one.
Business logic in the tool. create_customer can validate against your rules,
enrich from your database and write to two systems, and the agent sees one clean
verb rather than four steps to sequence.
No indirection. When something breaks there is a stack trace in your code, not a call to a service that returned an error you have to interpret.
For the two or three tools that are your product, write them. Nothing below changes that.
What it costs at the twentieth
The trouble is that most tools in a real agent are not your product. They are Gmail, Slack, the CRM, the tracker — commodity access to systems somebody else built. And each of those brings the same tax:
- an OAuth application to register with that vendor, and re-register when their review process changes
- a token refresh loop, written again, subtly differently
- a secret to store somewhere a whole team can use safely
- a second account of the same app to route between
- rate limits and pagination, per vendor, forever
- an audit trail, if you want one, that you now write
None of it is hard. All of it is the same work per vendor, it does not compound into anything, and it is not what you set out to build.
The part frameworks genuinely do not give you
Two things, and they are the reason this comparison is not just about effort.
Enforcement. A tool you wrote can be called by your agent whenever the model decides to call it. If you want "read anything, delete nothing" you have to build that check yourself, in a place every call passes through — which is a gateway, just one you now maintain. Most hand-rolled setups never build it, and the rule stays a sentence in a system prompt, competing with the user's message and losing occasionally.
Attribution across people. Your agent runs as your service credentials. When five people use it, the vendor's logs say the service did everything. Answering "who asked for this" means building your own audit layer on top.
A gateway gives you both by construction: read/write/destructive rules checked on every call before anything reaches the vendor, blocked tools not even offered to the model, and every call logged with the tool, the arguments, the outcome and the person it acted as.
Side by side
| Tools you write | Through a gateway | |
|---|---|---|
| Schema control | Total | The vendor's shape |
| Business logic in the tool | Yes | Not the gateway's job |
| Per-vendor OAuth apps | Yours to register | Already done |
| Token refresh | Yours to write | Handled |
| Two accounts of one app | You design the routing | Addressed by suffix |
| Permission enforcement | Build it | Per app, on every call |
| Attribution | Build it | Per person, per call |
| Works in other clients | Only your agent | Any MCP client |
| Time to the twentieth tool | Twenty times the first | The same as the first |
The one that decides it
The question is not which approach is more powerful. It is which tools are actually yours.
A tool that encodes something only your company knows — your pricing rules, your data model, your definition of a qualified lead — should be code you wrote, with a schema you chose. Nobody can give you that.
A tool that reads Gmail is not yours. It is the same tool everyone builds, and building it again buys you nothing except the maintenance.
Most agents need three of the first kind and twenty of the second. The arrangement that reflects that: your own MCP server or framework tools for the three, a gateway for the twenty. An MCP client can talk to both at once, and your agent cannot tell the difference.