Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnly=false, destructive=false and idempotent=false, so the safety profile is covered. The description adds genuinely non-structured context — that MCP approval requirements are admin-configurable and that business workflow approvals always apply — which tells the agent the call may enter an approval flow. It does not explain what an unapproved attempt returns, hence not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action before the sibling routing and the approval caveat. Nothing is redundant, though the approval sentence is generic phrasing rather than tailored to this operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the annotations plus approval note cover the safety/workflow side. Still missing for a state-changing selection tool: whether the previous current budget is deselected, and what budgetId must reference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter, budgetId, with 0% schema description coverage, so the description carries the full burden of explaining it. It says nothing about what a budgetId identifies, where to obtain one (which list/get tool), or what happens if it belongs to another deal's budget.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Select/set') and resource ('the current budget for its deal'), and explicitly names the sibling variant it is not (set_current_site_budget). It stops short of a 5 because what 'current' selection means operationally (replacing a prior selection, affecting a single deal) is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit routing rule: site-only budgets go to set_current_site_budget, which lets an agent pick the right sibling without opening schemas. There is, however, no guidance on when this tool should not be called at all, nor prerequisites such as whether the budget must already exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.