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

No annotations provided, so description carries full burden. Discloses that it returns metadata (safe read operation). Could mention no side effects, but adequate.

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 action verb upfront. 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?

Given single parameter and existing output schema, description provides sufficient overview. Lists returned metadata types, adequate for agent decision-making.

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 has 0% description coverage for 'collection_id'. Description does not elaborate on parameter beyond implying it identifies a collection. Minimal added 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?

Description clearly states the action (get metadata) and lists specific metadata types (description, extent, properties, links). Distinguishes from siblings like 'list_collections' by focusing on a single collection, but does not explicitly contrast.

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?

Provides context: 'Use this before querying to understand available attributes.' No guidance on when not to use or alternatives.

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 transparency burden. It describes the tool as a query (get) without side effects, but does not explicitly state it is read-only or non-destructive. For a simple describe tool, this is adequate but could be more explicit.

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, well-structured sentence that front-loads the action and key outputs. Every word earns its place with no 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 output schema exists, the description appropriately focuses on inputs and high-level output aspects (inputs, output format, execution mode). It is complete for a simple describe tool with one parameter and no nested objects.

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 0% schema description coverage, the description must compensate. It adds context that process_id identifies the OGC Process, but lacks further details like examples, format constraints, or sources for valid IDs. This partially compensates but not fully.

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: to get a detailed description of an OGC Process, including required inputs, output format, and execution mode. It distinguishes from siblings like list_processes and describe_collection by focusing on detailed process metadata.

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 (when a detailed process description is needed) but does not explicitly state when not to use it or suggest alternatives. No exclusions or comparisons with sibling tools are 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?

No annotations are provided, so the description carries the full burden. It discloses the output format (base64-encoded PNG with SB styling including logo, legend, scale bar) and mentions default values for parameters. It does not cover error handling or rate limits, but the core behavior is transparent.

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 front-loaded with the main purpose, followed by a bulleted list of indicators, then a clear args section. It is concise with no unnecessary words. 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?

Given the presence of an output schema (indicated by context), the description complements it by explaining the return format and styling. It covers the required parameter and explains optional ones. It could mention potential errors or performance considerations, but overall it provides sufficient context for an agent to invoke the tool correctly.

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 explain parameters. It does so effectively: 'indicator' is elaborated with a list of available IDs, 'location' with examples (municipality name, province name, 'national'), 'location_type' with allowed values, and 'year' with explanation of default. This adds significant meaning beyond the schema.

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?

Clearly states the tool generates a branded SB thematic map for a location, returning a base64-encoded PNG with styling. The verb 'generate' and resource 'thematic map' are specific. It distinguishes from sibling tools by focusing on map generation with a specific set of indicators and styling.

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?

Provides a list of available indicators and explains the parameters (indicator, location, location_type, year), which helps the agent choose appropriate inputs. However, it does not explicitly state when to use this tool versus alternatives (e.g., when a thematic map is needed vs. a different type of analysis). No exclusions or when-not-to-use 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?

With no annotations, the description carries full burden. It discloses the return format (GeoJSON) and describes parameters, but lacks details on pagination behavior, error handling, or constraints beyond the limit range.

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 concise with a clear header and structured Args list. It front-loads the purpose and 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?

Given the 5-parameter complexity, no annotations, and presence of an output schema, the description covers essential aspects well. It lacks some behavioral context but is largely 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 description coverage is 0%, so the description compensates fully by providing examples and format for each parameter (e.g., bbox format, filter_param example, limit range). This adds significant meaning beyond the schema.

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 starts with 'Fetch features from a collection. Returns GeoJSON.' which clearly specifies the verb and resource, and distinguishes it from sibling tools like describe_collection and list_collections.

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 example values for collection_id but does not explicitly state when to use this tool versus alternatives like search_boundaries or other feature-retrieval tools. Usage context is implied but not 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?

