unifier_cost_sheet_budget

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

No annotations exist, so the description carries the full behavioral burden. It does disclose the operation is read-only ('solo lectura') and that it pulls in lock state, snapshots, work packages, and optional financial BPs, which is genuine context. But nothing is said about authorization requirements, shell validation failure behavior, rate limits, or result shape.

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 tight sentences that lead with the resource and its read-only nature, then layer on the chained data sources. No filler, and the most identifying information is front-loaded.

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 no annotations, no output schema, and 0% parameter coverage, the description is the only source of behavior and parameters, and it is too thin. An agent would not know what the tool returns, what the project_number format expects, or how the financial_bps array affects the result.

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?

Schema description coverage is 0%, so the description must compensate for both parameters. It alludes to the optional financial BPs ('BPs financieros opcionales') and the comparison intent ('comparar los importes'), giving a faint hint at financial_bps. But the required project_number is never explained, and the enum values (presupuesto, comprometido, coste_real, prevision, otro) are not surfaced.

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 names the resource ('Cost Sheet / presupuesto') and signals its read-only nature ('solo lectura'), which is concrete. However, the operative verb is murky: 'valida el shell y encadena estado de bloqueo, snapshots, paquetes de trabajo y BPs financieros' describes internal chaining rather than stating plainly what the tool returns. It also does not distinguish this from siblings like unifier_read_shell_360 or unifier_compare_projects.

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?

No when-to-use, when-not-to-use, or alternative tool is mentioned. An agent cannot tell from this text whether to reach for this tool versus unifier_read_shell_360, unifier_compare_projects, or a direct unifier_rest_request. Usage must be entirely inferred.

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