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

With no annotations provided, the description bears full burden for behavioral disclosure. It discloses that the tool aggregates from multiple sources, deduplicates, and ranks results. However, it does not mention potential rate limits, pagination, or what happens if no results are found, leaving some gaps.

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 two sentences, front-loaded with the typical usage pattern, and every sentence provides essential information. It is concise with no wasted words.

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 covers inputs, purpose, sources, deduplication, ranking, and the intended use case (catching up from training cutoff). This is sufficient for an agent to understand the tool's capabilities and when to invoke it.

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 75%, and the description adds context by mapping 'topic' and 'since' to the natural language example. However, it does not elaborate on 'until' or 'maxEvents' beyond what the schema already provides. The schema descriptions are adequate, so the description adds marginal value.

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 clearly states the tool's purpose: listing what's happened in a topic since a date, aggregating multiple sources (regulations, court opinions, papers, House+Senate votes), deduplicating and ranking results. This distinguishes it from sibling tools that focus on single sources (e.g., gov.house-votes, law.opinion).

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 states the tool is designed for an agent to 'catch up since its LLM training cutoff' in one call, providing clear context for when to use it. It does not explicitly state when not to use it or name alternative tools, but the use case is well-defined.

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?

No annotations provided, so description carries burden. It discloses returned data (listing + reputation stats) but omits pagination behavior (limit/offset) and read-only nature.

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 concise sentences with zero fluff. Every sentence adds value: purpose and filtering options.

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?

Given 5 parameters, no output schema, and no annotations, the description covers basic purpose and result shape but lacks pagination details and sorting behavior, leaving gaps.

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 low (20%). Description adds meaning for q (free-text), capabilities (comma-separated, ALL must match), and network, but ignores limit and offset 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?

The description clearly states the tool discovers agents in the marketplace, with filtering options. This distinguishes it from sibling tools like agent.marketplace.profile (single agent details) and agent.marketplace.register (registration).

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 implies usage for discovery via filters but does not explicitly state when to use this tool versus alternatives like agent.marketplace.profile for specific agents.

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?

No annotations are provided, so the description carries full behavioral disclosure burden. It states the output includes listing, stats, and reviews but does not mention error handling, permissions, rate limits, or what happens if the agent profile does not exist. The description is adequate but not thorough.

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 a single sentence that clearly communicates the core functionality and return components. It is concise and front-loaded with the action and resource, with no unnecessary words.

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?

Given the tool has one parameter with full schema coverage and no output schema, the description adequately covers the scope and return format. It could mention potential limitations (e.g., only 25 reviews) but overall is complete for a simple fetch 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?

The input schema already describes 'namespace' as 'Target agent pubkey.' with 100% coverage. The tool description does not add any additional meaning or context beyond the schema, so baseline score of 3 applies.

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 clearly states the action 'Fetch', the resource 'one agent's full marketplace profile', and the components 'listing + stats + up to 25 recent reviews'. It distinguishes from sibling tools like 'agent.marketplace.discover' (which presumably lists multiple) and 'agent.marketplace.review'.

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 implies usage for fetching a specific agent's profile but does not explicitly state when to use it vs. alternatives like 'agent.marketplace.discover' or when not to use it. No prerequisites or context provided.

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?

With no annotations, the description carries full burden. It mentions idempotency and uniqueness per pubkey, but lacks details on mutation behavior, required permissions, error handling, or return values. Significant gaps for a registration tool.

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 sentences are concise and front-loaded, but the terse style leaves out critical information. It is efficient but could include more detail without becoming verbose.

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?

Given the lack of annotations, output schema, and the complexity of 9 parameters with nested objects, the description is far from complete. It doesn't explain what the registration does, success/failure behavior, or prerequisites, leaving major gaps for an agent.

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 input schema has 9 parameters (3 required) with 0% schema description coverage. The description adds no explanation for any parameter, such as the meaning of 'metadata', 'payTo', 'capabilities', or 'status' enum values. This forces the agent to guess parameter semantics.

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 clearly states the action (register/update) and the target (calling agent in agent-to-agent marketplace). It adds specificity with 'one listing per pubkey' and 'idempotent', distinguishing it from siblings like discover, profile, and review.

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 implies this tool is for registering or updating your own agent listing, but does not explicitly state when to use it vs alternatives like discover or profile. No exclusions or alternative tool names are mentioned, though context provides sibling names.

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?

With no annotations, the description adds behavioral context by stating 'insert-only' and listing the outcome values and optional fields, though it lacks details on authentication, rate limits, or response 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?

A single sentence that includes the core action, constraints, and parameter summary with no redundant information.

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?

While the description covers the basic purpose and required parameters, it omits details on the response format and the exact meaning of optional fields like txHash and network, leaving gaps for an agent.

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 schema coverage is low (17%), but the description mentions rating range and lists optional fields. However, it does not explain txHash or network semantics fully, so only partial compensation.

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 uses a specific verb 'Post' and resource 'review of another agent' with the constraint 'insert-only', clearly distinguishing it from sibling tools like agent.marketplace.profile or agent.marketplace.register.

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 implies when to use the tool (for posting reviews) but does not explicitly state when not to use it or mention alternative tools for other review actions.

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?

