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

Annotations signal non-read-only behavior (destructiveHint true), and the description substantially augments this with concrete side effects: token cost range (5–123), charge-once semantics, async enqueue returning {status:'processing'}, and idempotent re-send behavior. This is transparent and does not contradict the 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?

The description is organized into clear informational blocks — purpose, cost, async behavior, timing, and retrieval — with no filler. Although long, every clause contributes essential operational detail, and key facts 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?

For a high-complexity async tool with an output schema, the description thoroughly covers cost, enqueue response shape, timeout resilience, run duration, retrieval via a sibling tool, and idempotent retry. The structured brief itself is handled by the output schema, so no critical context 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?

Schema coverage is 100%, providing baseline 3. The description adds operational meaning for idempotencyKey (no second charge, resolves to same run) and response_format (compact omits prose to save context tokens), which goes beyond the schema's own descriptions.

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

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

The description opens with a specific verb ('Ask...') and target ('Delta Analyst'), then details the operation: 'Runs an agentic multi-step analysis over the signal corpus and returns a structured brief'. It also distinguishes itself from the sibling get_analyst_job by explicitly naming that tool for fetching results.

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 operational context: async enqueue, polling cadence ('poll every ~10–20s'), and two explicit retrieval alternatives ('calling get_analyst_job with the job_id' or 'ask_analyst again with the SAME idempotencyKey'). It does not enumerate exclusions for when not to use this tool versus other analysis siblings, 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?

The annotations indicate idempotent and destructive (side-effect) behavior. The description adds crucial context: token costs (5/15), charging to key owner's balance, caching of prior assessments, and rejection of not-observable signals before any charge. It also details the result's context block, fulfilling transparency beyond structured data.

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 but every sentence carries information: purpose, result contents, cost, caching, and pre-filtering instruction. It is somewhat long but appropriate for the tool's complexity; 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 the rich output schema (context block, meta.tokens) and the description's coverage of inputs, outputs, cost, caching, and rejection behavior, the tool is fully specified for an agent to select and invoke it correctly. It even tells the agent the follow-up action (pass imagery_handoff to search_imagery), making it self-contained.

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 already documents both parameters with 100% coverage, so baseline is 3. The description adds cost semantics for kind (quick=5, deep=15 tokens) and clarifies eventId as coming from query_signals, though the latter repeats schema. This extra context raises it to 4.

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: 'Run an AI RS deep-dive assessment for a specific signal: what to observe, recommended sensors, and a collection window.' It clearly distinguishes from siblings like query_signals (listing signals) and search_imagery (finding imagery) by emphasizing the analysis and actionable plan output.

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: signals not satellite-observable are rejected before charge, so it instructs to pre-filter with query_signals observability:'observable'. It also states the result carries an imagery_handoff to pass to search_imagery, giving the agent a clear workflow. While it doesn't list alternative assessment tools, it gives a when-not-to-use condition, meeting the bar.

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?

Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds cost behavior ('Creating is free; each automatic check costs...') and the automatic monitoring behavior ('every new acquisition... measured automatically'). It does not contradict 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?

The description is two sentences, front-loaded with the main function, and includes decision guidance and cost context without redundancy. Every clause adds value.

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

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

Given the 4-parameter schema with 100% description coverage, plus an output schema, the description provides sufficient context: it explains the persistent monitoring behavior, cost model, and when to use it. There is no missing critical information.

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 description coverage is 100%, with detailed descriptions for bbox, name, metric, and start_date, including cost implications. The description only adds a high-level mapping ('pick an area and what to count') without new 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 uses the specific verb 'Put a place under continuous satellite measurement' and clarifies the resource (area + metric). It distinguishes from create_standing_order by explicitly contrasting quantities at a fixed place over time versus events. This clearly communicates the tool's core function.

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 when-to-use guidance: 'Use this when the question is about a quantity at a fixed place over time' and names the alternative 'create_standing_order' for events. This gives an agent clear decision criteria.

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

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

