Your Small Business Agent Does Not Need Every Tool

A developer argues that small businesses should not expose every available tool to their AI agents, but instead provide a narrow, task-specific set to reduce ambiguity and errors. The post recommends a routing layer that presents only the tools needed for a specific job, separates read and write permissions, and uses human approval for sensitive actions. It also advises versioning the exposed tool set to manage dynamic changes.

A small business usually does not need a smarter agent first. It needs an agent with fewer ways to get lost. That sounds backwards when the default pitch is “connect everything”: email, CRM, database, website, accounting, calendars, search, social, and a dozen specialist services. MCP makes those connections easier. A client can discover tools from servers instead of shipping a custom integration for each one. The temptation is to expose the whole toolbox and let the model choose. For a five-person business, that is the wrong default. The first useful agent should see a small, task-specific set of tools. It should prepare work before it performs side effects. When the tool list changes, that change should be visible and reviewable. Tool descriptions sit in the agent’s working context. A large catalogue costs tokens. The bigger cost is ambiguity. If an agent can search five systems, update three records, send messages, and edit a workflow, every request becomes a routing problem before it becomes a business problem. Familiar failure modes: The MCP tools specification supports discovery through tools/list and lets a server notify clients when the tool list changes. That is useful for growth. It also means the action surface is not static. Treat tool exposure as configuration, not a one-time onboarding step. The question is not “Can this agent access the system?” It is “Which two or three capabilities does this job need right now?” Imagine a local company that receives quote requests through a WordPress form. The owner wants an assistant to sort them each morning and prepare replies. A broad setup might expose WordPress, email, CRM, calendar, files, web search, and accounting. Plenty of options for the model. Plenty of permissions for the owner to worry about. A routed setup gives the quote-triage task only: read new quote requests lookup customer record prepare quote reply queue reply for approval The underlying services can stay the same. A routing layer presents a narrow contract for this task. Email-send is not available while the agent is classifying requests. Accounting tools are not in context at all. This is not a claim that models stop making mistakes. It makes the mistakes smaller. A wrong choice from four tools is easier to inspect than a wrong choice from forty. A useful router can select by: The router should return a tool set plus a short reason. That reason becomes part of the run record: quote triage - read quotes, lookup customer, prepare reply . The cleanest first boundary is between gathering information and changing something. A read path can collect a form submission, retrieve the matching customer record, and draft a response. A write path can create a CRM task or send an email, but only after a person approves the proposed action or a clearly defined policy allows it. That separation matters more than a clever system prompt. A prompt can say “do not send email without approval.” A permission boundary can make sending unavailable until approval exists. In an MCP system that can mean separate servers, separate credentials, or a proxy that filters tools based on workflow state. Implementation varies. The operating rule does not: do not give a classification step the ability to perform the final action. n8n’s human-in-the-loop tool patterns are a practical model here. The workflow can pause at a sensitive tool call, ask for approval in Slack/Telegram/chat, then resume with the approved action. That bridges “assistant only drafts” and “assistant runs unattended.” Dynamic discovery is useful when a business adds a service. It becomes dangerous when the tool list changes and nobody notices. Put the exposed tool set in a versioned config file, even if the underlying MCP servers are dynamic. For each workflow, record something like: workflow: morning-quote-triage allowed tools: - read new quote requests - lookup customer record - prepare quote reply - queue reply for approval blocked tools: - send email - edit wordpress - create invoice policy: approval-required-for-external-messages When a tool is added, removed, or renamed, write a small change record. Test the workflow with a fixture, then ship the new set. Ordinary release hygiene. An agent’s tool catalogue is part of its application surface. The same applies with a local model. Ollama supports tool calling, but a local model does not remove the need for boundaries. It can make the data path more private and cost more predictable. It cannot decide whether send customer email is appropriate just because the schema is valid. A useful run record does not need private customer content. Store the operational facts: That record answers the questions an owner eventually asks: Why that action? Which tools were available? Did a person approve it? Was the failure in the model, the router, or the downstream service? Do not log full email threads or customer records by default. Prefer identifiers, hashes, and small redacted summaries. Debug the workflow without creating a second copy of the business’s sensitive data. Start with one repetitive workflow that has a clear finish line. Quote triage, appointment requests, or a daily content queue beat “run the business.” Day one: write the desired outcome and the actions that stay human-approved. Day two: expose only read and draft tools; run a few representative examples. Day three: add the approval queue and a receipt record. Then measure the boring things: time saved, wrong classifications, approval turnaround, failed tool calls. If the workflow is reliable, add one capability at a time. If it is not, shrink the tool set before you change the model. That last step is easy to skip. People often respond to bad choices with another instruction, another retrieval step, or a larger model. Sometimes the fix is removing seven tools the task never needed. MCP makes connected tools easier to build. Good routing makes them easier to operate. For a small business, the practical win is not an agent that can do everything. It is an assistant with just enough access to finish one job, that asks before it crosses a boundary, and leaves evidence when something goes wrong. notifications/tools/list changed