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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true; "Read only; no spend" simply repeats that safety profile rather than adding to it. Nothing is said about pagination, result volume, cross-account aggregation under openWorldHint, or why a read tool carries confirm/requestId parameters. No contradiction with annotations, so not flagged, but the description earns little here.

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?

It is short and front-loads the action, which is good. But the third sentence is a wasted URI pointer that contributes nothing, and the mid-sentence caveat "no spend" is the only substantive content.

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?

With six parameters, a nested object, no output schema, and 50% schema coverage, the description needed to explain the shared-budget scope and the role of the confirmation/recovery parameters. Instead it offers a bare restatement, so an agent cannot tell from the definition what a "shared budget" is here or what comes back.

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?

At 50% schema coverage, the description must compensate for undocumented parameters (platform, accountId, parameters), and it does not. The "Fields: soclo://tools/soclo_ads_list_shared_budgets" fragment looks like it will document the fields but resolves to nothing usable, adding zero semantic meaning while implying coverage that isn't there.

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?

"List shared budgets" gives a clear verb and resource, but it is a near-verbatim restatement of the tool title, and the surrounding "Soclo Ads:" prefix plus the dangling "Fields: soclo://..." fragment add no distinguishing information. With a sibling named soclo_ads_create_shared_budget, the description never clarifies that this is the read counterpart, leaving differentiation to the name alone.

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?

"Read only; no spend" gestures at a usage context but never states when an agent should call this versus the many other listing tools or versus create_shared_budget. No prerequisites, no exclusions, no mention of what accountId scope means in practice.

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