The description discloses significant behavioral traits beyond annotations: it costs nothing to create, each firing runs ask_analyst and is metered, a deterministic pre-pass avoids charging for quiet periods, and it returns projected_monthly_tokens_max for cost visibility. It also notes plan limits on cadence and order count, and that errors indicate which limit was hit.

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 yet information-dense, structured to front-load the core function, then explain the cost model, then usage guidance. Every sentence earns its place, with no fluff or repetition of schema 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's complexity (8 parameters) and the presence of an output schema, the description covers all necessary aspects: function, cost, triggering logic, return value, plan limits, and usage guidance. It provides enough context for an agent to select and invoke the tool correctly without further clarification.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value by explaining cost implications directly tied to parameters: cadence affects check frequency and plan requirements, and min_new_events / min_geoint_score control when a check fires and thus influences cost. This goes beyond the schema's field-level 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: putting an area under continuous watch via a question and bounding box, scheduled re-answering, and change-based notifications. It distinguishes itself from sibling tools like list_standing_orders and delete_standing_order by focusing on creation and from immediate-query tools like ask_analyst.

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?

Explicit usage guidance is provided: 'Use it when the question is "tell me when this changes" rather than "what is happening right now".' It also explains the cost model, noting that creation is free and metering occurs only when the order fires, which helps users decide when this tool is appropriate.

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?

Beyond the annotations (destructiveHint=true), the description adds crucial behavioral details: pausing preserves the order and history, deleting removes both, neither operation costs tokens, and a paused order still counts against the plan limit. This explains side effects and resource constraints not present in the 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?

The description is three sentences that front-load the primary action, then efficiently explains the alternative and its consequences. Every sentence adds distinct 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 presence of an output schema, the description needn't explain return values. It covers delete and pause/resume semantics, state effects, cost, and plan limit implications, making it complete for the tool's 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?

The input schema already describes the active parameter's behavior (omit to delete, false to pause, true to resume) with 100% coverage. The description adds extra nuance about plan limit usage and the fact that pausing keeps history, which is not in the schema. This supplements the schema 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 begins with a specific verb ('Delete') and resource ('standing order'), clearly stating the primary action and also mentioning the alternative pause/resume behavior. It distinguishes from sibling tools like create_standing_order and list_standing_orders by focusing on the delete/pause operation.

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 delete vs pause: 'delete rather than pause when you want the slot back.' It also provides the context that pausing keeps the order/history and that neither operation costs tokens, giving clear decision 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?

Annotations declare readOnlyHint=true, and the description aligns with that, adding rich behavioral detail: exact statuses, processing intervals, separation of result_quality from job status, token charging behavior, and owner-only visibility. These go well beyond structured 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?

Five dense sentences cover statuses, polling, quality caveat, and access constraints with no filler. Information is front-loaded with the core action first.

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 polling endpoint with output schema, the description covers all needed operational context: status meanings, polling behavior, quality distinction, and access control. The response_format parameter is already documented in the schema, so no gap.

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

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

Schema description coverage is 100%, with both job_id and response_format documented. The description adds little beyond the schema (e.g., that job_id comes from ask_analyst), so parameter semantics are adequately handled by 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 names a specific verb ('Fetch') and a clear resource ('status and result of an ask_analyst run by job_id'), which distinguishes it from sibling tools like ask_analyst that create runs. It fully clarifies 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.

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

Clear context is given for polling ('poll again in ~10-20s') and it implicitly identifies this as the retrieval counterpart to ask_analyst. It doesn't explicitly name alternative tools, but the wording and sibling set make the usage context obvious, though no explicit when-not-to-use list is 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavior beyond that: discloses that anomaly flags come from a median-absolute-deviation test, that the result includes full measurement history with per-acquisition values and flags, and that the tool is "free of token charges." No contradiction with 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?

