gisgp

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 is rate-limited and best-effort, and specifies the exact JSON output structure including all fields. This provides good insight into behavior, though it could also mention error handling or failure modes.

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: two sentences covering purpose, constraints, and output. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.

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 simplicity (2 parameters, no nested objects), the description covers the core aspects: purpose, input requirements, output format, and usage limitations. It is nearly complete but could briefly mention error cases or result reliability.

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 description adds context by stating it reverse-geocodes a 'WGS84 point', clarifying the coordinate system. However, it does not explain valid ranges or any other constraints beyond that, offering only modest additional 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 clearly states the tool's purpose: 'Reverse-geocode a WGS84 point to country/region/locality via OSM Nominatim'. It specifies the verb (reverse-geocode), resource (WGS84 point), and output type (country/region/locality). This distinguishes it from sibling tools, most of which are geometric operations or coordinate conversions.

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 notes that it is free, fair-use rate limited, and best-effort, providing important context for when to use it. However, it does not explicitly mention when not to use it or suggest alternative tools for different scenarios, leaving the agent to infer usage boundaries.

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 discloses behavior: it costs 100 credits, requires Authorization and sufficient balance, uses a specific data source, and clearly states limitations (only the Part 77 200ft threshold, not airport-specific lower heights). It also describes the return JSON structure, making the tool's behavior highly 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 compact and information-dense, delivering cost, use case, source, threshold, limitations, auth requirements, and return format in a few sentences. Every sentence earns its place; there is no fluff or repetition.

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 moderate complexity (3 params, no annotations, output schema present), the description is remarkably complete. It covers inputs (implicitly), outputs (explicitly), cost, authentication, data source, and limitations, leaving little for the agent to guess.

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 compensate for parameter meanings. It explains proposed_height_agl_ft and its role in triggering FAA notification, but it never explicitly describes the required 'lat' and 'lon' parameters, leaving the agent to infer that 'US point' maps to these. This is a significant gap for the two required 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 identifies the tool's purpose: to assess nearby FAA-registered vertical obstructions at a US point for telecom/tower-siting due diligence. It uses specific verbs and examples ('is there anything tall already near this proposed tower site'), and it distinguishes itself from sibling tools by focusing on airspace obstruction proximity with a specific source (FAA Digital Obstacle File).

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 when to use the tool (telecom/tower-siting due diligence) and includes a concrete example. It also states an exclusion: it only flags the 200ft AGL notification threshold and is not a full aeronautical study, nor does it check lower heights near airports. It does not explicitly name alternative tools, but the guidance is sufficient.

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. Discloses honest reporting ('No invented overall suitability score'), authentication requirements, and credit cost. Does not mention rate limits or error handling, but overall transparent about 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?

Description is dense but informative, front-loading cost and purpose. Every sentence adds value, though it could be split for readability. Overall concise given the complexity.

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 composite nature and presence of an output schema, the description covers the main output fields and requirements. However, lacks details on data freshness, geographic coverage, or error conditions. Mostly 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 has 0% description coverage for parameters; description does not explain lat/lon beyond the schema (no bounds, format, or default values). The description focuses on output and requirements but fails to add meaning to the input 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 is for 'data center site-scouting composite' and lists specific components (grid proximity, multi-source hazard, land cover, temperature history). Distinguishes from sibling tools like assess_property_hazard by mentioning the composite nature and required multi-source hazard.

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 mentions cost (PAID 300 credits), required authorization (Bearer <api_key>), and sufficient credits balance. Notes that multi-source hazard is required and same contract as assess_property_hazard. However, does not explicitly guide when to use this over other datacenter-related sibling tools like assess_site_due_diligence.

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 carries the transparency burden. It discloses the credit cost, auth requirement, the qualifying logic (either pathway suffices), the fact that only qualification is reported, and the return JSON fields. This goes far beyond a simple restatement and gives the agent a solid understanding of 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?

Every sentence in the description earns its place: cost, purpose, methodology, exclusions, prerequisites, and output format are all covered without redundancy. The description is front-loaded with cost and clear purpose, making it efficient despite being detailed.

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 moderate complexity (tax credit qualification with two pathways) and lack of annotations, the description is remarkably complete: it covers eligibility logic, limitations, auth, cost, and expected output fields. No critical selection-driving information appears missing for an agent deciding to invoke this 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?

Although schema coverage is 0%, the description implies that lon and lat identify the renewable energy project site, which adds some meaning beyond the schema's bare 'Lat' and 'Lon' properties. However, it does not specify coordinate format (e.g., WGS84 decimal degrees), ranges, or other parameter details, so the description only partially compensates for the missing schema documentation.

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 opens with a specific verb and resource: 'US Inflation Reduction Act energy community bonus tax credit qualification lookup for a renewable energy project site.' It clearly identifies the tool's purpose and distinguishes it from sibling assess_* tools by focusing on the energy community tax credit. It also details the two qualifying pathways, making the purpose unmistakable.

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 use, including the IRA energy community bonus credit context, prerequisites (Authorization header, 100-credit cost, sufficient balance), and an explicit limitation ('not a project-specific dollar estimate'). It does not name alternative sibling tools or say exactly when not to use it, but the context is strong enough for an agent to select it appropriately.

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 full burden. It discloses that the tool requires no key and returns specific JSON fields, but lacks information on side effects, rate limits, or whether it is read-only (likely safe). This is minimal but sufficient for a simple query 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 brief, with two well-organized sentences. It front-loads the purpose and lists outputs in a structured list. Every sentence is meaningful, though some could be more explicit.

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 0% schema coverage and no annotations, the description is adequate for a simple tool with two numeric parameters. It lists output fields, but could improve by specifying coordinate system or edge cases (e.g., invalid coordinates).

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%, so description must compensate. It implies parameters are coordinates but does not specify expected format (e.g., WGS84) or valid ranges. This adds minimal value over the schema's type 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 clearly states the tool's purpose: assessing EV charging sites by combining grid proximity, land cover, and locality context. It uses specific verb 'scouting' and resource 'EV charging site', and distinguishes from sibling tools like 'assess_renewable_site' by focusing on EV.

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 EV site scouting and mentions 'No key needed' indicating easy access. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives 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?

Given no annotations, the description does a good job disclosing behavioral traits: data source (community ArcGIS mirror of HIFLD), limitations (proximity indicator, not a certified survey), and return format. It also clarifies no key is needed, implying no authentication overhead.

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, front-loaded with purpose, and includes the return structure inline. Every sentence adds value, though the format could be more structured (e.g., separate sections for input constraints).

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 data source, limitation, and output format but lacks details like units (miles are mentioned as radius), coordinate reference system, and how to interpret the proximity indicator. The return schema is embedded but not formally defined, leaving some 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 has 0% coverage, and the description only mentions 'at a US point' without specifying coordinate system (e.g., WGS84) or bounds for lat/lon. This leaves ambiguity for an agent selecting the tool, especially for geospatial inputs.

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 tool assesses proximity to electric grid infrastructure (substations and transmission lines) for a point in the US within 10 miles, using a community mirror of HIFLD data. This differentiates from sibling tools like assess_renewable_site or assess_property_hazard, which focus on other aspects.

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 some guidance by stating 'no key needed' and indicating it's a 'proximity indicator, not a certified survey', implying use for quick screening rather than official purposes. However, it lacks explicit instructions on when to use this tool versus alternatives like assess_renewable_site.

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. It discloses coverage scope (transmission only), data source, no-key requirement, and the return format. While it does not mention rate limits or real-time vs. cached data, the transparency is good for a safe read-only 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 concise at 4 sentences, front-loading the purpose. Every sentence adds value: data source, scope, disclaimer, and return structure. No redundant or 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?

