Your customer doesn’t want your agent, they want your MCP

A little over nine months ago, I wrote Don’t Build Another Chat Box into your Product because I kept seeing people treat a chat box as their AI strategy. My advice today has a similar ring: no one wants to use your agent. I don’t want to open someone else’s chat box and explain myself again when I already have an agent that knows what I’m working on. I want to use my agent to interact with your services.

Agent-to-agent communication isn’t really part of how I work today. Maybe it will be, maybe not, but my agent talking to your API or MCP is already very real. I use Linear, Notion, and GitHub via MCP far more than I use their applications these days. I delegate work to Codex and use those products as context stores, giving my agent somewhere to find the work, the decisions around it, and the code that implements it.

I still like those products and their metaphors. Issues, projects, documents, and pull requests give the work a shape that makes sense to me, and that’s what I pay them for. I don’t think rebuilding those products is a valuable use of my time, either. AI has changed the calculus on buy versus build, but you can still spread yourself too thin. Ask me how I know. I’d rather pay for those capabilities and have my agent work with them than make every piece of my workflow another product I have to maintain.

It’s similar with the App Store analytics service I pay for. I use its MCP to build custom reports through my agent, while the service does the hard work of collecting and packaging the data. I don’t want to rebuild all that grunt work, and I don’t need another agent to tell me what it thinks I should care about. I want the data available to my agent so we can put together the report I actually need.

In some ways, it’s even better if I forget you’re there. If my agent keeps using your service to get useful work done, I’ll happily keep paying. Spending less time in your application doesn’t mean I value the product less; it might mean it’s fitting into my work better. The thing I’m paying for is still doing its job, even when I’m not looking at your interface.

That’s my bet as a builder at Tariff Code Compliance, too. Our website functions more like a showcase for the data and capabilities we expose through MCP. I want someone to look at it and think, “Wow, you have that?” or “You can do that? Let me go use their MCP.” The website gives them a way to see what’s possible, then they can take those capabilities back to the agent they already use and put them to work with the rest of their context.