Four sentences, each earning its place: purpose, usage, anomaly algorithm, cost. Front-loaded with the core action, no fluff or redundancy. Ideal length for a simple read tool.

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

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

Given the tool's simplicity (one required param, no nested objects, output schema present), the description fully equips an agent: what is returned, how to use it, what's behind anomaly flags, and cost implications. Complete for its scope.

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

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

Schema coverage is 100% and the parameter description already explains area_id's provenance and polygon_id alias. The main description does not add new parameter-level semantics; it merely reinforces the source of area_id. Baseline 3 is appropriate because the schema carries the load.

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: "Fetch one monitored area with its full measurement history," immediately distinguishing it from the sibling list_monitored_areas, which reports only a summary number. The added context that this is "the time series behind the number" further clarifies its unique role.

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 states intended use cases: "use it to answer 'is it going up', 'when did it change', or 'how unusual is today'." This gives clear guidance on when to choose this tool over list_monitored_areas and other analytical 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds valuable context: 'Free of token charges' and details on what it returns. It clarifies the tool's non-consuming nature, going beyond the structured 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?

Two sentences, front-loaded with purpose, followed by a clear use case and a key behavioral note. No redundant information or filler, making it highly 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 simplicity (0 params), the presence of an output schema, and complete annotations, the description covers all necessary aspects: what it does, what it returns, when to use it, and a distinguishing behavioral trait. Nothing 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 tool has no parameters, and the description correctly doesn't introduce any. Schema coverage is trivially 100%, given the empty schema. The description adds implicit meaning by indicating the 'calling key' is used automatically, aligning with the baseline for zero-parameter 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 opens with a specific verb+resource: 'Check the calling key's remaining token balance and plan capabilities.' It enumerates concrete outputs (monthly allocation, tokens used, tokens remaining, plan capabilities) and distinguishes itself from sibling tools, none of which cover balance/plan status.

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: 'Use this to pre-flight a metered call: decide whether enough balance is left before spending.' It doesn't mention alternatives or when-not, but as a unique utility among siblings, this 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?

The description goes beyond the annotations by disclosing that the result includes a freshness object (brief_date, age_hours, is_stale) and explaining how to handle stale data. It also notes the tool is free of token charges, adding behavioral context that is not present in the 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?

The description is informative and every element serves a purpose, but the first sentence is quite long and contains a nested list, slightly reducing readability. Overall it's concise and front-loaded with the main purpose.

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

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

With a single optional parameter, annotations, and an output schema, the description adds essential context about the brief's content, freshness object, and how to interpret staleness. It is complete for effective 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?

The schema fully documents the single optional 'date' parameter with format and default behavior (defaults to latest available). The tool description does not add additional parameter semantics beyond this, and with 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states that the tool fetches the Daily World Brief, an AI-synthesized OSINT/GEOINT digest of the previous UTC day's events. It specifies the exact content structure (headline, executive summary, top developments, etc.), which distinguishes it from sibling tools like query_signals that provide raw data.

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 makes the tool's purpose clear—fetching a daily brief—so the context for when to use it is evident. However, it does not explicitly mention alternatives such as query_signals for raw signal data or state any exclusions, 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?

The description adds valuable behavioral details beyond the readOnlyHint and destructiveHint annotations: it explains that coverage window_total null means catalog total UNKNOWN, never zero, and explicitly states the operation is free of token charges. This significantly enhances 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 yet packed with necessary details. It front-loads the primary action, lists the returned fields in a readable flow, and adds a crucial null-semantics clarification. Every sentence earns its place with 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 is fully sufficient for a read-only list tool with an output schema. It covers the returned fields, plan limits, and a key data interpretation caveat, leaving no ambiguity about what the tool returns or how to interpret it.

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

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