The description provides essential context: data source, coverage limitations, and return fields. However, it lacks details like search radius or what the 'count' field represents. Given the output schema exists (implied by the described JSON), the description is fairly complete but could be enhanced.

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 2 required parameters (lat, lon) with 0% description coverage in the schema. The description does not add any meaning to these parameters, such as coordinate system (e.g., WGS84) or expected format. This is a significant gap for an agent to correctly invoke the tool.

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 assesses natural gas pipeline proximity at a US point, specifies the data source (EIA/HIFLD, 32,892 segments), and distinguishes it from proprietary 'call before you dig' data and local distribution lines. This makes the purpose specific and well-differentiated from sibling tools.

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 when to use (for major transmission pipelines) and when not to use (not for local distribution, not a substitute for calling 811). It provides clear usage boundaries but does not explicitly compare to sibling tools like assess_grid_exposure or assess_wildfire_risk.

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 disclosure burden and does so exceptionally. It reveals the cost per property, authentication requirement, the fact that it delegates to assess_property_hazard, and the exact JSON return structure. It also explicitly states 'no invented portfolio-level risk score', setting honest expectations about limitations.

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?

Although dense, the description is efficiently structured: cost and limits first, then purpose, then behavior, then prerequisite, then auth, then return format. Every sentence delivers critical information without padding. It's long but 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?

The description fully equips an agent to decide when to use the tool and how to call it correctly. It covers cost, limits, authentication, the underlying mechanism, the output schema, and the prerequisite invocation of estimate_cost. Nothing essential is missing.

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

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

The schema only provides an array of number arrays with no descriptions (0% coverage). The description compensates by explaining that each property is a [lon, lat] pair, clarifying the meaning of the single 'properties' parameter. It also ties the parameter to the cost calculation via estimate_cost.

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: bulk physical climate-risk disclosure input for a real-estate/asset portfolio (SEC/CSRD). It explicitly says it runs assess_property_hazard for each [lon, lat] property, distinguishing it from sibling single-property assessment tools. The wording is specific and includes the exact use case.

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 provides explicit usage guidance: use estimate_cost first to quote, and it implies this is the batch/portfolio version of assess_property_hazard. It also notes limits (max 25 properties/call) and discloses that the tool is paid. This gives clear context for when to use this tool vs 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 provided, the description fully shoulders the transparency burden. It discloses cost, required auth, data sources, limitations (infrastructure blocks), and notes that no composite risk score is invented. This is exceptionally honest and 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: starts with key info (paid, purpose), then sources, requirements, usage hint, return format, and limitations note. Every sentence adds value, and the structure is front-loaded with the most critical 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 the complexity (paid, multi-source, output schema exists), the description covers all essential aspects: cost, auth, sources, return fields, limitations, and usage hint. It is fully sufficient for an agent to decide when and how to use the 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 0%, meaning parameters lat and lon have no descriptions. The description only implies they are coordinates for a point location but lacks specifics like expected range, coordinate system, or format. With no schema descriptions, the description should compensate more.

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 is a 'multi-source US property hazard indicator' with specific data sources (USGS seismic risk, FEMA disaster history, NOAA alerts). The verb 'assess' and resource 'property hazard' are specific, and the purpose is unambiguous. While it doesn't explicitly differentiate from the sibling 'assess_property_hazard_x402', the core purpose is well-defined.

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 clear context on when to use: requires auth, paid (200 credits), suggests using estimate_cost first. It also notes limitations (no flood/wildfire). However, it does not explicitly name alternative tools for missing hazards, so the guidance is good but not optimal.

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 transparently discloses the payment mechanism (x402, USDC, cost ~$0.20/call), that no account or API key is needed, and that it returns JSON with specified fields. It does not mention any side effects, but the operation is likely read-only and non-destructive, which is implicit.

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 and efficiently conveys payment details, data sources, and output format without unnecessary words. The first sentence is slightly dense but still clear and front-loaded with essential 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?

Despite no output schema, the description lists all returned JSON fields (ok, pga_percent_g, etc.) and names the data sources. It does not explain coordinate system or units, but for a multi-source hazard indicator, it covers the main expectations 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?

The schema has 0% description coverage for the two parameters (lat, lon). The tool description does not add any meaning beyond the schema's type information (number). It fails to specify units (e.g., decimal degrees) or any constraints, which is inadequate given the lack of 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's function as a 'Multi-source US property hazard indicator' combining USGS seismic, FEMA disaster history, and NOAA active alerts. It distinguishes itself from the sibling tool 'assess_property_hazard' by noting 'same underlying data' and the x402 payment method, making the purpose and differentiation explicit.

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 context for when to use this tool: when the agent needs to pay directly on-chain without a GISGP account or API key. It notes that it has the same underlying data as 'assess_property_hazard', implying an alternative for payment preferences, but does not include explicit when-not 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?

No annotations are provided, so the description carries the full load. It discloses the tool is a read operation (no destructive action), specifies the 2-mile radius buffer, and describes the JSON output structure with fields like ok, count, areas, source, and note. It could mention authentication or rate limits, but for a simple coordinate query, the transparency is strong.

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 moderately sized with several sentences, but it is well-structured: it begins with the core purpose, adds legal context, then details behavior and output. Every sentence adds value, though it could be slightly more concise (e.g., removing the return format list if the output schema is sufficient). Overall, it is clear and organized.

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 low complexity (2 parameters, no nests, with an output schema), the description covers geographic scope, data source licensing, proximity radius, and return fields. It does not address error handling or coordinate system assumptions, but for typical agent usage, the provided information is sufficient.

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

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

The schema coverage is 0% (no parameter descriptions in the schema), so the description must explain the parameters. It does not explicitly mention 'lat' and 'lon' or their units; it only implies coordinate input through the context of 'point'. The parameter names are self-explanatory, but the description lacks additional semantic value beyond the schema itself.

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 assesses US protected/conservation area proximity using USGS PAD-US data, reporting whether a point falls inside/near a 2-mile radius of a federally-tracked protected area. It lists specific output fields (name, managing agency, etc.), which distinctly differentiates it from sibling tools like assess_wildfire_risk or assess_ev_charging_site.

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 'US-only' and highlights that the data source (PAD-US) is public domain and commercial-use OK, contrasting it with Protected Planet/WDPA. This provides clear context for when to use this tool (US commercial applications) and implicitly when not to (non-US or non-commercial scenarios requiring WDPA). However, it does not directly name sibling alternatives, keeping the score from being a 5.

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 cost, authentication requirements, and return format. It explicitly states it is based on free data and does not invent scores, providing transparency about its limitations. It does not mention potential side effects or rate limits, but as a read-only query, this is minor.

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 given the amount of information conveyed (cost, purpose, data sources, limitations, return format). It front-loads key details (PAID, purpose). Minor improvement would be more structured formatting, but overall it is 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's complexity (composite of multiple data sources) and the presence of an output schema, the description covers most essential aspects: purpose, cost, data used, what it does not do, authentication, and return fields. It lacks error handling or rate limit info, but these are not critical for selection. It differentiates well among many sibling 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?

The input schema has 2 required parameters (lat, lon) with 0% description coverage. The description implies lat/lon are coordinates for the site but does not explain units, coordinate system, or valid ranges. While the purpose is clear, the lack of explicit parameter guidance means the agent must infer 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 clearly states the tool assesses a site for reforestation/afforestation using terrain, land cover, and precipitation data. It distinguishes itself from siblings by noting it's a composite for bulk-screening and that it does not invent a 'sequestration score', making its purpose specific and unique among similar assessment tools.

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 cost (100 credits) and that it is priced for bulk-screening convenience, implying use for screening many sites. It also says 'no invented sequestration score', guiding against using it for carbon credit calculations. However, it does not explicitly state when not to use it or name alternatives 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?