No annotations are provided, so the description carries full burden. It correctly indicates a read operation and specifies the returned fields (ID, title, description), but omits any mention of authentication, rate limits, or potential side effects. For a simple list tool, this is minimally adequate.

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 wasted words. The description is front-loaded with the purpose and quickly lists return fields. Ideal conciseness.

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 parameters and an output schema, the description covers the essential behavior: listing collections with ID, title, and description. No additional information is necessary for this simple 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 tool has no parameters, so the baseline is 4. The description does not need to add param info, and it correctly omits any parameter discussion since there are none.

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 lists all available data collections with examples. It distinguishes from siblings like describe_collection or get_features by focusing on enumeration of collections rather than details of a single collection.

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 the tool is used to list collections, but it does not explicitly state when to use it versus alternatives like describe_collection or search_boundaries. No guidance on exclusions or 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?

Without annotations, the description carries the behavioral burden; it correctly implies a read-only list operation with no side effects, though it omits details like rate limits.

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 no fluff, immediately stating purpose and typical usage.

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 list tool with an output schema, the description fully covers what the tool does and why to use it, requiring no additional context.

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 and 100% schema coverage, the description adds no unnecessary information; it correctly implies no input is needed.

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 it lists all available map indicators with legends and data sources, distinguishing it from sibling tools like generate_thematic_map which creates maps.

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?

It explicitly advises use for discovering what thematic maps can be generated, providing clear context but no exclusions or alternatives.

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 accurately describes a read-only listing operation. It doesn't disclose any complex behaviors, but none are expected for a simple list.

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, informative sentence that is front-loaded and contains 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 zero parameters and an output schema present, the description fully covers what the tool does for the agent to use it correctly.

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?

No parameters exist, and schema coverage is 100% (empty schema). The description adds no param info, but baseline 4 applies due to absence of 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 lists all available OGC API Processes and provides examples (ODIN analysis, modal split, etc.), distinguishing it from sibling tools like 'describe_process'.

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 the tool is for getting an overview before using more specific tools, but lacks explicit when-to-use or when-not-to-use 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the output format (base64 PNG) and lists possible parameter values, but it does not disclose whether the tool is read-only, destructive, requires authentication, has rate limits, or any error behavior. The lack of behavioral traits beyond parameter enumeration is a significant gap.

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 structured efficiently: first a one-line summary of purpose and output, followed by a clean 'Args:' list. It front-loads essential information and uses minimal words to convey the parameter details. No redundant or filler sentences.

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 complexity (5 parameters, no output schema, no annotations), the description covers the core functionality well: purpose, output format, and all parameter details. It mentions the required condition for region_id. However, it lacks information on error handling, performance, or side effects, which could be useful for an AI agent. Overall, it is mostly complete for a map generation 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?

Despite 0% schema description coverage, the description compensates by listing all five parameters with their valid values (e.g., mode options: car_24h, cycle, walk; amenity types; map_type options; region_type; and region_id details including examples). This adds substantial meaning beyond the schema, which only provides titles and types. The description effectively tells the agent exactly what values to use.

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 generates a BOP accessibility map showing travel times to amenities and returns a base64-encoded PNG image. It uses a specific verb ('Generate') and resource ('BOP accessibility map'), and the name 'run_accessibility_map' aligns well with the purpose. The description distinguishes this tool from siblings like 'run_modal_split' or 'generate_thematic_map' by specifying the output type and focus on travel times.

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 any explicit guidance on when to use this tool versus alternatives. It only describes what it does and lists parameters. There is no mention of when not to use it, prerequisites, or comparisons to sibling tools. Usage context is only implied by the parameter options.

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?

States output is base64 PNG, but lacks detail on side effects, authentication, rate limits, or behavior if multiple location parameters are provided (e.g., both municipality and postcode). No annotation coverage to compensate.

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?

Description is concise: two sentences plus argument list. Front-loaded with purpose and output format. No unnecessary 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?

Covers purpose, output format, and parameters adequately. No output schema, so return type is specified. Missing details on error handling or constraints (e.g., only one location should be provided), but overall sufficient for a simple 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?

All 5 parameters are described with examples (e.g., municipality: 'Amsterdam') and year range (2004-2023), adding significant meaning beyond schema's type-only definitions. Schema coverage is 0%, so description compensates well.

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?

