Your agent does not need every MCP tool, and the toolbox is the liability

A post on dev.to by sphillips1337 argues that the connect-everything default of MCP is the wrong first move for a five-person business, and that the first useful agent should see a small, task-specific set of tools instead ^[2]. That matters because the thing you are defaulting into is not capability, it is an action surface that changes without notice and a run record from which nobody can reconstruct why a given action was chosen ^[5][6].

The mechanical appeal is real. MCP lets a client discover tools from servers rather than shipping a custom integration for each one ^[1]. The cost of exposing all of them is usually described in tokens, since tool descriptions sit in the agent's working context, but the post puts the bigger cost on ambiguity ^[3]. 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 ^[4].

The failure modes are the ones you would expect from a shift roster with too many people on it: a tool that is technically valid but operationally wrong, a read-only request sharing context with write-capable tools, similarly named tools pointing at the wrong account or environment, and a server update that adds a tool and quietly changes the agent's choices ^[5]. The MCP tools specification supports discovery through tools/list and lets a server notify clients when the tool list changes, which the post reads as a reason to treat tool exposure as configuration rather than a one-time onboarding step ^[6].

The worked example is a local company taking quote requests through a WordPress form. A broad setup exposes WordPress, email, CRM, calendar, files, web search and accounting ^[7]. The routed setup for morning triage exposes four tools: read_new_quote_requests, lookup_customer_record, prepare_quote_reply, queue_reply_for_approval ^[8]. Seven service surfaces become four named tools ^[9]. The underlying services do not change; a routing layer presents a narrow contract, email-send is unavailable while the agent is classifying, and accounting is not in context at all ^[8]. The post is explicit that this does not stop models making mistakes, it makes them smaller, on the grounds that a wrong choice from four tools is easier to inspect than a wrong choice from forty ^[10].

The load-bearing boundary is between gathering information and changing something ^[13]. A prompt can say do not send email without approval; a permission boundary can make sending unavailable until approval exists ^[14]. In MCP terms that can be separate servers, separate credentials, or a proxy filtering tools by workflow state, with the operating rule that a classification step does not get the ability to perform the final action ^[15]. The post points at n8n's human-in-the-loop patterns as the practical version: pause at a sensitive tool call, ask for approval in Slack, Telegram or chat, resume with the approved action ^[16].

Two things to watch in your own setup. First, whether your router returns a reason alongside the tool set, and whether that reason lands in the run record ^[12]. Second, whether the exposed tool set lives in a versioned config file with allowed_tools and blocked_tools per workflow, so a server-side addition shows up as a diff rather than a behaviour change ^[17]. Dynamic discovery is useful when the business adds a service and dangerous when the tool list changes and nobody notices ^[18].