Without annotations, the description carries the full burden. It describes the return format (JSON with specific fields) and notes it uses existing free primitives. It does not explicitly state it is read-only, but the lack of destructive hints in the description is acceptable for a scouting 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 concise, with only three sentences that front-load the key purpose and output. Every sentence adds value, and there is no redundant or vague language.

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 (combining multiple data sources) and the presence of an output schema (though not shown), the description covers purpose, inputs, outputs, and limitations. It could mention coordinate system details but overall is sufficiently complete 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 0% description coverage, and the description does not add any parameter-level detail beyond the parameter names (lat, lon). Given the low coverage, the description should compensate, but it fails to explain coordinate system, bounds, or expected formats.

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 'one-call solar/wind site-scouting indicator' combining terrain, land cover, climate averages, and grid proximity, distinguishing it from sibling tools like assess_grid_exposure, classify_land_cover, get_climate_history, and get_terrain_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?

It provides context by noting 'no key needed' and cautions that it is 'Not a substitute for a professional feasibility study,' implying usage for quick scouting rather than definitive analysis. However, it does not explicitly compare to sibling tools for when to choose this composite tool over individual ones.

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 carries the burden of behavioral disclosure. It reveals cost, authorization, credit balance requirement, output JSON structure, and that no invented overall score is produced. This is comprehensive for a complex 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 a single, focused paragraph that front-loads the cost warning and concisely conveys all key aspects without unnecessary words, earning 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?

Given the tool's complexity and lack of annotations, the description covers cost, auth, included sub-assessments, output structure, and constraints (no invented score). The presence of an output schema alleviates the need to detail return values further.

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 adds minimal parameter meaning—only that the tool requires lat and lon coordinates for 'a point'. No details on coordinate system, bounds, or units are provided.

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 'master due-diligence report for a point' that wraps multiple specific sub-assessments (hazard, grid, land cover, locality), distinguishing it from sibling tools that provide individual assessments.

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 advises users that the tool is paid (300 credits), recommends using estimate_cost first, and specifies authorization and credit requirements. However, it does not explicitly state when to use this vs. alternatives 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.

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

With no annotations, the description carries full responsibility for behavioral disclosure. It explicitly notes the tool is PAID (400 credits), requires Authorization and sufficient balance, and returns a specific JSON structure. It also discloses the FEMA state-level limitation, which is a significant behavioral nuance beyond what annotations would likely cover.

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 information-dense but every sentence earns its place: purpose, methodology, caveat, auth requirement, and return format. It is front-loaded with the core action and includes 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?

The description covers purpose, methodology, caveats, authentication, and return fields, which is robust given the presence of an output schema. The main gap is input coordinate format clarity, but overall it is highly complete for a geospatial analysis 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 schema provides no descriptions for site_a and site_b (0% coverage), so the description must compensate. It clarifies that these two parameters represent the two sites being compared, but does not specify coordinate format (e.g., lat/lng order, GeoJSON) or units. This leaves ambiguity for a geospatial tool.

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 function: it checks whether two supposedly-redundant sites are actually independent, using geodesic distance, multi-source hazard profiles, and shared FEMA incident history. This specific verb+resource combination distinguishes it from the many sibling assess_* tools.

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: evaluating redundancy for backup suppliers, warehouses, or data centers. It also provides a critical caveat about FEMA state-level data, advising that distance_km is more reliable for same-state comparisons. However, it does not explicitly mention when not to use the tool or name alternative tools.

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?

Despite no annotations, the description discloses that it is read-only (returns data), uses free primitives, requires no key, and returns specific fields including 'physically_unsuitable'. This provides good behavioral context for an assessment 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 a single, effective sentence that front-loads the purpose and key features, followed by the return format. No superfluous 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?

For a simple tool with no annotations and an output schema mentioned in the description, the description covers purpose, inputs (implicitly), and outputs. It is complete enough for an agent to use correctly, though it could mention coordinate limits or error responses.

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 does not explain the 'lon' and 'lat' parameters beyond their schema definitions. With 0% schema coverage, the description should add meaning (e.g., coordinate format, bounds), but it omits this, relying on the parameter names 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 specifies the verb 'assess' and the resource 'telecom site' with specific factors (grid proximity, terrain elevation, land cover). It distinguishes this tool from siblings like 'assess_ev_charging_site' or 'assess_renewable_site' by targeting cell tower scouting.

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 quick one-call assessments and notes no key is needed, but does not specify when to use this tool over alternatives like 'assess_grid_exposure' or when not to use it (e.g., for detailed feasibility studies).

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 data source (NASA FIRMS, last 2 days), no API key needed, and that indicators are separate with no fabricated score. With no annotations, it covers key behavioral aspects well.

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 two sentences plus return format; front-loaded with key information, but 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?

Covers purpose, data source, authentication, return format; missing error handling or limitations, but adequate for a simple tool with output schema.

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, and the description does not add details about lat/lon format, ranges, or constraints beyond implying a point location.

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 assesses wildfire risk at a point using NASA FIRMS data and grid exposure, distinguishing it from siblings like assess_grid_exposure.

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 point-based wildfire risk, but lacks explicit guidance on when to use this tool versus alternatives like assess_grid_exposure or assess_property_hazard.

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 describes the return JSON shape and lists included components (health, fields, domains, summary), but does not disclose potential issues like authentication requirements (token is optional but unexplained), error cases, or the exact structure of the 'health' object. It is adequate but lacks depth.

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: two short sentences that front-load the purpose and follow with the key differentiator and output format. 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 tool's complexity (comprehensive audit) and the presence of an output schema, the description adequately covers what the tool does and returns. However, the lack of parameter documentation (0% coverage) and missing guidance on authentication or error states leaves significant gaps 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%, and the description adds no information about the two parameters (service_url, token) beyond what the schema provides. It does not explain what service_url should point to or how token is used, making it nearly impossible for an agent to correctly construct the invocation without external knowledge.

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 produces a 'Full one-call QA report' covering health, field schema, coded domains, and summary counts. It specifies the output format and explicitly distinguishes itself from sibling tools like check_service_health, check_field_types, and extract_domains by noting that this tool replaces separate lookups.

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 'One call replaces separate health/fields/domains lookups,' which guides agents to use this tool when a comprehensive report is needed instead of individual checks. However, it does not explicitly state when not to use it (e.g., if only a single metric is needed) or provide direct comparisons to sibling tools.

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 takes full responsibility. It discloses the return format (JSON with ok, distance_m, geojson), explains the projection behavior (local equidistant for geodesic accuracy), and notes that negative distances shrink. This is fairly transparent, though it could mention performance implications.

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 only two sentences, both front-loaded with essential information. No wasted words, and the structure is logical: operation + parameter specification, then accuracy and return details.

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 only 2 parameters and a clear return (output schema exists but not detailed), the description covers the main points. It could mention limitations like large inputs or geometry types, but overall it is sufficiently complete for a simple buffer operation.

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 add value. It explains the distance_m unit (METRES) and effect (negative shrinks). It also implies that geojson input should contain features. This adds meaning beyond the bare schema, though it could be more explicit about input format.

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 ('Buffer every feature'), the resource (GeoJSON), and the key parameter (distance in meters). It distinguishes itself from sibling geometry tools like centroids_geojson or convex_hull_geojson by explicitly focusing on buffering.

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 geodesic accuracy at any latitude, which hints at appropriate use cases, but does not explicitly state when not to use this tool or provide alternatives among the many sibling geometry tools.

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 fully discloses behavior: 30 credits per delivery, silent skip if wallet lacks credits, webhook_url validated at creation and delivery, and JSON return body structure. It also states the auth requirement (Authorization: Bearer <api_key>) and the scheduler's ~5 min firing window.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely informative, using clear line breaks and bullet-like semicolons. Every sentence adds value, but it could be trimmed slightly by moving some billing details to an annotation if available. Overall, well-structured and front-loaded with the most critical pricing/usage caveat.

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 complex tool with 9 parameters, no annotations, and no enum schemas, the description covers all critical aspects: billing, scheduling behavior, webhook validation, authentication, return value, and failure modes. It also gives a direct link for topping up credits. This is complete for an agent to invoke 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 0%, so the description must compensate, and it does for key parameters: format lists allowed values, frequency explains hourly/daily/weekly/monthly with run_hour/weekday/monthday semantics, and webhook_url describes the POSTed JSON body. However, token, where, and service_url are not explicitly described, relying on common sense from the tool context.

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 creates a schedule that re-exports a FeatureServer layer and POSTs the file to a webhook_url. It distinguishes itself from siblings like bundle_export_fixed (one-time) and cancel_export_schedule (deletion), and explicitly claims to be the only MCP tool exposing this recurring-export product.

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 explains when to use this tool (recurring exports) and names related tools: use estimate_cost or check_wallet_balance to plan ahead, and cancel_export_schedule to delete. It also notes the tool is free to create/cancel and paid per delivery, setting clear expectations 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?

