Server Quality Checklist

Tool Scores

• check_statusA
  4.1/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden, and it does well. It discloses that results are archived locally, that polling is free, that the job runs independently of polling, and that repeat calls are served from disk. These are meaningful behavioral traits 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.

  Conciseness5/5

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

  Three sentences, each adding distinct value: core action, result handling, and cost/behavior semantics. The most important information is front-loaded and there is no wasted text.

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

  Completeness4/5

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

  For a polling/status tool with three well-documented parameters, the description covers the essential behaviors: what happens on completion, persistence, and cost. An output schema is absent, but the description does not fully describe the result structure or error cases. Mostly complete, with minor gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3 even without extra parameter detail. The description adds only general context about waiting and results, while the schema already documents format, wait_s, and activity_id. It does not materially enhance parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool checks on a submitted analysis and can wait for completion, with the result returned once finished. It identifies the resource (submitted analysis) and the action (check/wait), but does not explicitly differentiate it from sibling tools like get_result_slice. This is clear but lacks direct sibling distinction.

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

  Usage Guidelines4/5

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

  The description gives practical guidance: polling is free, the job runs regardless of polling, and repeated calls after collection are served from disk at no cost. This implies use after a submit_* call and encourages polling, but does not explicitly state when to prefer alternatives like get_result_slice. Clear context but no exclusions.

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

• create_heatmapA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description bears full responsibility for disclosing behavior. It does this well: expected duration (21-38s), timeout behavior (returns activity_id, job keeps running), idempotent caching for identical earlier requests, and the important local-time interpretation of start_time. The absence of error-handling or quota details keeps it from a 5.

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

  Conciseness4/5

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

  The description is dense but well-structured: behavior first, timing details second, then parameter meanings. Some material duplicates the schema's filter_type text, which costs a little efficiency, but every sentence serves a practical purpose and the critical timeout/archive behavior is front-loaded.

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

  Completeness4/5

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

  For a 12-parameter tool with no output schema, this description covers the workflow well: inline wait, timeout fallback, later retrieval via check_status, archive reuse, filter modes, granularity, analytic_type, and local-time semantics. It does not describe the successful inline return payload or clarify direction/threshold, but the overall invocation context is mostly complete.

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

  Parameters3/5

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

  The description restates filter_type combinations and granularity defaults that already appear in the schema, and adds useful 'omit it' guidance for granularity and analytic_type. However, direction and threshold are unexplained in both schema and description, and schema coverage is only 58%. This adds some value beyond the schema but leaves significant parameter semantics to inference.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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: 'Run a temperature heatmap and wait for the result inline.' This clearly differentiates from sibling tools like submit_heatmap (which likely returns immediately) and check_status (which collects results later). It is not a tautology and conveys the tool's core behavior.

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

  Usage Guidelines4/5

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

  The description tells the agent when the inline-wait model applies, what happens on timeout, and that check_status can later collect the activity_id. It also notes that duplicate requests are served from the local archive. It does not explicitly name submit_heatmap as the alternative for fully asynchronous submission, but the wait/timeout behavior strongly implies the tradeoff.

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

• split_aoiA
  4.1/5.0
  Behavior4/5

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

  With no annotations on the tool, the description carries the full behavioral disclosure burden. It usefully states 'Local computation, no credits' and explains that there is no default maximum cap. It does not describe the output format or potential failure modes, which would be needed for a 5.

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

  Conciseness5/5

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

  Three sentences, each with a distinct purpose: the action, the appropriate use case, and the cap/credit caveats. There is no filler, and the most important information is front-loaded.

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

  Completeness4/5

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

  For a two-parameter local utility, the description covers the core purpose, when to use it, parameter nuance, and cost behavior. It does not specify the exact return contract, but 'grid of smaller areas' sets a reasonable expectation. A 5 would explicitly state the return payload or edge cases.

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

  Parameters4/5

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

  The schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds value specifically for max_area_km2 by explaining that the cap depends on plan and should be taken from contract or rejection messages. polygon_aoi receives minimal added meaning beyond 'area of interest,' but the overall parameter guidance is improved.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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: 'Cut an area of interest into a grid of smaller areas, each at or under a maximum size you specify.' This makes the function's purpose immediately clear. It does not explicitly name or contrast sibling tools such as validate_aoi, so it stops short of full differentiation.

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

  Usage Guidelines4/5

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

  The description gives an explicit trigger condition: 'Use it when the API rejects an area as too large.' It also provides practical guidance about deriving the max area from the contract or rejection message. It lacks an explicit 'when not to use' or named alternatives, which prevents a perfect score.

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

