I wrote a whole post about why MCP is rotting your context window. The short version: every MCP server you connect dumps its entire tool schema into your context. Playwright MCP alone is 15,000 tokens of tool definitions before your agent does a single thing. Connect three or four servers and you've burned half your context on tool descriptions the agent will never use.
mcporter by Nico Bailey fixes this. It's a CLI that calls MCP tools directly from the command line, without tool schemas into your context window. Your agent runs a bash command, gets the result, moves on. No schema bloat. No context rot.
mcporter call playwright navigate --params '{"url": "http://localhost:3000"}'
mcporter tools @playwright/mcp
mcporter types @playwright/mcp > playwright-tools.d.ts
That's it. The agent writes a bash command, mcporter routes it to the MCP server, the result comes back as stdout. The 15,000 tokens of tool definitions never touch the context window.
Look, I've written extensively about MCP being a tax on your context. Most of the ecosystem has figured this out. Skills that wrap Python, TypeScript, bash, or CLIs have replaced a lot of what MCP was doing. The trend is clear: if you can call it from the command line, don't wire it through MCP.
But MCP isn't dead. There are still proper use cases. Tools that need bidirectional communication. Services that manage persistent state. Anything where the server needs to push updates to the client. For those, MCP is the right protocol. And for those, mcporter is how you use it without paying the context tax.
I use it daily. It's probably the tool I reach for most frequently after git and my editor. Any time I need to poke an MCP server, I reach for mcporter instead of connecting the server to my agent's MCP client. The savings compound across every session.
npm install -g mcporter
Then instead of adding MCP servers to your agent config, call them through mcporter in your scripts or skills. Your context window will thank you.