With no annotations, the description carries the full burden and covers paid nature (150 credits), auth requirement, what it does, and return fields. However, the 'truncated' field is not explained, which is a minor gap given the 'fetch ALL records' claim.

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 tight and front-loaded with the most critical info (PAID), followed by function, what it replaces, requirements, and return JSON. Every sentence adds value with no filler.

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 the core functionality, cost, auth, and output fields. It doesn't mention error conditions or truncation behavior details, but an output schema exists and the description is sufficient for an agent to decide.

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%, and the description does not explain the 'token' or 'where' parameters. Only service_url is implied via 'FeatureServer layer.' This leaves the agent guessing at parameter semantics 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 clearly states the tool fetches all records from a FeatureServer layer, repairs geometries, and scans for problems—a specific verb+resource combo. It also distinguishes itself from siblings by explicitly naming what it replaces (query_features + fix_geometry + find_layer_issues).

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 states when to use this over alternatives: 'Replaces an uncapped query_features call (itself a paid-only capability) plus fix_geometry plus find_layer_issues.' It also provides essential prerequisites like Authorization Bearer token and sufficient credits balance.

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 bears the full burden. It discloses cost (120 credits), operational scope (ALL records), output format (ZIP base64), and the JSON response shape. It lacks details on size limits/truncation behavior beyond the 'truncated' flag, but overall it is transparent enough for safe use.

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 dense and well-structured: first sentence defines the action, second explains the efficiency benefit, third states requirements, fourth specifies the return value. Every sentence earns its place, and the 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 description covers purpose, cost, auth, output, and expected response. However, with an output schema present, return values are not the main gap. The missing parameter semantics (especially what 'where' does) leave the tool incompletely specified for callers, so overall completeness is only adequate.

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%, yet the description does not explain any of the three parameters (token, where, service_url). It only indirectly refers to 'live FeatureServer layer' without connecting to the service_url parameter. The description completely fails to compensate for the missing schema documentation.

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 and resources: 'fetch ALL records from a live FeatureServer layer' and 'export the same data as Shapefile + CSV + GeoJSON + KML + Excel in a single ZIP (base64-encoded).' This clearly distinguishes it from sibling tools like bundle_export_fixed or individual format conversions.

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 it 'replaces an uncapped fetch plus 4 separate format-conversion calls,' clearly indicating when to use this tool over multiple alternatives. It also states prerequisites (Authorization header and credit balance), providing actionable context for invocation.

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?

Since no annotations are provided, the description carries the full burden. It transparently discloses the paid nature (30 credits per address), the auth requirement and credit balance precondition, and the fallback geocoding chain. It also specifies the JSON return structure with failed_count, but it doesn't explicitly state that it is read-only or idempotent, which is implied but not spelled out.

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 opens with a prominent 'PAID' warning and then packs a clear functional summary, alternative naming, usage prerequisite, and return format into a tight set of sentences. Every sentence earns its place; there is no filler or 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?

This is a complete description: it covers purpose, cost, auth, per-call limits, alternatives, prerequisite estimation, and a detailed return schema. With an output schema also present, the description goes beyond the minimum and anticipates agent needs, leaving no critical gaps for a paid, multi-step 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 only says 'addresses' is an array of strings with no description (0% coverage). The description compensates thoroughly by explaining each element is an address, capping at 10 per call, and linking the count to estimate_cost's 'units' parameter. This adds meaning well beyond the schema's raw type definition.

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 performs batch geocoding and enrichment, detailing the exact pipeline (forward geocode to lon/lat, reverse geocode for context, and land cover classification). It differentiates from sibling tools by explicitly naming geocode_address, analyze_location, and classify_land_cover as the three separate calls it replaces, making its scope unmistakable.

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 says 'Replaces 3 separate calls per address' and advises to 'Use estimate_cost(tool_name=... ) first to quote,' which is explicit, actionable guidance. It also communicates the limit of 10 addresses per call and the per-address cost, helping an agent decide when to invoke this bundle versus simpler 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 provided, the description carries full behavioral burden. It discloses the credit cost, auth requirement, input format specifics (shapefile as base64 .zip vs raw text), parameter edge cases (0 skips reprojection/simplification), and return format. This goes well beyond the empty schema descriptions, though it omits failure modes and 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?

The description is longer than a two-liner but every sentence earns its place: purpose, benefit, auth, parameter breakdown, and return schema. It is front-loaded with the core purpose and uses a clear paragraph-per-aspect structure. Slightly verbose but not wasteful.

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 5-parameter tool with an output schema, the description is quite complete. It explains all parameters, return fields, and auth/credit constraints. It does not cover error cases or null handling, but those are less critical for a conversion tool. Overall it provides sufficient context for an 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 description coverage is 0%, but the description compensates fully. It explains each parameter: input_format values and data encoding, to_epsg=0 meaning, simplify_tolerance=0 plus algorithm, round_decimals default, and how data relates to format. Every parameter is given meaningful usage context beyond the bare 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 opens with 'one-call file migration: convert a raw file to GeoJSON, then optionally reproject and simplify, then round coordinates.' This is a specific verb+resource statement that clearly distinguishes the tool from individual conversion siblings like csv_to_geojson or reproject_geojson by emphasizing its bundling of multiple steps.

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 notes it 'Replaces 2-4 separate free tool calls... an agent would otherwise chain by hand' and references estimate_cost's 'replaces' field, giving clear when-to-use context. It also mentions prerequisites (Authorization header and credits), but does not explicitly state when to prefer individual tools, so it stops short of a 5.

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 transparently discloses the cost (100 credits), authentication requirement, and the precise behavior of the ready and blockers fields when schema mismatches occur. This goes beyond typical descriptions.

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 information-dense paragraphs with front-loaded cost and purpose. Every sentence adds value: purpose, replacement, auth/cost, return JSON structure, and condition for ready/blockers. 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?

