unifier_project_autopilot_snapshot

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

With no annotations, the description carries the full burden. It does usefully declare 'solo lectura' (read-only) and 'determinista' (deterministic/reproducible), plus that it avoids downloading full records, which substitutes for the missing readOnlyHint. However, it omits permission/auth requirements, rate-limit behavior, and any detail about the shape of the returned metrics.

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 with the core identity and the differentiator (read-only, deterministic, aggregated, comparable) front-loaded. No filler, though the second sentence is doing double duty for both purpose and rationale.

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?

For a tool with 4 parameters, 0% schema coverage, no output schema, and no annotations, the description is too thin. It leaves the meaning of source_project_id, the bps/approval_bps structuring, and the returned metric format entirely undocumented.

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% across 4 parameters, so the description must compensate. It loosely gestures at bps/approval_bps via 'BPs y aprobaciones', but project_number and source_project_id are never explained, and there is no indication of how bps/approval_bps arrays should be populated.

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?

States a specific verb+resource: a deterministic, read-only snapshot for the project Autopilot that aggregates cost, planning, BPs and approvals into stable metrics. This is a clear multi-domain aggregate, distinguishable from single-domain siblings like cost_sheet_budget or schedule_health, though it never names those siblings explicitly.

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?

Usage is only implied: 'preparadas para comparar con la ejecución anterior sin descargar registros completos' hints at using it for stable metric comparisons rather than pulling full records. There is no explicit when-to-use vs when-not, and no routing against unifier_compare_projects, which is the obvious adjacent alternative.

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