Clearly states it generates modal split analysis (Marimekko chart) for a location, with specific location parameters (municipality, postcode, province). Distinguishes from sibling tools like run_odin_* by output type and analysis focus.

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?

Implies usage for modal split analysis, but no explicit guidance on when to use versus other run tools (e.g., run_odin_query). No exclusions or alternatives mentioned.

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 full burden. It only states the basic comparison function, but does not disclose behavior on partial inputs, error handling, or whether it is read-only. Minimal transparency.

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?

Extremely concise: two sentences of purpose followed by a well-organized parameter list. No wasted words, front-loaded with the core intent.

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 all parameters and basic use case. Output schema exists so return details are not required, but a brief mention of what is returned would improve completeness. Still strong given tool complexity.

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?

Despite 0% schema description coverage, the docstring in the description lists all parameters with examples (e.g., 'Amsterdam' for municipality), adding practical meaning beyond schema titles 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?

Clearly states the verb 'compare', the resource 'ODIN travel survey data', and the action 'side-by-side' between two locations. It is specific and distinguishes from sibling tools like run_odin_profile or run_odin_spider.

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?

Provides no guidance on when to use this tool versus alternatives, such as other ODIN tools or when not to use it. Lacks context for selection among 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?

No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention that the tool is read-only, what the output format is, or what happens when multiple location filters are combined. Without these details, an agent may misuse or misinterpret results.

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 highly concise: a single sentence for purpose, a brief cluster list, data source statement, and a structured Args section. No redundant or vague sentences. The most important 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?

The tool has an output schema (not shown), so return values need not be described. The description covers parameters, data source, and cluster semantics. It lacks any mention of optional vs required filter behavior, but overall it is sufficiently complete for a profiling tool with good schema coverage.

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 zero parameter descriptions, but the description's Args section adds meaningful context: example values for location filters, explicit year range (2004-2023), and cluster_id meaning (0-6 with labels). This compensates well, though it lacks explanation of filter interplay.

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 with a specific verb ('Profile respondent mobility behaviour using 7 data-driven clusters') and immediately lists the clusters, leaving no ambiguity about what the tool does. It is distinct from sibling tools like 'run_odin_query' which imply different operations.

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 contexts by naming the data source (ODiN respondents) and the clustering output, but it does not explicitly state when to use this tool over siblings, nor provide when-not-to-use guidance. The 'profile' verb implies analysis, but without clear exclusion criteria.

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 fully disclose behavioral traits. While it describes the return types and data scope, it omits critical behavior such as whether the tool modifies data, rate limits, or performance expectations. The lack of such details leaves the agent uninformed about potential side effects or costs.

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 concise and well-structured. The opening sentence provides a clear summary, followed by a bullet-style list of parameters with concise explanations. Every line adds value without redundancy or unnecessary detail.

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 description covers the tool's purpose, required inputs, optional filters, and general output categories. Given the tool's complexity (12 parameters, no annotations, but an output schema exists), the description is largely complete. However, it could benefit from clarifying the output structure or providing a usage example for common scenarios.

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 0% description coverage, but the tool description compensates excellently by providing detailed explanations, examples, and allowed values for each parameter (e.g., municipality examples, transport_mode list). This adds significant meaning beyond the schema's minimal metadata.

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 runs ODIN travel survey analysis for a Dutch location, specifying the data scale and returns. However, it does not explicitly distinguish itself from sibling tools like run_modal_split or run_odin_compare, which could cause confusion about when to use this tool over others.

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 key usage requirement: 'Provide at least one of: municipality, postcode, or province.' It also lists all optional filters. However, it does not provide guidance on when not to use this tool or suggest alternatives like 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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions the output format (GeoJSON) but does not discuss side effects, performance, rate limits, data freshness, or whether the operation is read-only.

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 concise with a clear purpose statement followed by bulleted parameter explanations. No redundant or overly verbose content; 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 description covers purpose, output, and parameters well. With an output schema present, it does not need to detail return structure. However, it lacks information on error handling, authentication, or data source, which would further enhance 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?

