Your Small Business Agent Does Not Need Every Tool

A small business typically doesn't require an ultra-capable agent with access to every tool imaginable. Instead, it benefits from an agent that has a more limited range of capabilities. The default approach of connecting everything - email, CRM, database, website, accounting, calendars, search, social media, and numerous other services - can be overwhelming for a small team.

The MCP platform addresses this issue by making it easier to connect those tools, allowing clients to discover and use them without having to integrate each one individually. However, for a five-person business, presenting an extensive toolbox to the model may not be the best default setting. A more suitable starting point is to provide a small, task-specific set of tools that are relevant to the business's immediate needs.

This approach ensures that the agent prepares work before executing any actions, and any changes to the tool list should be visible and reviewable. The challenge with a vast array of tools is that they can lead to ambiguity, as the agent may have to make routing decisions based on technical validity rather than business relevance.

This can result in the agent selecting tools that are technically sound but operationally inappropriate. For instance, a read-only request might inadvertently share context with write-capable tools, or similarly named tools might point to the wrong account or environment. Furthermore, server updates can quietly alter the agent's toolset, making it difficult to understand why a particular action was chosen.

To mitigate these risks, the MCP tools specification supports discovery through a tools/list endpoint, which notifies clients when the tool list changes. This feature is valuable for scaling the business, but it also means that the available tools are not static. Instead of treating tool exposure as a one-time onboarding task, it should be considered as configuration management.

Rather than asking "Can this agent access the system?", the more pertinent question is "Which two or three capabilities does this job require right now?" A practical example would be a local company that receives quote requests through a WordPress form. The owner wants an assistant to sort these requests each morning and prepare replies.

Instead of exposing a broad set of tools like WordPress, email, CRM, calendar, files, web search, and accounting, a more focused setup would limit the agent's capabilities to tasks like reading new quote requests, looking up customer records, preparing quote replies, and queuing replies for approval. The underlying services can remain the same, but the router presents a narrow contract for this specific task.

The router should consider factors such as the user's task, data sensitivity, whether the next step is read-only or changes state, business hours, approval policies, and how complete the request is. The router should return a tool set along with a brief rationale, which becomes part of the run record. This record should also include the reason behind the selection of tools.

Separating read and write paths is crucial. The read path can gather information, retrieve relevant data, and draft a response, while the write path can create tasks or send emails, but only after an approval step or a clearly defined policy permits it. This separation is more important than relying on clever system prompts. In an MCP system, this could mean using separate servers, credentials, or a proxy that filters tools based on the workflow state.

Regardless of the implementation, the fundamental rule remains: do not grant a classification step the ability to perform the final action. Practical models like n8n's human-in-the-loop tool patterns demonstrate this principle effectively. The workflow can pause at a sensitive tool call, ask for approval in Slack/Telegram/chat, and then resume with the approved action, striking a balance between drafting and unattended execution.

When a business adds a new service, dynamic discovery can be beneficial. However, it becomes problematic when the tool list changes without anyone noticing. To address this, the exposed tool set should be stored in a versioned config file, even if the underlying MCP servers are dynamic. For each workflow, maintain a record that includes the workflow name and version, the allowed tools, blocked tools, and the policy governing tool usage.

Whenever a tool is added, removed, or renamed, create a small change record. Perform thorough testing with a fixture before deploying the new tool set. Standard release hygiene practices should be followed. Ultimately, the tool catalogue of an agent is part of its application surface. This principle holds true even when using a local model, such as Ollama.

While local models offer more privacy and cost predictability, they do not eliminate the need for boundaries. It is still essential to define which tools are appropriate for each task, even if the model can understand valid schema definitions. Storing a record of every route taken is also beneficial. A useful run record should include operational facts such as the workflow name and version, request category, tools made available, the selected tool with redacted arguments, approval state, duration, and the final outcome, whether it was determined by the model, the router, or a downstream service.

To protect sensitive data, prefer identifiers, hashes, or small redacted summaries instead of logging full email threads or customer records. Debugging the workflow becomes more manageable without inadvertently creating duplicate copies of confidential business information. To kickstart this approach, start with one repetitive workflow that has a clear and well-defined process.