The tool has no parameters, so the empty schema provides 100% coverage. The description does not need to explain parameters, and per the calibration baseline, 0 params merits a 4.

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 the specific verb 'list' with a clear resource ('places under continuous satellite measurement on this key (Delta Monitor)'), distinguishing it from sibling tools like get_monitored_area (which fetches a single area) and create_monitored_area. The scope and returned data are explicitly stated.

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 conveys it returns all monitored areas with metrics, and the naming convention (list_*) implies its role. However, it does not explicitly contrast with get_monitored_area for single-area queries or provide when-not-to-use guidance, so it misses the top bar.

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 annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable context beyond that: it discloses that the tool is free of token charges and explains the meaning of 'quiet_checks'. This is good but does not cover potential rate limits or ordering details, which keeps it at a 4 rather than 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.

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

The description is two sentences long, front-loaded with the primary action, and every clause adds value. It neither wastes words nor omits essential details, making it an exemplary model of concise, structured documentation.

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 that the tool has no parameters, has an output schema, and is simple read-only listing, the description fully covers what it does, what fields are returned, how to interpret a key metric, and the cost behavior. There are no significant gaps, so a 5 is justified.

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

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

The tool has zero parameters, and the schema is empty (100% coverage by default). Per the rubric, a baseline of 4 is appropriate since the description does not need to compensate for undocumented parameters; it also explains the output fields, which is sufficient.

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 as listing standing orders on a key, with a specific verb ('List') and resource ('standing orders'). It lists the exact fields returned, distinguishing it from sibling tools like 'list_monitored_areas' and 'create_standing_order'.

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 on what information is returned and even interprets the 'quiet_checks' field, helping an agent understand when this tool is useful for assessing standing-order effectiveness. However, it does not explicitly mention exclusions or alternatives, such as when to use 'list_monitored_areas' instead, so it falls 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?

Even with destructiveHint=true, the description discloses the full behavior: the deterministic plan checks both Sentinel-1 and Sentinel-2 exactly once each, issues two catalog searches, costs 4 tokens, and returns per-search coverage/cloud/SAR-pair status. It also describes refusal behavior, screening/detection/identification capabilities, and explicitly states that a VHR recommendation does not invalidate free-catalog results—far exceeding the 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?

The description is relatively long but every sentence contributes substantive content: purpose, sensor behavior, output contents, capability context, usage guidance, precondition, and token cost. It is front-loaded with a clear summary, but the density of parenthetical details makes it slightly heavier than the most concise examples.

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

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

The description is remarkably complete: it enumerates what the result carries, explains screening/detection/identification limitations, gives usage preference over search_imagery, states the refusal condition, and mentions token cost and the two-search behavior. For a tool with 3 parameters and an output schema, this fully prepares 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 coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining that analysis_goal (damage_assessment | flood_mapping | wildfire_assessment) drives the plan and cloud gating, and that event_id resolves to the event's authoritative footprint. It does not explicitly detail the optional event_date beyond implying a pre/post window, but the schema already covers that field.

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 states a specific verb ('Plan') and a clear resource ('imagery evidence for ONE event'), and explicitly distinguishes it from the sibling search_imagery tool ('instead of guessing collections one at a time'). It further specifies the exact sensors and analysis goals, making its 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?

It explicitly says 'Prefer this over several search_imagery calls for the same event' and explains why (cannot miss the SAR look and cannot repeat a search). It also defines required inputs (event_id, analysis_goal) and a precondition (an event must have a resolvable footprint, otherwise refused), providing clear when-to-use guidance.

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

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

The description richly discloses behavior (SGP4 propagation, token cost, retrieval_ok:false semantics, geometry_only:true, never confirmed acquisitions), but the annotations contain destructiveHint:true, implying the tool destroys or modifies something. The description describes a purely predictive/read-only operation, directly contradicting the annotation. Per rubric, this contradiction forces a score of 1.

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 intentionally so, front-loaded with the core question. Every sentence adds operational value (method, uncertainty, error behavior, defaults). It could be tightened but is not bloated for the tool's 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 tool's complexity, the description is exceptionally complete: it defines output semantics (pass attributes), failure modes (retrieval_ok:false), limitations (geometry only, never confirmed), horizon cap, defaults, and cost. The presence of an output schema further reduces the burden of explaining return values.

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

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