Discloses idempotency and the specific return value for non-existent keys. This gives the agent clear knowledge of safety and outcome beyond the annotation-free context.

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 sentences, no filler, front-loaded with the action. Every word adds value.

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?

Covers essential behavior (idempotency, return shape) for a simple delete operation. Could potentially mention persistence guarantees, but adequate given the tool's simplicity.

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 0% and the description does not explain what the 'key' parameter represents or any constraints on its format. The parameter is left ambiguous, relying solely on the name.

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 explicitly states 'Delete a memory entry' with a clear verb and resource. The idempotent behavior further clarifies the action. Although it doesn't contrast with siblings like 'put', the purpose is unambiguous.

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 tool versus alternatives like 'memory.put' or 'memory.get'. The description does not mention prerequisites, exclusions, or context-specific usage.

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?

The description discloses return values (value, etag, sizeBytes, timestamps) and error conditions (404 if missing/expired). With no annotations provided, this adds valuable behavioral context beyond the input schema.

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 extremely concise with two sentences. It front-loads the primary purpose and covers key details without extraneous information.

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 simple read tool with one parameter and no output schema, the description is complete. It explains the action, return fields, and an important error condition (404). No further context is necessary.

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 description mentions 'by key,' indicating the role of the key parameter. However, it does not add additional meaning beyond what the schema provides (e.g., format, length, or constraints). With schema description coverage at 0%, the description is adequate but not richer.

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 clearly states 'Read a memory entry by key,' specifying the resource (memory entry) and action (read). It distinguishes itself from sibling tools like put, delete, and list, which have different purposes.

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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., agent.memory.list, agent.memory.put). There is no mention of when not to use it or specific prerequisites.

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?

With no annotations, the description carries the full burden. It discloses key behaviors: returns metadata only (no values), cursor-paginated ordering, optional prefix filter. It does not cover authentication, rate limits, or side effects, but as a read operation this is acceptable.

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 concise sentences front-load core purpose and ordering, then quickly cover pagination, filter, and guidance to sibling tool. No wasted words.

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?

Given no output schema, the description explains that it returns metadata and directs to another tool for values. It could be more explicit about the response fields (e.g., keys with updatedAt), but for a list tool with three parameters, it is reasonably complete.

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 67% with descriptions for all three parameters. The tool description adds 'newest-first by updatedAt' which contextualizes the order but does not elaborate on parameter semantics beyond what the schema provides. Baseline 3 is 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 description clearly states the verb 'list', the resource 'keys in memory namespace', the ordering 'newest-first by updatedAt', pagination method 'cursor-paginated', and an optional prefix filter. It distinguishes from siblings like agent.memory.get (fetch values) and agent.memory.put (store).

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 provides clear context for usage: it returns metadata only and directs to agent.memory.get for values. It implies when to use (listing keys) but does not explicitly list exclusions or prerequisites. The mention of an alternative tool enhances guidance.

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?

No annotations are provided, so the description must carry full burden. It discloses the ≤64 KiB value limit and optional TTL, but does not cover write semantics (e.g., atomicity, error conditions) or authentication details beyond the namespace.

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 concise sentences with front-loaded main action. Every sentence adds essential information without redundancy.

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?

Covers purpose, key format, value size, TTL, but does not mention return value or error handling. For a write operation with no output schema, this is acceptable but could be more complete.

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 description adds the ≤64 KiB constraint for the value parameter and clarifies 'Optional TTL' for ttlSeconds, which supplements the schema. For key and value, schema already provides descriptions, so marginal addition.

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 clearly states 'Write/replace a memory entry in the calling agent's private KV store,' specifying the verb and resource. It distinguishes from sibling tools like agent.memory.get, delete, and list.

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 mentions the namespace but does not provide explicit when-to-use or when-not-to-use guidance. It implies usage through contrast with sibling names but lacks direct alternatives or exclusions.

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?

With no annotations, the description carries full burden. It mentions using Claude Haiku and the output, but does not disclose potential delays, accuracy limitations, or side effects (though likely read-only). Adequate but not 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?

Two sentences, front-loaded with purpose, efficient with no fluff. Every word adds value.

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?

Given no output schema, the description could be more specific about what 'structured details' entails. It covers formats, size limit, and model, but omits error scenarios or access requirements beyond the schema's URI format.

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 100%, so baseline is 3. The tool description adds no additional semantics beyond the schema's parameter descriptions (e.g., 'HTTPS URL' and 'Optional focus hint').

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 clearly states the verb ('Describe'), the resource ('an image'), supported formats, size limit, and what is returned ('caption + structured details'). It is distinct from sibling AI tools like ai.screenshot or ai.extract.

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 tool versus alternatives (e.g., ai.extract for text extraction). The description implies usage for image description but does not specify exclusions or context.

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?

No annotations are provided, so the description fully bears the burden of behavioral disclosure. It mentions fetching a URL and extraction but does not disclose potential side effects, authorization needs, rate limits, or error handling, which are critical for a tool making network requests.

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 two sentences long, front-loads the action first ('Fetch a URL and extract typed data'), and contains no extraneous information. Every sentence serves a purpose.

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?