• submit_satelliteA
  4.1/5.0
  Behavior4/5

  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 asynchronous nature by stating 'return an activity_id. Collect it with check_status,' which tells the agent this is a job-submission operation rather than a direct result fetch. It does not mention side effects, credits, or validation requirements, but the core behavioral contract is transparent.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. 'Submit satellite land-cover segmentation for a point' is front-loaded and immediately states the action and resource, while the second sentence efficiently links to check_status. Every word earns its place.

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

  Completeness3/5

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

  With 6 parameters, no output schema, and no annotations, the description gives the essential workflow—submit and poll via check_status—but omits context such as whether the point must be inside a previously validated AOI, how long processing might take, or any credit/cost implications. The schema covers parameter formats, so basic invocation is possible, but a fully informed agent would need more context.

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

  Parameters3/5

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

  Schema description coverage is 83%, which is high, so the schema already documents most parameters. The description adds only the notion of 'a point' (latitude/longitude) and provides no additional detail about optional parameters like filter_type, start_date, or granularity. This meets the baseline for high schema coverage but adds no extra semantic value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Submit satellite land-cover segmentation for a point.' It clearly identifies what the tool does and distinguishes it from sibling submission tools like submit_streetview and submit_heatmap through the 'satellite land-cover segmentation' resource. It also names the return artifact (activity_id), making the tool's role unambiguous.

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

  Usage Guidelines4/5

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

  The description gives clear context: use this tool to submit satellite land-cover segmentation for a point, and then collect the result via check_status. It does not explicitly list when not to use it or name alternatives, but the resource type and follow-up instruction provide enough guidance for an agent to select it among siblings.

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

• get_storage_infoA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It meaningfully explains that nothing is ever deleted automatically, that stored results persist and cost money, and that the directory is user-managed. It does not cover auth needs or rate limits, but for a simple read-only storage summary the key behavioral traits are disclosed.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary output summary and followed by a useful behavioral note about persistence and cost. Every sentence adds distinct value with no redundancy.

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

  Completeness4/5

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

  Given the absence of annotations, parameters, and an output schema, the description covers all essential aspects: what data is returned, where it lives, and how it behaves over time. It could be more explicit about the exact return format, but for a no-argument storage information tool it is sufficiently complete.

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

  Parameters4/5

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

  The tool has zero parameters, so the description does not need to explain parameter meaning. The input schema is empty and the description fully describes what the call returns; a baseline of 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description specifies a clear resource (local disk archive) and states exactly what the tool reports: result counts by endpoint, space usage, downloaded report files, and storage location. It is easily distinguished from siblings like get_credit_usage or get_result_slice, which address different concerns.

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

  Usage Guidelines3/5

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

  The description implies the tool is for inspecting and managing archived storage, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. The intended usage is evident from context, but the guidance is not made explicit.

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

• submit_streetviewA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It explicitly reveals the asynchronous pattern: the tool returns an activity_id rather than a direct result, and the result must later be collected via check_status. This is a key operational trait that an agent needs to know. It does not mention cost, permissions, or failure modes, but the core submit-then-poll behavior is transparently conveyed.

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

  Conciseness5/5

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

  Two sentences with zero redundant wording. The primary action and output are front-loaded, and the follow-up instruction to use check_status is short and direct. Every word adds value.

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

  Completeness4/5

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

  For a submit-style asynchronous tool with no output schema, the description sufficiently explains what is returned and how to retrieve the eventual result. All required parameters are fully documented in the schema. A minor gap is the lack of any mention of whether this operation consumes credits or requires a valid AOI, but the core invocation flow is complete.

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

  Parameters3/5

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

  The input schema covers all 5 parameters with descriptive text, so schema coverage is 100%. The description adds context that the parameters describe a street-view point and scene analysis, but it does not add meaning beyond the schema's own parameter descriptions. This meets the baseline for schema-heavy documentation but does not exceed it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Submit street-view scene analysis') applied to a resource ('a point') and the expected output ('return an activity_id'). It clearly identifies that this is the street-view variant among sibling submit tools like submit_satellite and submit_heatmap, so an agent can distinguish it without opening schemas.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: submit analysis, get an activity_id, then collect with check_status. It does not explicitly enumerate when to choose this over submit_satellite or submit_heatmap, but the resource type is implicit in the name and description, providing adequate direction. No exclusions or alternative conditions are stated, so an agent must infer modality from the tool name.

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