Schema descriptions cover all 7 parameters (100% coverage), so baseline is 3. The description adds extra meaning: bbox's centre is used, satellites parameter groups free/systematic vs commercial/agile, and default behaviors for start_date and max_passes. This goes beyond the raw 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 predicts satellite passes, opening with "WHEN can this place next be imaged, and by WHAT — the timing half of collection planning." It names the resource (satellite pass access windows) and distinguishes itself from siblings by focusing on future collection opportunities rather than existing imagery or analysis.

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 tells when to use it: to answer "when is the next chance to see this", to choose between free systematic passes and paid agile tasking, and to time change-detection pairs. It also gives practical constraints (7-day horizon, retrieval failure meaning). However, it doesn't explicitly say when not to use it or name alternative sibling tools like search_imagery for past imagery.

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?

Beyond the readOnlyHint and non-destructive annotations, the description discloses important behavioral traits: the time-axis/evidence-movement semantics, the fact that claims track restatements and downgrades, scoping to the caller's own key, and that it is 'Free of token charges.' This adds significant context beyond the 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?

The description is long but every sentence contributes value, explaining the ledger concept, evidence classes, restatement chains, use cases, and scope. It is front-loaded with the main purpose. The length is justified by the tool's conceptual complexity, though it could be tightened.

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 lacking an output schema in the provided definition, the description thoroughly covers what the tool returns (evidence class, source family count, publishers) and its unique value proposition (time-axis tracking, downgrade detection). It leaves no major ambiguity about the tool's behavior and purpose.

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 descriptions cover 100% of parameters, so baseline is 3. The description adds extra meaning for restated_only and downgraded_only by explaining their purpose in identifying chains and weakened assertions, and it clarifies evidence classes with examples. This goes beyond the schema's straightforward 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 verb 'Read' plus the resource 'LEDGER of claims' clearly states the tool's function. It specifies the content (factual assertions, evidence class, source families, publishers) and explicitly distinguishes itself from sibling tools by focusing on the claims ledger and its time-based evidence chains.

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

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

Provides explicit use cases: 'Use it to audit what you were told before acting on it, or to check whether an assertion has since weakened.' It also notes scope restrictions (only your own key) and the meaning of restated_only and downgraded_only. However, it does not explicitly contrast with alternatives like query_signals or query_stats.

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 annotations indicate destructiveHint: true, but the description describes a read-only query operation that returns grid-binned data and metadata. This is a direct contradiction. According to the rubric, a score of 1 is required when the description contradicts annotations. The description does disclose token cost and the unit of cell counts, but the safety profile mismatch is a serious inconsistency that undermines trust.

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

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

The description is concise and well-structured: it starts with the core purpose, includes a usage phrase, provides a clarifying note about the unit and accountability of counts, and mentions the token cost. Every sentence earns its place, and the note is valuable for interpreting results correctly.

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 is quite complete for a query tool with an output schema: it explains what the tool returns (peak severity, categories, event_ids), clarifies the unit of cells, and discloses cost. However, the complete absence of any mention of the tool's safety profile (aside from the misleading destructiveHint) is a gap that could confuse an agent. The description supplies most necessary context, but the contradiction with annotations prevents a perfect score.

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

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

Schema description coverage is 100%, so the baseline is 3. The schema already provides thorough descriptions for all parameters, including the nuanced 'limit' parameter. The tool description adds context about what the cells count (satellite-observable points) but does not add parameter-specific meanings beyond the schema. Hence, it stays at the baseline.

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 verb and resource: 'Geographic hotspots — signal density grid-binned into cells, ranked by event count, each with peak severity, the categories present, and up to 5 representative event_ids'. It also provides a usage orientation ('Use to find WHERE activity is concentrating'), which differentiates it from sibling tools like query_signals (which likely returns raw signals) and query_stats (aggregate statistics).

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 gives a clear use case: 'Use to find WHERE activity is concentrating.' It does not explicitly name alternatives or exclusions, but the context signals list sibling tools, and the purpose is clear enough for an agent to choose this tool for spatial density analysis. The guidance is clear but lacks explicit 'when-not-to-use' or alternative names.

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

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

