geoagentic

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

Despite no annotations, the description covers key behaviors: internal geocoding, live real-time schedules, failure modes with specific error types, and temporal note generation. Lacks mention of idempotency or cost but is otherwise 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 well-structured with clear sections (CRITICAL, TEMPORAL, EXAMPLES, FAILURE MODES), front-loaded with purpose, and 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 5 parameters and no output schema, the description covers internal geocoding, temporal handling, failure modes, and examples. It does not detail the output format, but the mention of 'multi-leg itineraries' provides adequate 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?

Schema coverage is 100%, but the description adds value by explaining the purpose of each parameter, providing examples, and clarifying details like modes default and allowed values, and requested_date usage.

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 is an 'EU-wide public intercity transit router' that accepts place names and returns itineraries via Transitous, distinguishing it from sibling tools like geo-geocode or geo-route.

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 'CRITICAL FOR AGENTS' section provides explicit instructions: do not pre-geocode, call once, present errors and stop. Also explains temporal handling with requested_date, giving clear when-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?

No annotations are provided, so the description must cover behavioral traits. It mentions a timeout parameter but does not disclose error handling, rate limits, or what happens on ambiguity. The example helps but leaves gaps in 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?

The description is concise with clear sections (USE FOR, NOT FOR, EXAMPLE). Every sentence serves a purpose without redundancy. It is front-loaded with the core action and efficiently 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?

For a simple tool with 2 parameters and no output schema, the description covers purpose, usage, and parameter guidance adequately. It could mention the return format (lat/lon) explicitly, but the context 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 coverage is 100%, and the description adds value beyond the schema: it advises to 'Be specific — include city/country when possible' for the query parameter and notes the timeout default and maximum. This enriches the parameter meaning.

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 a clear verb+resource statement: 'Convert a place name or address into coordinates (lat/lon).' It also distinguishes itself from the sibling tool geo-reverse by specifying what it is not for, ensuring no confusion.

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 'USE FOR' with examples like 'Where is Izola bus station?' and 'NOT FOR: reverse lookup ... use geo-reverse instead.' It also advises using it before other geo tools, providing clear context for when to invoke this tool.

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?

Describes outputs (node count, radius, bounding box) and parameter constraints (max timeout 60), though lacks explicit read-only/permission info. No annotations provided, but description is transparent enough for a calculation 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?

Well-structured with sections (purpose, returns, USE FOR, NOT FOR, example). Every sentence adds value; no fluff.

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 inputs, outputs, provides an example, and notes constraints (max distance, timeout). No output schema, but description sufficiently explains 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?

All 6 parameters have schema descriptions (100% coverage). The description adds an example showing how parameters map to user intent, clarifying usage beyond schema alone.

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 calculates how far you can travel in N minutes from a point, and explicitly differentiates from sibling tool geo-route for directions.

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 explicit 'USE FOR' and 'NOT FOR' sections with alternatives (geo-route), plus an example mapping user query to parameters.

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 discloses critical tag formatting (stringified JSON) and implicit requirements (lat/lon, search radius). Lacks explicit statements about side effects, but as a read tool, it's 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?

Concise with clear sections (summary, critical note, USE FOR, NOT FOR, EXAMPLE, COMMON TAGS). Every sentence adds value and 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?

Given 6 parameters with full schema coverage and no output schema, the description covers purpose, parameter formatting, and usage. It could mention result format, but current completeness is high.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and description adds significant value: critical note on tags format, example usage, and common tag values, going well beyond schema descriptions.

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 nearby places on OpenStreetMap (cafes, ATMs, shops, parks), distinguishing it from sibling tools like geo-geocode, geo-route, and geo-isochrone.

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?

Explicitly lists use cases (e.g., 'Find a cafe near X') and exclusion cases (NOT FOR: directions, geocoding, Wikipedia, isochrones). Provides an example with exact parameters.

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 bears the full burden of behavioral disclosure. It states the tool converts coordinates to an address but does not disclose potential side effects, rate limits, authentication requirements, or the format of the returned address. While the operation is simple, more details (e.g., whether it returns a single address or multiple, or if it has any restrictions) would improve 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?

The description is remarkably concise and well-structured: it starts with the core purpose, then provides usage guidelines with 'USE FOR' and 'NOT FOR' sections, followed by a concrete example. Every sentence contributes 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?

