# A pile of MCP tools is not an agent > An MCP server tells an assistant what your product can do. It can't tell it what to do. When a flat tool list breaks, and when it's enough. - Published: 2026-09-14 - Author: Cosette Cressler - Categories: Perspectives - Canonical: https://www.agno.com/articles/mcp-server-vs-agent - Markdown: https://www.agno.com/articles/mcp-server-vs-agent.md The popular advice for how to make your product agent-ready says to expose your API as MCP tools (Model Context Protocol), let the user's assistant (ChatGPT, Claude, a copilot in another product) work out the rest, and you're done. For some software that works. For most, it doesn't. Do you need an agent, or is an MCP server enough? If your product enforces rules about what should happen and in what order, an MCP server alone will break them. If it doesn't, ship the tools. An MCP server tells an agent what your product can do. It doesn't tell the agent how those capabilities fit together, which steps to take and in what order, what context matters, or what a good result looks like. The agent has to figure all of that out for itself. But your team already spent years figuring that out and building it into your product. The workflows, business logic, defaults, and guardrails that make your product useful already exist. Making your product agent-ready shouldn't mean throwing all of that away and handing an assistant a box of tools. ## What goes wrong when you expose your API as MCP tools Picture an invoicing platform. The team wraps its API as MCP tools and ships it: `get_overdue_invoices`, `get_customer_history`, `get_open_disputes`, `send_payment_reminder`, and thirty-six more. Each tool maps cleanly to an API endpoint. A user connects the server to her assistant and asks it to chase her late invoices. The assistant calls `get_overdue_invoices` and gets fifty results. It starts sending reminders. One goes to a customer who is five days late but has paid on time for three years. Another chases an invoice the customer had already disputed. The assistant never checked for the dispute. It had access to `get_open_disputes`, but nothing told it that checking for a dispute should happen before sending a reminder. She hears about both by lunchtime. Nothing broke. Every tool did exactly what it was supposed to do. The schemas validated, the calls succeeded, and the API returned the right data. The problem is that the API only describes what the product can do. It doesn't capture everything the product has learned about how and when to do it. The team knows not to chase a disputed invoice. They know five days late means something different for a customer who has paid on time for three years. They know when to send a gentle nudge, when to escalate, and when to leave someone alone. Those aren't API capabilities. They're product decisions. A flat list of MCP tools leaves that logic for someone else's assistant to figure out. ## What an MCP tool list leaves out A tool knows how to perform an action. It doesn't know whether that action makes sense right now. You're asking a general-purpose model to rediscover product rules your team already knows, from names and descriptions, while the task is running. The same problem shows up with longer tasks. Say the assistant needs seven calls to finish something and the fourth fails. Should it retry? Skip that step? Try another route? Stop and ask the user? Individual tools can't answer those questions because no individual tool owns the task. The same goes for knowing when not to act. Sometimes the right outcome is to leave an invoice alone, escalate it to a person, or ask for more information. If those decisions only exist in your product, exposing more API endpoints won't teach an outside assistant how to make them. ## More tools won't solve the problem The natural response is to expose more of the API. If the assistant missed the dispute, give it `get_open_disputes`. If it picked the wrong tone, expose more customer data. If it needs another step, add another tool. But access wasn't the problem. The assistant already had access to `get_open_disputes`. It just didn't know when it needed to use it. Adding more tools can make that problem harder. Every new tool gives the model another description to understand and another option to choose from. When dozens of tools map directly to similar API endpoints, the model has to decide not only which tools it needs, but how they relate and in what order to call them. Tool coverage and agent readiness aren't the same thing. You can expose your entire API and still leave the hardest part to the user's assistant. ## The orchestration is the product When you publish a flat list of tools, the user's assistant has to decide how to combine them. It chooses the sequence, applies the business rules, handles failures, decides when to ask for help, and determines when not to act. Those aren't implementation details. They're decisions your product already makes, and you don't have to ask someone else's assistant to recreate them from a list of API endpoints. Instead of exposing forty low-level tools, you can expose the agent that already knows how to use them. ```python invoice_agent.as_tool( name="invoice_agent", description=( "Talk to the invoicing agent. Send plain language. " "Pass session_id back to continue the conversation." ), ) ``` _That one line is the last step of a longer build. Our CEO, Ashpreet, walks through the whole thing in [How to build an agent for your product and serve it everywhere](https://www.agno.com/articles/how-to-build-an-agent-for-your-product)._ Now the user's assistant can ask your invoicing agent to "chase my late invoices." Your agent decides which invoices need attention, checks for disputes, looks at customer history, chooses the right action, handles failures, and knows when to stop. It runs on your infrastructure with the rules you've already built into the product. The user's assistant owns the conversation. Your agent owns the invoicing. That gives each side the job it knows how to do. The difference between publishing tools and publishing an agent comes down to who makes the decisions. | | MCP tools alone | An agent behind the tools | | --------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------- | | **Deciding the order** | The user's assistant infers it from tool names and descriptions, fresh on every run | Your product's rules set it, the same way every time | | **Applying business rules** | Whatever the assistant can guess from the schema | Encoded once, in the agent | | **When a step fails** | No owner of the task, so no retry or fallback logic | The agent owns the task and decides what to do next | | **Knowing when not to act** | A tool list always tries | The agent can escalate, ask, or leave it alone | | **Where the logic runs** | In someone else's assistant | On your infrastructure | ## When a flat tool list is enough None of this means every MCP server needs an agent behind it. If engineers use your product and the API itself is the product, a flat tool surface can work well. The person directing the assistant often supplies the missing judgment. A developer asking an assistant to call a CI API probably knows what should happen and can catch it when something looks wrong. Read-only tools are another good fit. Search, retrieval, and lookup tools have a smaller downside when the model makes a poor choice because they don't usually take actions on someone's behalf. Small, well-defined tool surfaces can work too. If you have five tools with obvious purposes and few rules governing how they interact, adding another orchestration layer may not buy you much. The question is whether your product knows something the user's assistant doesn't. Does it know that one action must happen before another? That a certain customer shouldn't receive a reminder? That a failed step should be retried instead of skipped? That sometimes the right answer is not to act? If those rules are part of what makes your product work, expose them with the capabilities. If they aren't, ship the tools. ## What to do about it If you've already shipped an MCP server, you don't need to start over. Keep the server, put an agent behind it, and turn the low-level tool surface into a smaller set of entry points that map to what users actually want to accomplish. Instead of asking the user's assistant to choose among forty API operations, let it hand the task to an agent that already understands your product. If you haven't built anything yet, start with the same question: what does your product know that a list of API endpoints doesn't? Build that into the agent first. Then expose the agent. [Here's what that looks like end to end](https://www.agno.com/articles/how-to-build-an-agent-for-your-product). The API gives an agent capabilities. Your product knowledge tells it what to do with them.