One gateway for every AI assistant’s tools.

The takeaway

I connect a lot of outside systems to my AI assistants: a database, a notes vault, a ticket tracker, a design tool, and many project-specific tools with a separate MCP server for each account. The ordinary way to do that is to install each connection into each assistant, then do it again for the next assistant and again for the next project. I stopped doing that and put every connection behind one local gateway, a piece of software called Toolport, then pointed all the assistants at that one thing. As you can imagine, there are massive advantages to a system like this, but there are also some drawbacks that actually add friction, so I’ve forged a workflow by deciding which of Toolport’s pros are worth its cons.

At a glance
Role	Sole operator. Chose the gateway, configured the connections, set the access profiles, decided the security settings.
Context	Personal system, used on my own projects and on client delivery work.
Outcome	37 connections registered in one place, 23 active in the profile I work in day to day. Six folders bound to their own set of tools.

The situation

While the assistants I use can all work with the same tools, Claude keeps its connections in one place and Codex keeps them in another, and each new project can mean more new connections and more decisions about how to provision access. Every addition brings an API key to request, store, and eventually renew (or, more likely, leave wide-open and non-expiring). Then comes the familiar troubleshooting: I enabled something over here, but I’m trying to use it over there.

Each individual client project lives in its own folder, and when an AI agent works on a given project, it works inside that specific folder. The tools it could reach, though, had nothing to do with that folder. Every agent carried the same key ring, with every client’s keys on it. If you’re thinking about letting agents into your own company’s systems, that’s the first question to answer: what can it reach, and who decided?

The calls that mattered

Use a gateway instead of per-assistant installs. Every tool runs through a single local gateway, which proxies requests back and forth to the downstream tools. I used the gateway for these reasons:

• I like to try different models and switch between providers, but it is enormously frustrating to need to rebuild a workspace and maintain it several times over. The gateway eliminates that redundancy.
• When I started using Toolport, context bloat from a large number of tool definitions was a concern. That’s less true today as tool management in-platform has become more efficient and context windows have grown, but it can still be of marginal benefit.
• It lets me manage access profiles, to control different groups of servers and use multiple instances of the same server.

Access follows the folder, not the chat. Toolport allows me to tie a set of tools to a project, so an agent that opens one client’s folder picks up that client’s keys and nothing else. In other words, Client A’s agents only reach Client A’s store. Most of what I connect is shared anyway, like one Jira connection for all my agency work, but each client’s Shopify store has its own connections, and those are the keys worth keeping apart. That is the part I care about most. It means the question of what a given agent is allowed to reach has an answer that lives next to the work, rather than with an agent.

Where it landed

Working: the gateway is what my assistants talk to. It is how agents reach my notes, my tickets, my databases and my design files. I’ve also used it to bring two new providers online, first Google’s Antigravity and then OpenAI’s ChatGPT and Codex. Each one connected to Toolport once and had every downstream tool working from its first turn, with nothing to rebuild. Both times that meant more compute capacity for less money, and I could spread the load across providers to stay under quota on each.

Not proven: I have not measured whether search-on-demand makes agents slower or worse at finding the right tool than a full catalog would; I assume a cost there and have not quantified it. My agents generally perform just as well as if I didn’t have the gateway, but from time to time I need to remind an agent that Toolport exists.

What I’d do differently

I would bind every project folder from the start, including the ones with nothing to separate yet, so the rule is already in place when a project gets its own servers.

I would look closer at the server list more often than I do: one server is registered twice under two different names, 241 tools each, and I only found it while writing this.

Under the hood

This last part is detail, for anyone who wants it.

What the connections are. Each connection is an agentic method to connect to a platform: MCP is the industry standard. Sometimes I use API or CLI-based connections, possibly combined with a skill to explain to the AI how to use it.

Skills, which Toolport doesn’t cover. Toolport only manages MCP servers, and I think that’s a bummer, because skills, the files that tell an AI agent how to do something, have the same problem: every assistant expects its own copy, so changing one skill means updating it in several places. My workaround is symlinking, which, yes, Claude helped me configure. A symlink is a pointer: there’s a single central copy of each skill, and every agent’s skills folder simply points at it, so I edit a skill once and every agent picks up the change. My skills are, of course, also backed up, separately from any single platform.

What Toolport is, and what I did to it. An open-source local MCP gateway that sits between the AI clients and the servers. What I built here is the configuration and the access rules, not the software.

Scale, as configured today. 37 servers registered in total exposing over 1,000 tools between them, the largest single server accounting for 241 of them. I currently have six working directories bound to an individual profile, so the profile follows the working directory rather than the client.

Content defense in practice. When I was working with Claude on writing this piece, the chat was interrupted at one point when the gateway intercepted a tool call and returned a redaction, flagging a possible prompt injection in a structured result. The result in question was a dump of the gateway’s own configuration file, indeed a structured file that holds configuration. The protection did its job flagging it.

The decision here was not which tools to use. It was where the answer to what an agent is allowed to reach should live. I moved it out of the assistants and into one place.