For a simple tool with only three parameters and no output schema, the description covers the essential information: purpose, usage context, and an example. The only minor gap is the lack of detail about the output format (e.g., full address string vs. components). However, given the tool's simplicity and the schema's coverage, it is nearly 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 input schema has 100% coverage with descriptions for all three parameters (lat, lon, timeout). The description adds minimal extra semantic value beyond the schema, such as showing an example with lat and lon. However, the schema already clearly documents each parameter, so the description does not significantly enhance parameter understanding.

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: 'Convert coordinates (lat/lon) into a street address.' It uses a specific verb (convert) and resource (coordinates to address), and it distinguishes itself from the sibling tool geo-geocode, which does the inverse operation. This makes the purpose 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 explicit usage guidance: it lists what the tool is used for (e.g., 'What's at 45.5, 13.6?') and what it is NOT for ('place name → coordinates → use geo-geocode instead'). Additionally, it includes a concrete example, helping the agent understand when to invoke this tool versus 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?

Discloses return values (distance, time), constraints (local trips under ~10 km), and the timeout parameter. No annotations exist, so description carries full burden. Could explicitly state it's a read-only operation, but overall good.

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?

Concise, well-structured with labeled sections (USE FOR, NOT FOR, EXAMPLE). Every sentence provides unique value. 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?

Covers return values, prerequisites (geo-geocode for place names), usage boundaries, and an example request. No output schema, but description fills the gap adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds context: explains the 'dist' parameter (graph radius, increase if far apart), travel modes (walk, bike, drive), and timeout. Also gives an example mapping user request to 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?

Clearly states the tool computes shortest routes for walking, biking, or driving between two coordinates. Distinguishes itself from siblings like eu-transit-router (public transit) and geo-geocode (place name to coordinates).

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 explicit 'USE FOR' and 'NOT FOR' sections, including an example of when to call geo-geocode first. Tells when to use the tool vs alternatives (e.g., eu-transit-router for intercity trips).

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, but the description adds behavioral context: 'One call is sufficient', 'DO NOT iterate', and instructs combining results into a summary. This helps the agent understand tool behavior beyond the 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?

Well-structured with clear sections (USE FOR, NOT FOR). Concise with no wasted sentences. Front-loaded with 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?

No output schema, but description explains expected results (notable landmarks) and usage pattern. 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 description coverage is 100%, so baseline 3. The description does not add significant new parameter info beyond what schema already provides (e.g., dist max, limit range).

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 finds info about notable/historic landmarks, towns, and remarkable sites near a coordinate, with concrete examples. It distinguishes from sibling tools like geo-geocode or geo-route.

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?

Explicitly provides USE FOR examples and NOT FOR exclusions (directions, specific shops, raw geocoding). Also instructs not to iterate results, combining into a single summary.

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 explains that the tool queries OSM networks and returns trail distances, but does not explicitly state read-only behavior, rate limits, or side effects. However, the usage instructions imply safe, read-only operation, making it mostly 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 well-organized with clear headings, bullet points, and bolded terms. It is concise yet comprehensive, front-loading the purpose and then providing usage instructions. No unnecessary 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 no output schema, the description moderately explains that the tool returns trail distances and features. It does not specify the full output format, but combined with sibling tool context and usage examples, it is fairly complete for a trail exploration 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 coverage is 100%, so the baseline is 3. The description adds significant value by explaining buffer values in meters, max allowed buffer, and endpoint mirror options, which goes beyond the schema descriptions and aids agent understanding.

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 is a global trail explorer querying OSM relation networks, with specific use cases like hiking and biking. It distinguishes itself from street routers (geo-route) by naming them, satisfying the 'specific verb+resource' and 'sibling differentiation' criteria.

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 explicit 'USE FOR' and 'NOT FOR' sections, plus critical instructions for when to choose this tool over geo-route, buffer size recommendations, and a directive to accept results as complete. This fully satisfies the 'explicit when/when-not/alternatives' standard.

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 details the output structure (per-property prices, ratings, free cancellation flag, summary stats) and includes critical instructions about date format, currency default, and how to use the summary fields. This provides sufficient behavioral context for a read-only search 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 well-structured with clear sections: main statement, 'USE FOR' with bullet points, 'RETURNS', and 'CRITICAL INSTRUCTIONS'. Every sentence adds value, and the information is front-loaded. 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 adequately explains the return types (dorm/private prices, ratings, cancellation flag, summary stats). It provides guidance on how to use the results for different queries (e.g., cheapest vs. general cost). The tool is moderately complex with 5 parameters, and the description covers all necessary aspects for an AI agent to invoke 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?

Schema coverage is 100%, providing baseline of 3. The description adds value by reinforcing the date format (YYYY-MM-DD), currency default (EUR), and giving examples for city names and number of guests. While it does not elaborate on every parameter beyond schema, it clarifies usage through the 'CRITICAL INSTRUCTIONS' section.

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 provides 'Live hostel and budget accommodation prices from Hostelworld for any city worldwide.' It includes specific verb+resource and usage examples, and none of the sibling tools compete directly for this purpose.

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 explicit use cases with example queries in the 'USE FOR' section and gives guidance on interpreting results (e.g., using summary.floor for cheapest queries). However, it does not explicitly state when not to use this tool or mention alternatives, though no obvious alternative exists 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 provided, so description carries full burden. It discloses that the tool makes multiple WFS calls per result and can be slow (10-30s), advises using --limit for reasonable response times, and notes rate limit considerations via --workers. Does not mention authentication or fully describe all edge-case behaviors, but covers major performance traits.

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 well-organized: initial summary, bulleted use cases, exclusions, search mode breakdowns, common KO IDs, and a performance note. Every sentence adds value, no redundancy. Efficiently front-loads purpose and 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?

Given the tool's complexity (14 parameters, multiple search modes, no output schema), the description is fully complete. It covers all usage scenarios, performance implications, parameter combinations, and provides lookup aids (common KO IDs). An agent can confidently use 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?

Input schema has full description coverage (100%), but the description adds substantial value by grouping parameters into search modes, providing concrete examples (e.g., '--parcel 3086 --ko 1725'), and explaining contextual requirements. This goes beyond the schema's own descriptions.

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 it performs deep parcel/building analysis with GURS WFS data and lists specific insights (zoning, heritage, etc.). It distinguishes from siblings by explicitly stating what the tool is NOT for and naming alternative tools (slovenia-cadastre, slovenia-wfs-expert).

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 explicit USE FOR examples illustrating appropriate queries and NOT FOR sections that exclude uses better handled by sibling tools. Also outlines four distinct search modes with parameter requirements and examples, guiding the agent on when and how to use each mode.

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 the description carries full burden. It describes inputs and outputs but fails to disclose behavioral traits such as read-only nature, side effects, authentication needs, rate limits, or error handling. The tool's query-only nature is implied but not explicitly stated.

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 well-structured with clear headings, bullet points, and examples. It is front-loaded with the purpose and efficiently organizes information. Every element earns its place.

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 complex functionality, the description lacks details on return formats, error cases, and required parameters per command. It mentions 'Returns: ...' vaguely without specifying JSON structure. Also missing guidance on command-specific required fields.

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%, baseline is 3. The description adds example values and groups parameters by command, but does not provide additional constraints or behavioral context beyond the schema's parameter descriptions. The added value is moderate.

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 queries Slovenian cadastral data with specific commands (parcel, address, building, near-coords, near-location). It provides examples for each command, making the purpose unmistakable and differentiating from sibling tools through simplicity.

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 guidance on when to use this tool versus alternatives like slovenia-cadastral-deep or slovenia-wfs-expert. The description only lists commands; it does not specify conditions, prerequisites, or exclusions for 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 the critical time zone behavior (CET/CEST) but omits other important aspects like error handling, authentication, rate limits, or whether it is read-only. The presence of an undocumented '--dry-run' in examples reduces trust.

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 relatively concise with a clear opening, structured examples, and a prominent time zone note. The examples are helpful but include a parameter mismatch that slightly detracts from efficiency.

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 main purpose and time zone but lacks details on return format, pagination, error scenarios, or output structure. For a tool with 6 parameters and no output schema, this is only moderately 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 100%, so the schema itself already documents parameters. The description adds value through examples that illustrate parameter combinations, but it introduces a '--dry-run' parameter not present in the schema, causing confusion.

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 'Search for car rides on Prevoz.org in Slovenia', providing a specific verb and resource. It is well-differentiated from sibling tools like 'eu-transit-router' or 'geo-geocode' which address different domains.

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?

Agentic examples illustrate common usage patterns for date and limit parameters, giving implicit guidance on when to use the tool. However, it does not explicitly mention when not to use or direct to alternatives, and the --dry-run example suggests an undocumented parameter.

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 explains confidence levels (exact_match, ko_level, national_fallback) and the no_verified parameter behavior. Lacks mention of data source freshness or update frequency, but overall transparent for a read-only estimation 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?

Well-structured with sections, front-loaded with purpose and use cases. Each sentence is informative; no redundancy. Examples are clear and concise. Optimal length for a command-driven tool.

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?

Despite 7 parameters (only 1 required) and no output schema, the description covers all necessary context: commands, optional parameters, confidence levels, common KO IDs. An AI agent can select and invoke this tool correctly without ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds value by grouping parameters per command, clarifying required vs optional, and providing concrete examples. This enhances understanding beyond the schema's property descriptions.

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 estimates property values and market statistics for Slovenia using ETN transaction data. It specifies the input types (building numbers, parcel numbers, KO IDs) and provides distinct use cases, differentiating from sibling tools like cadastral-explorer and slovenia-cadastre.

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?

Explicitly says when to use (property valuation) and when not (parcel details, zoning, heritage, live listings). Names alternative sibling tools. Provides multiple example queries and command options with required/optional parameters.

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 coordinate system handling (WGS84 vs EPSG:3794) and endpoint roles. It lacks info on error behavior, rate limits, or side effects, but overall transparency is good.

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 well-structured with bold headings, front-loaded purpose, and concise sections. At 85 words in the main body, it is reasonably terse but could be slightly more streamlined.

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 10 parameters and no output schema, the description explains coordinate handling and endpoint mapping but omits return value details and how parameters interrelate (e.g., ko + parcel). This leaves 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?

Schema coverage is 100%, baseline 3. The description adds value by explaining endpoint numbers (e.g., '1' = Cadastral Portal) beyond the schema's brief label. This enriches parameter understanding.

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: a multi-endpoint WFS explorer for Slovenian geographic data, dealing with cadastral and zoning queries. It distinguishes itself from siblings like slovenia-cadastre by emphasizing its WFS nature and multiple endpoints.

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 context is clear: spatial bounding box queries against Slovenian geographic catalogs. However, there is no explicit guidance on when to prefer this tool over siblings like slovenia-cadastre or when not to use it.

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