The description covers purpose, replacement, auth, cost, return format, and ready/blockers logic. However, it omits explanation of token_a/token_b parameters and their relationship to the Authorization header, which is a significant gap for a complex bundle tool with no annotations.

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%, and the description does not explain the parameters. It implicitly refers to 'two FeatureServer layers' but does not name service_url_a/service_url_b or clarify the purpose of token_a/token_b, especially given the Authorization: Bearer requirement. The description fails to compensate 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's purpose: 'migration-readiness report comparing two FeatureServer layers: schema diff, coded-value domains, and field types for both.' This is a specific verb+resource and distinguishes it from siblings by being a bundle that replaces multiple existing tools.

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 'Replaces compare_schemas + extract_domains×2 + check_field_types×2', providing clear guidance on when to use this tool instead of alternatives. Also mentions the prerequisites: Authorization header and sufficient credits balance.

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 default backend, fair-use limits, optional token usage, honest 'no_route' response, and the return JSON structure, providing comprehensive behavioral 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 no redundant sentences. It front-loads the core purpose, then introduces options and behavior in a logical order, earning each sentence's 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?

The description provides a complete overview: tool purpose, backend options, limitations, honest response, and return format. While it does not mention prerequisites like valid coordinate ranges, the overall coverage is thorough for a routing tool with two backends.

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 adds meaning by mentioning coordinates and the agol_token purpose, but it does not explicitly state that origin_lon/origin_lat are the start and dest_lon/dest_lat are the end, nor does it clarify the default value for agol_token. The context signals indicate no enums or nested objects, so the description partially compensates but lacks full clarity on 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 tool calculates 'Real driving distance + duration between two points,' distinguishing it from sibling tools that handle other geospatial analyses. It also specifies default and optional backends, making 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 clear guidance on when to use the default OSRM backend versus the Esri service with agol_token, including limitations (fair-use, no SLA) and credential requirements. It does not explicitly state when not to use the tool, but the context is adequate given the sibling list.

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 burden and provides useful behavioral details: ownership restriction, return format (JSON with {ok} or {ok: false, error}), and the implicit mutating nature of cancellation. It could mention irreversibility, but for a cancel operation this is sufficient.

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 sentences, front-loaded with the core action. Each sentence adds value: operation, constraint, return format. 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?

The tool is simple (one required param, output schema present). The description covers operation, ownership, and return format. However, the token parameter is not explicitly tied to a schema property, leaving a minor gap for a low-complexity tool.

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

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

Schema description coverage is 0%, so the description must explain parameters. It impliedly refers to schedule_id (the schedule to cancel) and hints at token (API key ownership), but never explicitly defines either. The token parameter, in particular, is left unexplained beyond 'API key' in prose.

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 function: 'cancel a schedule created by bundle_create_export_schedule.' It uses a specific verb ('cancel') and resource ('export schedule'), distinguishing it from siblings like bundle_create_export_schedule or bundle_export_fixed.

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 specifies the exact use case: cancel schedules created by a particular tool, and adds a key constraint ('Only the API key that created it can cancel it'). It does not explicitly name alternatives, but the context is clear enough for this simple operation.

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 supplied, so the description carries the burden. It discloses the return wrapper ('JSON {ok, geojson}'), the output type ('FeatureCollection of points'), and a key behavior ('Properties are kept'). This goes beyond the bare schema, though it omits edge-case handling such as invalid geometries or mixed geometry types.

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 compact (three sentences), front-loaded with the core purpose, and every sentence adds value: purpose, examples, property preservation, and output format. There is no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter compute tool with an output schema, the description covers the main input/output contract and key behavior. It is sufficiently complete for an agent to select and invoke it, although it could mention limitations for degenerate or mixed geometries.

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 only one parameter, 'geojson', the schema provides just a type string and 0% description coverage. The description partially compensates by implying the input features should be polygons/lines ('each polygon/line feature'), but it does not explicitly state the expected GeoJSON structure (e.g., FeatureCollection vs geometry) or coordinate assumptions.

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 opens with a specific verb+resource: 'Get the center point of each polygon/line feature', and provides concrete paraphrase examples ('find the center of each parcel', 'convert polygons to points for labeling'). This clearly distinguishes it from sibling geometry tools like convex_hull_geojson or envelope_geojson by focusing on per-feature centroids.

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?

Examples like 'find the center of each parcel' and 'centroid of each feature' indicate the typical labeling/point-conversion use case, providing clear context for when to invoke this tool. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusion 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 fully disclose behavior. It describes the return format but omits important details such as authentication requirements, error handling for invalid URLs, rate limits, or any side effects. This is insufficient for a tool that makes external API calls.

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 well-structured sentences. The first sentence states the main action, and the second details the return format. No extraneous information is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the output schema is partially described (returned JSON structure), the description fails to clarify required vs optional parameters, provide example values, or explain how to obtain service_url. Given the tool has 2 parameters and non-trivial dependencies, this is incomplete.

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%, meaning the input schema provides no parameter documentation. The description does not explain the parameters token and service_url, leaving the agent to guess their meaning and usage. This is a critical 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 uses a specific verb 'Inspect' and resource 'field schema of an ArcGIS FeatureServer layer'. It is not a tautology and clearly states the tool's function. However, it does not differentiate itself from siblings like audit_service or check_service_health, which could have overlapping functionality.

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 'useful before importing/mapping data', providing a clear use case. However, it does not specify when to avoid using this tool, nor does it mention any alternatives among the 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 carries full burden. It describes the return JSON format, which adds value, but does not disclose whether the tool is read-only, requires authentication, or has any side effects. A 3 is appropriate for adequate but incomplete 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 two sentences: the first states the purpose, the second lists return fields. It is front-loaded and contains no 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?

Given the low parameter coverage (0%), the description should compensate but only lists return fields, which are already defined in the output schema. It does not explain the token parameter or provide usage context. For a simple health-check tool, it is moderately complete but has 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 description coverage is 0%, and the description adds no parameter-level meaning beyond the parameter names. It mentions 'service_url' implicitly in the purpose but does not explain 'token' or provide formatting details. This is a missed opportunity.

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: checking if an ArcGIS FeatureServer layer is reachable and responsive. It specifies the verb 'check' and the resource 'service health', and distinguishes from sibling tools like 'audit_service' by focusing on basic reachability.

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 a clear purpose but lacks guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or compare to sibling tools like 'audit_service' or 'full_service_audit' for deeper checks.

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 fully discloses behavior: it is free, requires Authorization header, returns JSON with specific fields, and describes error case. No contradictions.

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 (three sentences) and front-loaded with essential information (FREE, purpose, authentication). 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 no parameters and an output schema that is described (fields returned), the description covers all necessary aspects: purpose, authentication, return format, and error handling.

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 0 parameters and 100% coverage. The description adds value by explaining the purpose and the context of the wallet balance, which is useful beyond the empty 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 checks the user's MCP credits wallet balance. It explicitly uses the verb 'check' and the resource 'wallet balance', and distinguishes itself from paid tools like assess_property_hazard.

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 explains when to use the tool (to check balance) and notes it is free and requires an API key. It does not explicitly mention alternative tools for similar purposes, but the context of being a wallet check is clear.

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 discloses data source, resolution (300m), coordinate system (WGS84), return format (JSON with specific fields), and current operational status (gated, off pending smoke-check). This gives good insight into tool behavior and limitations.

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, but includes a lengthy note about source swap and status. While informative, this extra detail could be separated or shortened. Not overly verbose but not maximally concise.

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 point query tool with an output schema (not shown), the description covers key aspects: what it does, data source, resolution, return format, and current operational status. This is sufficient for an agent to understand and 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 coverage is 0%, so description must compensate. It adds meaning by specifying that the point is in WGS84 and that lon/lat are used, but does not detail ranges, validation, or order. Partial compensation, not exhaustive.

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 classifies land cover at a WGS84 point using a specific data source (ESA CCI Land Cover 2018). It includes verb (classify), resource (land cover), and coordinates. It distinguishes from siblings by specifying the exact classification task, which is unique among the listed sibling tools.

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 explicitly state when to use this tool versus alternatives. It provides context about the source status (gated, off pending check) but no guidance on when it is appropriate or what other tools might be used for similar tasks.

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 must fully disclose behavior. It describes the output structure but omits critical behavioral traits such as read-only nature, authentication needs (tokens), error handling, or rate limits. The return type is given but not how the tool behaves in 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?