The description describes a read-only query operation, yet annotations declare destructiveHint=true and readOnlyHint=false. This contradicts the description, which also does not disclose any state-changing or destructive behavior beyond a token cost. The annotation contradiction is severe and unaddressed.

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

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

The description is two sentences, front-loaded with the core purpose. The first sentence is dense with the Delta Signals definition but remains informative. The second sentence concisely states filter options and cost. No redundant or filler content.

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

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

Given the tool's 19 parameters and an output schema, the description provides a high-level overview and notes cost. It does not explain pagination, use-case prioritization, or return-value structure, but those are covered by the schema and output schema. The annotation contradiction leaves a critical gap, but for the description alone, it is minimally 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?

Schema description coverage is 100%, with every parameter richly described in the schema itself. The top-level description only references three filter types (bbox, date, category) that are already documented in the schema. Thus the description adds no semantic value beyond the schema, warranting the baseline score.

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 'Query geolocated world event signals' — a specific verb+resource that clearly distinguishes from siblings like query_stats and get_world_brief. The parenthetical defining Delta Signals adds context without ambiguity. The filter mention further clarifies the tool's domain.

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 states 'Filter by bounding box, date window, and category,' offering clear context on how to use the tool. However, it doesn't explicitly state when to use this tool over alternatives or when not to use it. No exclusions or explicit comparative guidance 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?

The annotation destructiveHint=true contradicts the description's implication of a read-only aggregation tool. The description discloses important behavioral traits (cost, unit semantics, non-cluster-collapsed counts), but the contradiction with annotations forces a score of 1 per the rubric.

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, all valuable: purpose, cost/comparison, and unit nuance. No fluff or repetition; information is front-loaded with the primary function.

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

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

The description covers the tool's purpose, alternative, cost, and output semantics. An output schema exists, so the return field details are not required. The only gap is the unresolved contradiction with destructiveHint, which slightly reduces completeness.

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

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

Schema description coverage is 100% (all 4 parameters have descriptions), so the baseline is 3. The tool description adds general context about bbox/date windows but does not provide additional parameter-level 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's function: 'Aggregate statistics over the signal corpus' with specific outputs (total event count, per-category, per-day breakdown). It explicitly distinguishes itself from the sibling tool query_signals by saying it returns roll-ups rather than rows.

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 guidance on when to use this tool versus the alternative: 'Cheaper than query_signals (returns roll-ups, not rows)' clearly indicates it is for aggregate needs rather than detailed row-level queries.

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 annotation destructiveHint=true directly contradicts the description's claim that the tool is 'Deterministic — no LLM, no per-event cost' and only returns ranking data. The description gives no indication of any destructive side effect, and its entire framing suggests a read-only query. This is a critical inconsistency that could lead an agent to misuse the 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 relatively long (5 sentences) but each sentence carries useful information: purpose, method, output, use case, and cost. It is front-loaded with the key question and efficient in its wording. A small deduction for density — the resolution-class explanation could be slightly tighter.

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 tool with a rich output schema and fully documented input parameters, the description covers the essential context: what it returns, how to think about the output, determinism, and cost. It lacks nothing critical, though the annotation contradiction undermines trust. The tool's complexity is well-served by the description.

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

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds minimal parameter-specific nuance — it only mentions resolution classes indirectly, but doesn't explain how bbox, top_n, or min_geoint_score interact with the ranking logic. Thus it neither adds nor subtracts much 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 opens with a clear, specific question ('WHERE — and with what class of satellite — is observation most worthwhile right now?') and explains exactly what the tool does: ranks events by importance and resolution class. It clearly distinguishes from sibling tools like search_imagery and plan_event_imagery by framing itself as a triage step before imagery spending.

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

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