• validate_aoiA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden and does well: it states that the tool costs nothing, makes no API call, only reports, and applies no size limit. It also discloses the heuristic nature of the transposition check with 'look transposed.' Minor omissions like handling of invalid GeoJSON or exact output formatting prevent a higher score.

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

  Conciseness5/5

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

  Three sentences, each earning its place: the first lists outputs, the second covers cost and network behavior, the third explains the no-limit policy. Key information is front-loaded and there is no filler.

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

  Completeness4/5

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

  The description is complete for a single-parameter reporting tool: it explains the purpose, the local execution, the lack of side effects, and the boundary around size limits. There is no output schema, but the description sufficiently conveys the kind of measurements returned, so an agent can anticipate the result without needing a full return-value spec.

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

  Parameters3/5

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

  The schema already fully documents the single parameter as a GeoJSON FeatureCollection, Feature, Polygon, or MultiPolygon. The description adds that the parameter is an 'area of interest' and that it is measured locally, but does not add format details beyond the schema. This meets the baseline for full schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb ('Measure') and resource ('GeoJSON area of interest') and lists concrete outputs: geodesic area, bounding box, edge lengths, ring closure, and transposition check. It also distinguishes itself from siblings by noting it runs locally and makes no API call, which separates it from the submit_* tools.

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

  Usage Guidelines4/5

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

  The description conveys when to use this tool: as a local, cost-free pre-flight check of an AOI before submission. It implies a validation workflow and notes that no size limit is applied because limits vary by plan, giving useful context. It does not explicitly name sibling alternatives like split_aoi, but the local/no-API-call framing makes the appropriate use clear.

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

• get_credit_usageA
  4.3/5.0
  Behavior3/5

  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 usefully explains that this is a live, authoritative view of account capabilities, and that area limits and endpoint access vary by plan. However, it does not explicitly state the operation is read-only/no side effects, nor does it mention any authentication requirements or response format nuances.

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

  Conciseness5/5

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

  Two compact sentences deliver all necessary information with no filler. The first sentence immediately states what the tool returns, and the second adds authoritative context about plan-dependent limits. Every sentence earns its place.

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

  Completeness5/5

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

  For a zero-parameter, no-output-schema tool with no annotations, the description is complete enough for an agent to know exactly what this tool provides and why it should consult it. It covers the return contents (plan, balance, per-endpoint usage), the authority of the data, and the variability of limits by plan.

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

  Parameters4/5

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

  The tool has zero parameters, so there are no parameter semantics to document. The description instead focuses on what the tool returns, which is appropriate. This matches the baseline for zero-parameter tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific resource (account plan, credit balance, per-endpoint usage breakdown) and clarifies this tool is the authoritative source for key capabilities. This distinguishes it from siblings like get_storage_info or submit_heatmap, which clearly serve different purposes.

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

  Usage Guidelines4/5

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

  The description clearly indicates when to use this tool: whenever you need authoritative plan limits, credit balance, or endpoint access details. It explicitly says these are 'not assumed anywhere in this server', giving the agent a strong signal to call this before making assumptions. It does not name specific alternative tools or provide explicit when-not-to-use guidance, 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.

• get_env_paramsA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the disclosure burden and does meaningful work: it reveals the heatmap-matching requirement, that from_activity_id is free and supplies the date, that the two temperature inputs are mutually exclusive, and that omitting analysis returns every parameter. It stops short of describing error behavior or the response envelope, but covers the non-obvious constraints.

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

  Conciseness5/5

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

  Three sentences with no filler: the first states what the tool returns, the second states the core precondition and how to satisfy it, and the third explains response narrowing. Key constraints are front-loaded.

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

  Completeness3/5

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

  The description is strong on the temperature/activity path but leaves a notable gap: it says the temperature must match 'the same place and time' and that from_activity_id supplies the date, yet it never explains how to specify the time when using temperature= directly. With no output schema and no annotations, a mention of filter_type/start_date/start_time or the response structure would make it fully complete.

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

  Parameters4/5

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

  Schema coverage is 67%, and the description adds semantics beyond the schema: mutual exclusivity of temperature and from_activity_id, the date-providing role of from_activity_id, and the narrowing effect of analysis. It does not add meaning for wait_s or start_date/start_time, but the schema already documents the remaining core parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a concrete resource ('Environmental parameters at a single point - humidity, heat index, wet bulb, air quality and more') and a clear action (get). This distinguishes it from sibling submit/validate tools and makes the tool's purpose immediately actionable.

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

  Usage Guidelines4/5

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

  It explicitly states the precondition (a temperature matching the heatmap), offers two mutually exclusive ways to satisfy it (temperature= or from_activity_id=), and explains when to omit analysis. It does not name alternative read tools such as get_result_slice, but the guidance for this tool's own options is specific and unambiguous.

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