Two sentences: first states purpose, second describes output and use case. No unnecessary words, front-loaded with key information. Every sentence 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?

Given 4 parameters (2 required) and no schema descriptions, the description is insufficient. It lacks details on token handling, URL format, prerequisites (e.g., layer must be FeatureServer), and fails to fully explain the JSON diff structure. An output schema exists but is not referenced.

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%, yet the description does not explain any parameter. It only implicitly refers to the two service URLs but provides no details on token parameters or their purpose. The description adds minimal value beyond parameter names.

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 compares field schemas of two ArcGIS FeatureServer layers, with a specific verb (compare) and resource (schemas). It distinguishes from siblings by its focus on schema comparison rather than geometry or data content.

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 'useful for QA before an import or migration,' providing clear context for when to use. However, it does not explicitly state when not to use it or differentiate from alternatives like geojson_diff.

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 1000-point limit, axis order dependence, and return format. However, it lacks details on error handling for invalid EPSG codes or points exceeding the limit. Overall, key behavioral traits are covered.

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: three sentences covering purpose, points format, and return structure. It is front-loaded with the core action and limit. No extraneous 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's simplicity (3 parameters, no enums, no output schema) and the existence of output schema (implied by context), the description covers essential aspects: usage context, limit, axis order, and return shape. Missing error details but sufficient for basic usage.

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 add meaning. It explains the points parameter format ([[x, y], ...]) and the axis order dependency, which the schema does not. The EPSG codes are integers but no further details on valid values. This adds significant value beyond the bare 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 converts coordinate pairs between EPSG coordinate systems with a 1000-point limit. It distinguishes from sibling tools like reproject_geojson which handle GeoJSON objects. The verb 'convert' and resource 'coordinate pairs' are specific.

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 indicates using this tool for point conversions between EPSG systems and notes the axis order convention, but does not explicitly state when to choose this over alternatives like reproject_geojson or epsg_suggest. No when-not-to-use guidance is 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 for behavioral disclosure. It mentions the output format but does not state whether this is a read-only operation, whether it modifies the input, how errors are handled, or any prerequisites (e.g., minimum number of points). This is a notable gap for a tool with no annotation support.

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, immediately defines the core concept, gives two relatable examples, and states the return format. There is no redundancy or filler; every sentence contributes meaning.

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 availability of an output schema (not shown), the return mention is helpful but not essential. The tool is simple, but the incomplete parameter guidance and lack of sibling differentiation leave gaps. An agent might not know precisely what GeoJSON structure to pass or why this tool is preferable to envelope_geojson, so overall it is minimally viable but incomplete.

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 lists a single string parameter 'geojson' with no description, and schema coverage is 0%. The description's phrase 'all input features' hints that the value should be a GeoJSON collection of multiple features, but it does not specify the exact expected format (FeatureCollection vs GeometryCollection), coordinate order, or error handling. The description fails to compensate for the schema's lack of detail.

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 operation: 'Draw the smallest polygon that wraps around all input features (a convex hull)' and provides concrete natural-language examples. However, it does not explicitly distinguish this tool from closely related siblings like envelope_geojson or minimum_rotated_rectangle, so it falls just short of a perfect score.

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 examples ('draw a boundary around these points', 'find the outer perimeter of my data') provide clear context for when this tool is appropriate. There is no explicit discussion of when not to use it or which alternative to choose (e.g., envelope for bounding boxes), but the intended use case is understandable.

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 discloses the return JSON structure and notes that token is only for private layers, but does not mention rate limits, error handling, or behavior on unavailable services. The description offers basic transparency but lacks depth.

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 three sentences, front-loading the purpose. It is efficient but could be more structured (e.g., using bullet points for parameters). 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 the simple tool (count, 3 parameters, output schema described), the description covers the essential aspects. Sibling tools are many but distinct enough that the core function is clear. However, for a counting tool, the description could mention if count is approximate or exact.

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 well: it explains service_url format, token purpose, and where defaults. However, it does not detail the token's usage (e.g., how to obtain it) or the WHERE clause syntax beyond a default.

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 ('count') and resource ('features in an ArcGIS FeatureServer layer'), with optional WHERE filtering. It clearly distinguishes from sibling tools like query_features (which returns features) and query_statistics (which computes aggregates).

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 use for counting features with optional filtering, but does not explicitly state when to use this tool over alternatives. It provides no 'when not to use' guidance or comparisons to sibling tools.

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 transparency burden. It discloses that coordinate columns are auto-detected and that the output is a GeoJSON FeatureCollection as a JSON string. It does not cover edge cases or error behavior, but for a simple conversion tool the key behaviors are communicated.

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 opens with the core purpose and includes several user-phrase examples that help with intent matching. It is slightly long but every part contributes value, so it remains well-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 low complexity (one parameter and an output schema), the description covers the essential purpose, input expectations, and return type. The only significant gap is input format clarity, which is already captured in parameter semantics.

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 one required 'csv' string parameter with 0% description coverage, and the description does not clarify whether the value should be raw CSV content, a file path, or a URL. It only implies the data should contain lat/lon or X/Y columns, which is not enough to fully resolve 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 tool converts a CSV/spreadsheet with lat/lon or X/Y columns to GeoJSON, and explicitly mentions auto-detection of coordinate columns. This distinguishes it from sibling converters like geojson_to_csv, gpx_to_geojson, or kml_to_geojson.

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 through user-intent examples like 'map this spreadsheet' and 'turn my Excel export into map points', which help an agent decide when to use this tool. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficient for selection.

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 fully discloses behavior: only longitude can exceed ±90, so certainty when values exceed that; otherwise returns 'inconclusive' without guessing. It also notes pure computation and no external API, plus the return format.

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 and front-loaded: the first sentence states the purpose. 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?

Given the simple single-parameter input and the presence of an output schema (mentioned but not shown), the description provides sufficient context: explains input semantics, behavioral certainty, and return JSON structure. No 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 0%, but the description explains that the tool takes [x,y] pairs and detects their order, adding context beyond the schema's raw array definition. It clarifies the semantic meaning of the input.

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 verb 'detect' and clearly states the resource: coordinate order. It distinguishes itself from siblings like convert_coordinates by focusing on order detection, not conversion.

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 conveys when to use the tool: when there is confusion about coordinate order, a common real-world problem. It does not explicitly state when not to use it, but the context is clear.

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 must disclose behavior. It mentions free usage, no API key, and return JSON structure. However, it omits details like rate limits, pagination, error handling, or behavior when no results are found. Adds some context but not comprehensive.

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 reasonably concise (4 sentences) and front-loaded. It uses line breaks and a bullet-like list for the output JSON. It could be slightly tighter, but it remains informative without being 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?

