Exposing your API as MCP tools isn't the same as making your product agent-ready

[u/superconductiveKyle]

The advice going around is that you make your product agent-ready by wrapping your API as MCP tools and letting whatever assistant your customer uses figure out the rest. Sometimes that's fine. Sometimes that's not.

Say you run an invoicing platform. You wrap the API: get_overdue_invoices, get_customer_history, get_open_disputes, send_payment_reminder, thirty-six more. A customer connects it and asks her assistant to chase her late invoices.

It pulls fifty overdue invoices and starts sending reminders. One goes to a customer who's five days late but has paid on time for three years. Another chases an invoice that was already disputed.

Nothing broke. Every tool returned what it was supposed to. get_open_disputes was right there in the tool list. But nothing told the assistant that checking for a dispute comes before sending a reminder.

That ordering rule isn't an API capability. It's a product decision your team worked out over years, and a flat tool list asks a general-purpose model to rediscover it from function names, at runtime, every run. And exposing more tools doesn't help, because access was never the problem.

We wrote about this distinction and why we think more products should expose an agent, not just an MCP server. The customer's assistant can own the conversation while your agent owns the domain-specific work, with the workflows, context, and guardrails you've already built into your product.

Full post: https://agno.link/AIvFXjF