DroneLedger

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a hint about payload contents, but it is a cryptic field list with no clarification of what 'production' or 'operators' actually contain, no single-vs-many scoping, and no error/not-found behavior.

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, but brevity here is under-specification rather than conciseness: a verbless fragment that leads with a comma-separated attribute dump instead of front-loading what the tool does. No sentence earns its place because the core action is never stated.

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 single-parameter lookup the description omits the essential facts: that it takes one drone-type id, returns one record, and how it differs from the plural list_drone_types. With no output schema, the payload description is the only return-value signal, and it is too vague to be actionable.

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% for the single id parameter, so the description must compensate and does not — it never references the id, its slug-like pattern, or that lookup fails for unknown ids. The schema's pattern/maxLength constrain the format but the semantic meaning of the identifier is left implicit.

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 is a bare noun list ('Manufacturer, production, operators, unit-cost estimates with sources, characteristics') that never states the verb or resource — it never says it fetches a single drone type by ID. The title 'Get one drone type' carries the actual purpose, and the description does nothing to distinguish this tool from the sibling list_drone_types.

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?

There is no when-to-use guidance, no mention of prerequisites (a valid id), and no routing to alternatives such as list_drone_types for enumeration or search_incidents for related lookups. An agent gets nothing to decide between this and its siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds useful depth context — that this returns the *full* dossier including editorial history and citations — signaling completeness relative to thinner siblings. It still says nothing about missing-id behavior, auth, or response 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?

A single compact sentence/fragment with the scope signal ("Full dossier") front-loaded and zero filler. It is efficient, though the fragmentary phrasing costs a little clarity.

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 output schema, the description takes on the job of describing return contents, and it does list the dossier's sections reasonably well. However, it is silent on the one input parameter's format and on lookup-failure behavior, leaving gaps for a 1-param retrieval tool.

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% for the single required 'id' parameter, so the description must carry the burden and it does not: it never mentions that the id is a slug, its pattern, or its length limit. The agent must reverse-engineer parameter meaning entirely from the schema's regex.

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 enumerates what a dossier contains (evidence states with sources, drone types, timeline, editorial history, citation), which implies a full incident record retrieval, but it never states the verb+resource directly — "Full dossier" is a content list, not a statement of what the tool does or which incident it acts on. It also does nothing to distinguish itself from siblings like search_incidents or get_drone_type.

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 guidance on when to use this versus search_incidents (list/query) or get_drone_type. There is no statement of prerequisites, no exclusions, and no indication of when a full dossier is preferable to a lighter lookup.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful content scope (evidence states, attribution rules, source families, citation) but says nothing about whether the content is static or versioned, nor how large the response is.

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?

A single compact fragment with no filler, and the topic area is front-loaded. It is terse to the point of being a content list rather than a sentence, but nothing is wasted.

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 zero-param, no-output-schema reference tool, listing the sections the document covers is close to sufficient. Only the absence of any usage framing keeps it from being fully self-sufficient.

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?

Zero parameters, so per the rubric the baseline is 4. There is no parameter semantics for the description to add or omit.

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 title plus description make it clear this returns DroneLedger's assessment methodology rather than a data record, distinguishing it from the lookup siblings like get_incident and get_trends. It enumerates the covered sections (evidence states, attribution rules, source families, citation guidance), though it uses a noun phrase rather than a verb and never explicitly says 'returns the reference documentation'.

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 guidance on when to call this versus the data-retrieval siblings. An agent must infer that this is a reference lookup to consult when interpreting evidence states or attribution, but nothing in the text states that condition or any prerequisite.

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

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

Annotations already declare this a read-only, closed-world operation, so the bar is lower. The description nonetheless adds real behavioral context: it discloses the fixed period set (today, 7, 30, 90, 365 days), the comparison baseline, and the important caveat that results reflect archive coverage rather than all incidents worldwide.

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 no filler; the core output shape is front-loaded and the data-coverage caveat is placed where it will be read before the agent reports numbers.

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?

No output schema exists, but the description supplies the return shape (counts per period plus prior period) and the interpretation caveat, and annotations cover the safety profile. What is missing is minor: nothing about ordering, the response container, or what a 'dossier' maps to.

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?

With zero parameters, the baseline is 4. The description still earns it by enumerating the fixed period values the caller cannot control, which an agent would otherwise have to guess.

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 (dossiers/incidents) and the exact aggregation it performs — counts per period, bucketed by incident date, with the previous period of the same length. This clearly separates it from get_incident (single record) and search_incidents (listing), though it does not explicitly name those siblings.

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: the period-over-period framing signals trend analysis rather than record retrieval, and the coverage caveat hints at what conclusions the numbers cannot support. No explicit when-to-use statement or named alternative is given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and data-scope behavior is covered structurally. The description adds useful provenance context – cost figures are third-party with source, year and price basis – which is behavioral value not present in the annotations, though it omits whether the list is paginated or how complete it is.

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?

A single sentence with the core subject front-loaded ('Catalogue of drone types') and the field/cost detail packed into a compact parenthetical. Nothing is wasted, though the parenthetical is slightly dense to parse.

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 output schema and no parameters, the description must convey what a caller gets back, and it names the dimensions returned (category, origin, operators, cost estimates) plus the reliability caveat on pricing. That is sufficient for a static read-only catalogue, though an explicit note that it returns all types would make it airtight.

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?

The tool takes zero parameters, so there is no parameter semantics for the description to clarify; the baseline for a no-parameter tool is 4. The description's field enumeration is about return content, not inputs, which is appropriate here.

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 resource ('drone types') and enumerates the fields it catalogues (category, origin, operators, unit-cost estimates), so the agent knows exactly what this tool returns. It does not explicitly contrast with the sibling get_drone_type, but the plural 'catalogue' clearly implies the collection-level listing.

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?

There is no explicit statement of when to use this tool versus get_drone_type or search_incidents. The plural noun implies a bulk listing, but the agent must infer that this is the right entry point for enumerating all types rather than fetching one or searching incidents.

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

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

Annotations already declare this a safe read operation (readOnlyHint=true, openWorldHint=false), so the description doesn't need to cover safety. It does add useful behavioral context beyond the schema: filters combine conjunctively, and results are 'short summaries with URL and citation' rather than full dossiers. It says nothing about result ordering, the 50-item cap, or default limit behavior, so it is adequate rather than rich.

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?

Three short sentences with no filler, front-loaded with the core action. It is arguably too terse for a 9-parameter tool, but there is no wasted wording.

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 9 optional parameters, 4 enums, and no output schema, the description covers two of the main gaps: the return shape (short summaries with URL and citation) and filter combination. It leaves the limit cap, ordering, and the semantic distinction between drone_status and impact_status unexplained, which matters for a filter-heavy search tool.

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 56%: query, since, until, country, and corroboration are documented in the schema, while limit, category, drone_status, and impact_status are not. The description adds cross-parameter semantics ('Filters are combined') that the schema cannot express, but it supplies no meaning for the undocumented enum or limit parameters.

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 and resource ('Search published dossiers') that is clearly distinct from single-record siblings like get_incident and aggregate siblings like get_trends. It stops short of naming those alternatives, so the differentiation is inferred from the verb rather than stated.

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?

'Filters are combined' is the only usage signal, telling the agent that multiple filters AND together. There is no guidance on when to use this search versus get_incident for a known item or get_trends for aggregates, and no stated prerequisites or exclusions.

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