The tool is low complexity with 2 parameters and an output schema. The description covers the main purpose and output fields but lacks details on error handling, edge cases (e.g., no results), or parameter formatting. Adequate but not fully 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 0%, so the description should explain parameters. It only implies 'query' via keyword search and does not mention 'limit'. No elaboration on default values, constraints, or usage. This leaves the agent underinformed about 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 specifies the tool performs keyword search across ArcGIS Hub Open Data, returning real service URLs. It distinguishes itself by noting it's not a universal open-data search, and it lists compatible sibling tools, making 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 guidance: it states when to use (for ArcGIS Hub open data search), how results are used (with specific tools like query_features), and limitations ('Not a universal open-data search'). It also notes no API key required, aiding tool selection.

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 convey behavioral traits. It states the merge operation and the return format, but does not disclose whether geometries are modified, authentication requirements, or behavior for non-overlapping geometries.

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 efficiently cover purpose, optional grouping, and return value. No redundant information, and key details are 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 description covers purpose, parameter usage, and output format. With two parameters and an explicit return structure, it is largely complete. However, it lacks error handling details or input validation notes, which would enhance completeness for a geospatial 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 0%, so the description must add meaning. It explains that the 'by' parameter groups features and that each distinct value yields one dissolved feature. 'geojson' is not elaborated but is expected as a GeoJSON string. The description adds value beyond the bare 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 merges overlapping or adjacent geometries into one, with optional grouping by a property field. This distinguishes it from sibling tools like buffer_geojson or overlay_geojson, which perform different geometric 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 indicates when to use the tool (to merge overlapping/adjacent geometries) and mentions the optional grouping parameter. However, it does not explicitly exclude cases or compare with alternatives like overlay_geojson for union operations, leaving some ambiguity.

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 explicitly states that arcs/circles are tessellated into LineString/Polygon, that splines/text/hatches/3D solids are skipped (not errored), and that each feature's properties.layer will carry the DXF layer name. These are valuable behavioral details 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?

The description is front-loaded with the primary purpose, followed by concrete examples, conversion details, and usage tips. Every sentence adds information—no filler. Though moderately long, it remains efficient and well-organized.

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 key aspects: input (DXF content), output (GeoJSON with layer attribute), entity handling (which convert, which are skipped), optional filtering, and a related tool (list_dxf_layers). The existence of an output schema reduces the need to describe return values, and the description covers the rest comprehensively.

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 by explaining the `layer` parameter ('Pass `layer` to return only that layer's entities') and referencing list_dxf_layers. The `dxf` parameter is not explicitly explained, but its meaning is strongly implied by the tool name and description ('Convert an AutoCAD DXF file's contents'). Thus, it adds meaning for at least one parameter and contextualizes both.

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 function: 'Convert an AutoCAD DXF file's contents to GeoJSON'. It provides multiple usage examples and specifies exactly what entity types are converted (POINT/LINE/LWPOLYLINE/POLYLINE/ARC/CIRCLE) and which are skipped, effectively distinguishing it from related tools like georeference_dxf or dxf_to_pdf_report.

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 clearly implies when to use the tool (e.g., 'convert this DXF to GeoJSON', 'extract only the UTILITIES layer') and references a prerequisite workflow (using list_dxf_layers to discover layer names). However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.

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 carries the burden. It discloses critical behavioral traits: paid (150 credits), requires Authorization Bearer + sufficient balance, output is base64 PDF, and no basemap due to local units. This goes beyond typical descriptions. Not disclosing error behavior or idempotency is a minor gap, but the cost and auth warnings are particularly valuable.

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?

Every clause earns its place: cost warning, core function, examples, no-basemap limitation with alternative, auth requirement, and return structure. It is front-loaded with the most important fact (PAID) and remains compact. No filler or repetition.

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 output schema exists, the description doesn't need to explain return values, but still does so concisely. It mentions the required auth and credit balance, which is essential for a paid tool. It also distinguishes from georeference_dxf and enough context to select this tool over many siblings. Missing a small note on the optional 'title' parameter's effect, but overall the description is quite 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 0%, so the description must compensate. It gives context about the 'dxf' parameter ('render a DXF drawing') but does not specify the exact input format (e.g., raw DXF content, file path, or base64). The optional 'title' parameter is not mentioned at all, though its default is in the schema. Partial compensation, but leaves ambiguity for one of two 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 opens with a specific verb+resource: 'render a DXF drawing to a one-page PDF site-plan report'. It clearly distinguishes itself from siblings like dxf_to_geojson and export_geojson_to_pdf by specifying the deliverable (site-plan report with vector plot, entity breakdown, layer list). It also gives example prompts, making the tool's 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?

Provides explicit when-to-use guidance via examples ('make a PDF of this site plan'). It also explicitly tells the agent when NOT to use it: 'No basemap... use georeference_dxf first if you need a real-world-referenced report.' This direct exclusion and alternative are exactly what the dimension asks for.

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 takes on full burden. It discloses it's a thin wrapper around share_map, mentions the 30-day TTL, and specifies the return JSON fields. However, it doesn't detail side effects, auth needs, or error conditions, leaving minor 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?

Two sentences with no filler. The first sentence covers purpose and relationship to share_map, the second lists output fields. Highly efficient and 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?

While it explains the output schema and relationship to share_map, it misses parameter documentation. Given the complexity (4 params, 1 required) and presence of an output schema described in text, it is mostly complete but has a notable gap in parameter semantics.

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 parameter coverage is 0%, and the description does not explain any of the four parameters (name, width, height, geojson). It doesn't clarify that geojson is required or how the optional parameters affect output. This is a significant omission given the lack of 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 it provides an iframe embed code for a live interactive map. It explicitly distinguishes itself from the sibling share_map by noting it's for embedding rather than sharing a link. The verb 'provides embed code' is specific and the resource is well-defined.

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 explains when to use this tool (for embedding in a website/dashboard) and contrasts with share_map (for sharing a link). It doesn't list exclusions but provides clear context for appropriate use.

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 burden and provides key behavioral details: per-feature processing, property preservation ('Properties are kept'), and return format ('Returns JSON {ok, geojson}'). It omits error handling, but for a pure read-only computation 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?

Three short, impactful sentences: action with definition and examples, property preservation, and return shape. Every clause earns its place with no filler.

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 per-feature bounding-box utility, the description covers the core behavior, provides examples, notes property preservation, and states the JSON response. An output schema exists so detailed return fields are not necessary. The only minor gap is explicit input format guidance, but the parameter name and examples make it discoverable.

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%, and the description never explains the geojson parameter beyond the schema's type string. There is no guidance on expected GeoJSON structure, coordinate order, or constraints, so it fails to compensate for the low schema coverage.

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 'Get the bounding box (min/max rectangle) around each feature' with a specific verb and resource, and provides natural-language examples. It distinguishes itself from geometric siblings like convex_hull_geojson and minimum_rotated_rectangle by emphasizing per-feature rectangular extent.

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 includes example user phrasings such as 'get the bounding box of this shape' and 'bbox for each feature', which signal when to use the tool. However, it does not explicitly exclude alternatives like convex hull or minimum rotated rectangle, so it stops short of full 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 carries full burden. It lists output fields but does not disclose behavioral traits like internet dependency, performance, or warning conditions.

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, zero waste. Efficient and clear.

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 suggestion tool with 2 parameters and an output schema, the description covers core functionality and output format. Could mention limitations (e.g., only UTM zones).

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 adds minimal context beyond parameter names: it clarifies input is in WGS84 lon/lat but does not specify ranges, units, or coordinate order.

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 suggests UTM EPSG codes for projecting WGS84 lon/lat, with a specific purpose (accurate metric measurements). It distinguishes from sibling tools like convert_coordinates or reproject_geojson.

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 needing UTM projection for metric measurements but does not explicitly state when not to use or mention alternatives, leaving some ambiguity.

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 fully discloses behavior: it is free, does not execute the tool, and returns different JSON structures based on payment type. Covers edge cases like x402 pricing.

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 thorough but slightly lengthy. However, it is well-structured with front-loaded key info and each sentence adds value. Minor redundancy in explaining both response types.

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 (has output schema: true), the description explains return formats for both credits-wallet and x402 tools. It covers all necessary information for correct invocation.

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 compensate. It explains that 'tool_name' is the tool to estimate, 'units' is for per-unit tools and defaults to 1, and how units are handled for flat-priced tools.

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 cost of a paid tool without executing it. It specifies the verb 'quote' and resource 'cost', and distinguishes from siblings by being free and used for cost estimation.

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 'call this before assess_property_hazard etc.' and explains the units parameter for per-unit tools. Provides clear guidance on when to use and how parameters work.

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 paid usage, credit cost, auth requirements, output format (base64-encoded xlsx), and return structure. No mention of error cases or rate limits, but fair given no annotations.

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, front-loaded summary, uses bullet-point-like structure without clutter. 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?