• submit_heatmapA
  4.4/5.0
  Behavior4/5

  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 transparently states the asynchronous return behavior, the archive/cache behavior with from_archive and zero cost, and the local-timezone interpretation of start_time. It could add cost/rate or failure details, but the essential behavioral traits are disclosed.

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

  Conciseness5/5

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

  The description is information-dense and every sentence adds value: purpose, when-to-use, result collection, archive behavior, and parameter semantics. It front-loads the most important async behavior and remains readable despite covering several nuanced options.

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

  Completeness4/5

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

  For a complex tool with 10 parameters, no annotationns, and no output schema, the description covers the central return contract, filtering modes, optional parameters, and timezone handling. The main gaps are direction and threshold semantics and a bit more shape detail for polygon_aoi, but the tool remains usable with this definition.

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

  Parameters4/5

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

  Schema description coverage is high at 80%, and the description adds value by clarifying filter_type mapping to date/time fields, granularity omission behavior, analytic_type omission behavior, and local-timezone semantics. It does not explain direction or threshold, but those are optional and not heavily behooped.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a specific verb and resource: submit a temperature heatmap over an area, returning an activity_id immediately instead of waiting for completion. This distinguishes the tool from synchronous alternatives and clarifies its core purpose without ambiguity.

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

  Usage Guidelines4/5

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

  Explicit usage guidance is provided: 'Use this when you have other work to do, or for a large area.' It also directs the agent to collect results via check_status and explains the cached-result behavior. It does not explicitly contrast with create_heatmap or other submit tools, but the when-to-use criteria are clear.

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

• submit_heat_intelligenceA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and delivers: it discloses the ~395 second latency, the async expectation, the short-lived signed URL that is never stored, and exactly how the PDF is retrieved and delivered. This is far beyond the schema's structural information.

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

  Conciseness5/5

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

  Four dense sentences, each earning its place: action/return, latency, collection workflow, and parameter constraint. The most decision-relevant facts are front-loaded before workflow details.

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

  Completeness5/5

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

  For a six-parameter async submit tool with no output schema and no annotations, the description covers the full lifecycle: submission, latency, retrieval, result location, and parameter invariants. An agent has enough to call it correctly and know what to do afterward.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3; the description adds real value by stating that a temperature source is mandatory (temperature or from_activity_id, not both) even though neither is marked required in the schema. It also reinforces the complete-report requirement, though the schema already documents the five analysis categories.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence states a specific action and resource: submit a heat intelligence report for a point, with an explicit return (activity_id). It also distinguishes the tool from its companion sibling by directing collection to check_status, so an agent can tell submission from retrieval.

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

  Usage Guidelines4/5

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

  The description gives clear operational guidance: never wait inline, collect via check_status, and provide exactly one of temperature or from_activity_id. It does not explicitly contrast this tool with the sibling submit_heatmap/satellite/streetview tools, so it stops short of full when-not/alternative coverage.

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

• get_result_sliceA
  4.8/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full transparency burden. It goes well beyond a basic read description by disclosing: no API call and no cost, complete delivery of named formats versus context-budgeted auto mode, and that statistics for both the slice and full result are always reported. This prevents common misuses, like mistaking a slice maximum for the true maximum.

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

  Conciseness5/5

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

  Every sentence earns its place: purpose, cost/safety, paramter usage, format/budget caveat, and output statistics are each covered exactly once. The key behavioral trait (free/no API call) is front-loaded so an agent can immediately classify this as a cheap read operation.

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

  Completeness5/5

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

  Given 5 parameters, no annotations, and no output schema, the description is remarkably complete: it explains all slicing modes, format behavior and the context-budget nuance, and the statistics guarantee. The input schema covers antimeridian bbox and parameter types, so nothing essential is left unexplained for an agent to call this correctly.

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

  Parameters5/5

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

  Although schema coverage is 100% (baseline 3), the description adds substantial operational meaning beyond the schema: top_n is for "the hottest tiles," bbox for a "sub-area," every_nth for "a downsample," and the formats are mapped to concrete outcomes ("compact" vs "untouched payload"). This gives an agent a practical understanding of how to shape each parameter, not just its type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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: "Read part or all of an already-collected result from local disk." It clearly distinguishes this from sibling submission/creation tools by noting it "makes no API call" and reads "already-collected" results. The description also enumerates the different slicing modes, leaving no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The description gives clear when-to-use guidance: since it "Costs nothing and makes no API call, so use it freely." It also implicitly signals when-not: this is for already-collected results, not for starting new analyses, unlike sibling submit_* and create_* tools. However, it does not explicitly name the alternative tools or state "use submit_* instead when you need a new analysis," so it stops short of a full when-not/alternatives specification.

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