The description explicitly states the intended use case ('Use it to triage a theatre before spending on imagery') and explains the practical difference between resolution classes (hr = free Sentinel data, vhr = paid order). It doesn't name alternative tools or list exclusions, but the context is clear enough for an agent to decide when to invoke 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?

The annotations include destructiveHint: true, but the description clearly indicates a read-only search operation returning metadata with no imagery bytes. This directly contradicts the destructive hint. While the description is rich in behavioral detail, the contradiction mandates a score of 1 per the scoring rules.

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?

Though lengthy, every sentence delivers critical operational detail: catalog scope, output type, parameter effects, edge-case clarifications, and cost. The structure front-loads the core purpose and methodically explains optional parameters, avoiding redundancy with the input schema.

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 (11 parameters, multiple collections, nuanced target_relation logic), the description is exceptionally complete. It covers what is returned, how to interpret derived fields, when to use eventDate/eventPoint/eventAoi, and even cost. The presence of an output schema reduces the need to explain returns, but the description adds value by explaining semantics, not just listing fields.

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

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

The description adds rich semantics beyond the schema, especially for eventDate (timing classification, pre/post bracketing, SAR pair status) and eventPoint/eventAoi (target_relation with geometry gate vs. usability gate). It clarifies edge cases like same-day scenes without eventTimestamp and cloud-cover thresholds, far exceeding baseline for high 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 the tool 'Search the satellite imagery catalog' with specific collections (Sentinel-1/2, OPERA RTC-S1) and scope (area and date window). It also positions it relative to siblings by calling it 'the natural follow-up to a signal (find imagery over the event location)', making it distinct from related tools like plan_event_imagery or query_signals.

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

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

Explicitly provides a use case: 'natural follow-up to a signal (find imagery over the event location)'. It also indicates what the tool does NOT do ('no imagery bytes'), implicitly guiding agents to choose another tool if they need actual imagery. This clear context and implicit alternatives qualify as strong usage 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?

The annotations specify destructiveHint=true and readOnlyHint=false, implying the tool may have destructive or non-read-only side effects. The description, however, portrays a purely analytical, deterministic survey that 'returns' counts and events, with no mention of any mutation or destructive action. This directly contradicts the annotations, making the description misleading regarding safe invocation.

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 average but well-structured: it opens with a clear question, explains core behavior, then offers usage guidance and population caveats. Each sentence provides meaningful context (e.g., sensor differences, relation to sibling tools, determinism, cost). While slightly dense, it avoids fluff and earns its length.

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?

Although the description covers purpose, usage, and return contents thoroughly, it omits any mention of destructive side effects or non-read-only behavior that the annotations indicate. Given that an output schema exists and parameters are fully documented, the description should have addressed the tool's actual side-effect profile. This critical omission makes the description incomplete and potentially unsafe.

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 covers all 7 parameters with descriptions (100% coverage), so the baseline is 3. The description adds a couple of contextual notes (e.g., sensor resolution details, 30-day window cap), but these are already present in the schema's parameter descriptions. No significant extra meaning is provided beyond the schema, so a 3 is appropriate.

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

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

The description opens with a specific question and clearly defines the tool's function: to evaluate which events in a window a given in-app sensor can resolve, return counts, breakdown by required resolution, and top events with rationale. It explicitly distinguishes itself from siblings like rank_imaging_priority and query_signals by contrasting population and units, making its purpose unique and concrete.

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 gives explicit guidance: 'Prefer this over asking about events one at a time' and explains it is exhaustive, cheap, and the honest way to assess observability before committing collection effort. It also differentiates from rank_imaging_priority and query_signals, and instructs to read collection_ready per event for taskability, providing clear when/when-not usage.

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