Dónde y cuándo se practicó una diligencia

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description does not contradict them. It adds substantial behavioral context beyond the annotations: `existe:false` is a measured outcome distinct from not querying, `intentos` is null only when `existe` is false, and `precision_metros` must be reported alongside coordinates because it varies from 6 to 103 meters. It even discloses that the coordinates concern a third party's address, which matters for how the result should be presented.

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?

The description is long but tightly packed: every sentence contributes a distinct caveat or clarification, from the legal basis to the one-request-per-act rule to the measured precision ranges. It is front-loaded with a clear one-line purpose and then proceeds in a logical order through source, usage, failure semantics, and reporting obligations. No filler or repetition of the schema is present.

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?

The output schema exists, but the description goes further and explains the meaning and reliability of key output fields (`existe`, `intentos`, `precision_metros`) that an agent must understand to use the response correctly. It covers failure cases, rate-of-request concerns, data provenance, and privacy-sensitive handling. For a tool with this complexity, nothing important for invocation or interpretation is missing.

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 coverage is 100%, and both parameters have meaningful descriptions in the schema; the description adds no new information about `competencia` and mostly restates the `georreferencia_referencia` origin already documented in the schema. The rich caveats in the description concern output fields and usage policy, not parameter semantics. A baseline 3 is therefore appropriate.

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 opening line states exactly what the tool reports: where and when the minister of faith (ministro de fe) recorded performing a diligence. The description further distinguishes this record from the `hora_diligencia` field in the actuaciones, making its scope precise even without reading the schema. The name and title agree with the described resource.

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?

The description explicitly tells the agent when not to rely on this data ('NO reemplaza a `fecha_diligencia`') and to report discrepancies rather than choose between values. It also warns that each request is one per actuación and that requesting for all actuaciones multiplies queries, so only the relevant one should be requested. This is strong when/when-not guidance, even though it doesn't name a sibling tool.

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