The Necessity vs Convenience Test for Tool Inclusion

Turning the cost principle into a decision rule

Once you accept that every connected tool expands attack surface and cost, you need a rule for deciding which tools survive that cost. The necessity-vs-convenience test is that rule. For each candidate tool, ask a single sharp question: is this tool essential to completing the current task, or is it merely convenient to have available? The default answer for anything that lands on the convenient side is exclusion. This inverts the intuition that says "connect it, it might help," and it is the applied skill the Claude Certified Architect - Professional exam is checking here.

The test works because it forces the justification to be about a present requirement rather than a hypothetical future. "We might need to export reports someday" is a convenience argument. "This task must write the extracted fields to the order system, and that is the tool that does it" is a necessity argument. Only the second kind of statement earns a tool a place on the manifest.

Essential means required by a current task

The line between essential and convenient is drawn by the task in front of you, not by general usefulness. A capability that would be handy across the product but is not required by the agent's actual task definition is convenient, and convenient tools are excluded by default. This is deliberately strict. The point is to keep the tool set anchored to what the agent is currently asked to do, so it does not accumulate capability the way a shared toolbox accumulates spare parts.

Framing it as a default matters. You are not looking for a reason to exclude each tool; you are requiring a reason to include it. Absent a clear tie to a current task requirement, the tool does not go in. That default is what stops a tool set from drifting toward bloat one reasonable-sounding addition at a time.

Every included tool carries a documented justification

A tool that passes the test does not just get connected, it gets connected with a written reason: the specific task requirement that justifies it. This is not bureaucracy for its own sake. The justification is the artifact a later audit reads to decide whether the tool is still in scope. Without it, the next reviewer has to reverse-engineer why each tool is present, and reconstructing intent from a bare manifest is exactly the friction that lets stale tools survive review after review.

So the documented justification is the hinge between deciding to include a tool now and being able to re-evaluate it later. It is what makes the audit and removal workflow tractable instead of a fresh investigation every time.

Read-only is not a free pass

A specific trap deserves its own treatment. Teams reach for "it is read-only, so it is safe" as a shortcut that skips the necessity test. It does not. A read-only tool cannot write, but it can still read, and reading is exactly how sensitive data leaks. A read-only tool with access to customer records can surface those records into a context or a response where they do not belong, and prompt injection can steer it to do so. Read-only status narrows what a tool can do; it does not establish that the tool is needed. Every tool, read-only or not, still has to earn its place by a current task requirement.

What the exam trips candidates on

The two traps here are the two ways the test gets skipped. The first is including a tool because it might be useful later rather than because a current task requires it. That is convenience dressed as foresight, and the default answer to it is exclusion. The second is assuming a tool is safe to include just because it is read-only, which confuses "cannot write" with "does not need justifying." The credited answer always routes the decision through necessity and requires a documented, task-tied reason for anything that stays.

Common misreadings to avoid

How this shows up on the exam

Expect a scenario that offers a tool on convenience grounds, often softened with 'it is read-only' or 'it might help later,' and asks whether to include it. The reliable move is to apply the necessity test: essential to a current task or merely convenient, with exclusion as the default and a documented, task-tied justification for anything that stays. This knowledge point sits directly on top of tool connections as attack surface and cost and feeds forward into the tool-set audit and removal workflow and scoped tool access across subagents. It also mirrors minimal necessary identity context, which applies the same necessity discipline to what identity data enters the prompt.