The schema has no parameter descriptions (0% coverage), but the description's Args section adds significant value by providing examples, value lists, and ranges (e.g., gemeente examples, mode options, top_n range 1-100, include_internal explanation). This fully compensates for the schema gap.

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 generates origin-destination desire lines (spider diagram) for a municipality and returns GeoJSON with arc geometries. It distinguishes from siblings by specifying the output type, though not explicitly differentiating from similar OD tools like run_odin_spider_profile.

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 parameter details (e.g., mode, motive, top_n) that imply when to use the tool, but lacks explicit guidance on when to choose this tool over alternatives like run_odin_query or run_odin_compare.

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 states the tool returns distributions and centroids, but does not disclose error behavior (e.g., invalid gemeente), performance implications, or data freshness. It is adequate for a read operation but lacks depth on side effects 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 concise (about 10 lines) and front-loaded with the core purpose. The Args section is cleanly formatted. No extraneous information; every sentence contributes to understanding. It achieves high density of useful content.

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 complexity (3 params, 1 required) and existence of output schema, the description covers purpose and parameters well but lacks context on sibling differentiation, error handling, or typical usage scenarios. It is complete for basic invocation but insufficient for nuanced selection among related tools.

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%, but the description's Args section adds meaning: it explains 'gemeente' as municipality name with examples, 'mode' as transport filter with examples, and 'motive' as trip purpose filter. This adds significant value beyond the schema, which only provides types. It does not enumerate valid values but provides practical guidance.

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 retrieves demographics of travelers to/from a municipality, listing specific return fields (sex, age, education, etc.) and home location centroids. This is a specific verb+resource with clear scope, differentiating it from siblings like run_odin_profile or run_odin_spider by combining 'spider' (origin-destination) and 'profile' (demographics) concepts.

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 context (when needing demographic breakdowns by mode/motive for a municipality) but does not explicitly state when to use versus alternatives among 15 sibling tools. No when-not guidance or prerequisites are 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?

In the absence of annotations, the description discloses key behavioral traits: data source (~1M respondents, 20-year span), return fields (sex, age, etc.), and parameter constraints. However, it omits information about authentication, rate limits, or behavior when no data matches.

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 succinct, with a clear purpose statement upfront, followed by essential context and a structured Args list. Every sentence adds value, and the format is easy 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?

Given the tool's complexity, the description covers all necessary aspects: purpose, data source, return fields, parameters with examples, and constraints. The existence of an output schema further supports completeness, though the description already details return values.

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 0% schema description coverage, the description compensates fully by explaining each parameter (municipality, postcode, province, year_min, year_max) with meanings, examples (e.g., '1012'), and allowed ranges (2004-2023). This adds significant value beyond the basic schema.

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 retrieves demographic and mobility profiles of ODIN respondents for a location, using specific verbs like 'Get' and specifying the resource and scope. It distinguishes from sibling tools by focusing on respondent profiles with standardized data across 20 years.

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 parameter requirements (e.g., provide at least one location parameter) but lacks explicit guidance on when to use this tool versus alternatives like run_odin_profile. No when-not-to-use or comparison to 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?

With no annotations provided, the description fully bears the burden of behavioral disclosure. It only describes input parameters and fails to mention aspects like partial matching, case sensitivity, error behavior, or pagination, leaving the agent with limited understanding of how the tool behaves.

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 concise with a clear purpose statement and an organized Args section. Every sentence is relevant, and the structure is front-loaded with the main action, though it could be slightly more structured.

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 presence of an output schema, return value explanation is not needed. However, the description lacks behavioral details and usage context, making it minimally adequate but with clear 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?

The input schema has no property descriptions (0% coverage), so the description adds crucial semantics: it defines 'name' as a search term and lists allowed values for 'level' ('gemeente', 'wijk', etc.). This compensates for the schema gap and provides meaningful guidance.

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 searches for geographic boundaries by name, specifying types like municipality, district, neighbourhood, or postal code. It is specific about the resource and verb, but does not explicitly distinguish from sibling tools like get_features, though the focus on name search is distinct.

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 when a boundary name is known, but provides no explicit guidance on when not to use it or alternatives among sibling tools. The context is clear but lacks exclusions or comparative advice.

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