Covers core behavior, output schema exists for return values, and description adds feature_count. Missing error handling, validation, or more parameter details, but acceptable for this 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?

Schema coverage is 0%; description only names 'geojson' but does not explain expected format, size limits, or that it must be a string. Schema provides type 'string' but description adds no extra 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?

Description uses specific verb 'convert' and resource 'GeoJSON FeatureCollection to Excel workbook', distinguishes from other export tools (export_geojson_to_pdf, etc.) and explicitly handles geometry types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly states it's paid (80 credits), requires auth and sufficient balance, and distinguishes from web app's Excel export. Lacks explicit when-not-to-use vs. alternatives like geojson_to_csv.

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. It discloses credit cost, authentication requirement, output format (base64-encoded PDF), return schema (ok, pdf_base64, feature_count, truncated, size_bytes), and that it produces one page with map and table. It does not detail error handling or validation, but covers key behavioral 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?

The description is a single, well-structured sentence packed with essential information: cost, purpose, differentiation, prerequisites, and output format. Every part adds value, and it is front-loaded with the cost to set expectations.

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 (paid, auth, output schema), the description covers most needs: purpose, alternatives, auth, credits, return fields. However, it omits details like maximum features, meaning of 'truncated', and parameter explanations, leaving minor 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 0%, so the description must compensate. It implies the geojson parameter by referencing 'GeoJSON FeatureCollection' but does not explain the 'title' or 'accent' parameters. Their defaults are given in the schema, but meaning (e.g., accent is a color) is left unclear for the agent.

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: rendering an ad-hoc GeoJSON FeatureCollection to a one-page PDF report (static map + property table, base64-encoded). It explicitly distinguishes this from the web app's PDF Builder, which is tied to AGOL services and quota-gated, clarifying when to use this tool versus alternatives.

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 guidance: use this for GeoJSON the agent already has in hand, not for AGOL-service-tied data. It also lists prerequisites (Authorization: Bearer, sufficient credit balance) and mentions the cost (150 credits), helping the agent decide when to invoke.

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 bears the full burden of behavioral disclosure. It describes the return format but omits important traits such as authentication requirements (the token parameter's role is unclear), error handling, or rate limits. The tool's behavior under failure conditions is not addressed.

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 two sentences that front-load the purpose. However, it could include additional crucial information (like parameter details) without becoming overly verbose, so slightly more structure would improve completeness.

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 low-complexity, and the description covers the return format partially. However, given the lack of annotations and parameter descriptions, the description is not fully complete. An agent would need additional context to use it effectively, especially regarding the token and service_url.

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%, and the description does not explain the parameters. The token parameter's purpose and requiredness are not clarified; the service_url format is implied but not specified. The return structure is described, but this does not add meaning to the parameters themselves.

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 extracts coded value domains from an ArcGIS FeatureServer layer, which is a specific verb and resource. The purpose is unambiguous and distinct from sibling tools, which focus on geometry, analysis, or other GIS 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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or limitations. It only states what the tool does without context for appropriate 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 key behavioral traits: it is sample-based (first 200 records), returns a JSON structure with layer_name, issues array, issue_count, sample_size, and note. This provides clear expectations beyond the missing annotations. No contradictions.

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, front-loading the main purpose and listing issues. It could be slightly more organized (e.g., separating parameter notes), but it is efficient with minimal waste.

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 an output schema (mentioned) and moderate complexity, the description covers the main scanning purpose, sample behavior, and return format. However, it omits parameter explanation, which is a gap for a tool with only two parameters.

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%, and the description does not explain the parameters 'service_url' or 'token'. Since the description adds no meaning beyond the schema, it fails to compensate for the lack of parameter documentation.

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: scanning an ArcGIS FeatureServer layer for common problems, listing specific issues (missing ObjectID, disabled query, stale data, etc.). This distinguishes it from sibling tools like audit_service or full_service_audit, which are more comprehensive or focused on other aspects.

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 quick checks on layer health, but does not explicitly state when to use this tool versus alternatives like audit_service or full_service_audit. No when-not or exclusion criteria are given.

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

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

Discloses use of GEOS make_valid, return format (JSON with ok, fixed_count, feature_count, geojson), and behavior on valid geometries. No annotations provided, so description carries full burden; it does well but lacks mention of error conditions.

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. Every sentence adds value: first defines purpose, second describes return and edge case.

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, input, output, and behavior for valid geometries. Output schema exists but not shown; description still provides enough detail for a single-parameter 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 has 0% description coverage, but description adds that input is GeoJSON and output includes the fixed geometry. However, does not elaborate on format or constraints beyond the schema's type definition.

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 states specific verb 'repair', resource 'geometries', and lists exact issues (self-intersections, bad rings). Clearly distinguishes from sibling tools like simplify_geometry or buffer_geojson.

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?

Implied usage for invalid geometries, but no explicit 'when to use' or 'when not to use' compared to alternatives. States that valid geometries are untouched, providing some 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 the burden. It describes the return format (JSON fields) and the merged nature of the response, but does not disclose any other behavioral traits such as authentication, rate limits, side effects, or error conditions.

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 two sentences: the first states the core purpose and the second details the return schema. It is front-loaded and efficient, though the structure could be slightly improved by using bullet points for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool replaces three separate tools, the description covers the main output fields but omits explanation of the 'token' parameter. With an output schema described in text, it is moderately complete but not exhaustive.

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%. The description mentions 'service_url' implicitly via 'one-call QA report' but does not explain the 'token' parameter at all, leaving the agent without guidance on its purpose or 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 uses a specific verb ('Complete'), names the resource ('QA report'), and clearly distinguishes from siblings by naming three separate tools it replaces (grade_service, audit_service, find_layer_issues). 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 explicitly states that this tool 'replaces 3 separate calls', giving clear guidance on when to use it. However, it does not explicitly state when not to use it or mention alternatives for partial needs.

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. Explains rendering path (reuses PDF map reports logic), basemap options, and agol_token behavior for single-Point vs multi-feature input. Mentions return format. Missing error handling details, but overall 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?

Description is reasonably concise (few sentences) with a clear structure: purpose, distinction from sibling, basemap detail, token behavior, return format. Each sentence adds value, though could be slightly shorter.

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 and an output schema (described in text), the description covers essential aspects: purpose, usage context, behavioral details, and return fields. Lacks input validation or error states, but sufficient for typical use.

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 (no parameter descriptions in JSON schema). Description adds meaning for basemap (lists options) and agol_token (explains conditional behavior), but does not detail width, height, accent, or geojson beyond stating they exist. 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?

Clearly states it renders GeoJSON to a static PNG map image (base64 data URL) for embedding in reports/emails/documents, distinguishing it from share_map (interactive live page). The verb 'render' and resource 'GeoJSON FeatureCollection/Feature' are specific.

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 mentions when to use (embedding in reports/emails/documents) and contrasts with share_map. Provides context for optional agol_token usage, but does not specify when not to use other siblings beyond share_map.

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 provider behavior (rate limits, free), credential needs, and return format. Explains that agol_token routes through Esri's service with user's own quota. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.