Given the tool's complexity (3 parameters, no output schema, network request), the description is too brief. It omits important context such as return format, error behavior, content type support, and any limitations, making it incomplete for an agent to use safely and effectively.

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 input schema covers 2 of 3 parameters with descriptions, and the tool description adds context that the schema is user-supplied and describes desired output. However, this adds minimal value beyond the schema itself, and the 'url' parameter lacks any description in both the schema and the tool description.

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 clearly states the tool fetches a URL and extracts typed data based on a user-supplied JSON Schema. It distinguishes itself from sibling tools by specifying a unique action of structured data extraction.

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 says 'Use when you need a structured payload conforming to your own shape,' providing clear usage context. It does not mention alternatives or when not to use, but the guidance is sufficient for basic decision-making.

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?

With no annotations, the description carries full burden. It discloses the data source (~307k US airframes, OpenSky, CC-BY-SA) and return fields (make/model/owner/operator + icao24), providing useful behavioral context beyond the schema. It does not mention error cases or rate limits, but is sufficiently transparent for a lookup tool.

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 two concise sentences with no fluff. Every sentence adds meaningful information: input constraints, return content, data source. Front-loaded with the core action and examples.

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?

Given the lack of output schema, the description covers return fields (make/model/owner/operator + icao24) and context (regional scope, data attribution). It is complete for a straightforward lookup, though missing details on error handling or authentication.

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 100%, so baseline is 3. The description adds value by explicitly stating 'Pass exactly one' and giving examples (N757F, aa3487), guiding parameter semantics beyond the schema definitions.

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 uses specific verbs ('Look up') and resources ('US-registered aircraft') with concrete examples (tail number, icao24). It clearly distinguishes from siblings like aircraft.profile by specifying the output includes icao24 for flight tracking, and targets US airframes. The purpose is unambiguous.

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 provides usage instructions ('Pass exactly one') but omits when to use this tool over alternatives like aircraft.profile or flight.status. No explicit exclusions or context for sibling differentiation, making the guidance implied rather than explicit.

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?

With no annotations, the description carries full burden. It discloses that the tool returns aircraft record plus per-name sanctions screen with confidence and flagged, and notes that name-based screening is probabilistic. However, it does not mention rate limits, permissions, or edge cases.

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 two sentences plus a contextual line, all front-loaded with the main purpose. Every sentence adds value without redundancy.

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?

Given the parameter count and no output schema, the description explains what the tool returns (aircraft record + sanctions screen with confidence/flagged) and the probabilistic nature. It is fairly complete but could elaborate on response format or confidence interpretation.

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 67% with descriptions for 'tail' and 'icao24' but not 'threshold'. The description repeats scheme info (identify by tail or icao24) but adds no new meaning beyond what's in the schema. No additional explanation for threshold or any param.

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 clearly states the tool identifies a US-registered aircraft by tail or icao24 and screens owner/operator against OFAC sanctions. It distinguishes from sibling 'aircraft.lookup' by adding sanctions screening, and specifies use cases like OSINT and asset-tracing.

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 implies when to use this tool (when both aircraft info and OFAC screening are needed) but does not explicitly state alternatives or when not to use. The mention of 'in one call' contrasts with separate calls, but no sibling names are given for exclusion.

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?

No annotations provided; the description adds useful context about data source (OurAirports, CC0 and scale (~85k airports) but does not mention error handling or behavior on invalid codes, which is acceptable for a simple lookup.

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 sentences with no wasted words, front-loading the key action and resource. Every sentence adds value.

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 tool is simple with no output schema; the description covers purpose, input format, and data source. Minor omission of error handling or return format doesn't significantly hinder completeness.

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 100%, so the schema already documents the parameter well. The description adds minimal extra meaning beyond the schema, such as the data source and code length hints.

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 uses a specific verb 'look up' and resource 'airport by IATA or ICAO code', clearly distinguishing it from sibling tools like 'airport.near' that handle geographical queries.

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 implies usage for code-based lookup but lacks explicit guidance on when not to use it or alternatives like 'airport.near' for location-based searches.

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?

The description mentions ordering by distance but does not disclose other behaviors such as response format, pagination, empty result handling, or authentication requirements. With no annotations, the description carries the full burden and falls short.

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 a single clear sentence with no fluff. It is appropriately front-loaded and efficient.

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?

Given the tool has 7 parameters, optional filters, and no output schema, the description is too sparse. It lacks information on response structure, default values, and effective use of optional filters like type and country.

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 only 29% (country and scheduled_service have descriptions). The description does not explain the purpose of lat, lon, radius_km, limit, or type, leaving the agent to rely solely on parameter names and types.

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 clearly states the tool finds airports near a coordinate, ordered by distance. This distinguishes it from the sibling tool 'airport.lookup' which likely retrieves a specific airport by identifier.

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 explicit when-to-use or when-not-to-use guidance. However, the name and description imply it is for proximity searches, contrasting with 'airport.lookup'. A note about preferring 'airport.lookup' for known codes would improve clarity.

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