emem — Earth memory protocol

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description does not need to repeat safety aspects. The description adds value by explaining the composition (locate → recall → aggregate) and the data source/resolution. No contradictions 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?

The description is extremely concise: three sentences covering purpose, usage, and a pairing suggestion. No redundant information, and the most critical information is front-loaded.

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

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

Given the tool's complexity (8 parameters, no output schema), the description provides a clear purpose, usage context, and data source. It lacks details on the return format or what 'aggregate' means, but the annotations and schema cover safety and parameter details. The description is sufficiently complete for an agent to understand when and how to use the tool.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds context by naming the default band set (PM2.5, NO2, O3), which is not in the schema, helping the agent understand what the tool retrieves by default.

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

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

The description clearly states the tool recalls CAMS air-quality bands (PM2.5, NO2, O3) at a place, using a compose of locate, recall, and aggregate. The title reinforces the specific pollutants. This distinguishes it from sibling tools like emem_at or emem_weather.

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 'When to use' section explicitly advises using this tool when a user asks about air quality, pollution, or emissions exposure. It also provides context about CAMS data and suggests pairing with finer-grained stations data for urban PM2.5, offering an alternative. However, it does not explicitly state when not to use it or list specific sibling alternatives.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) are present and the description adds rich behavioral context: entries contain kind, bands, formula, output, citation; the agent applies formulas in-process and quotes keys for replayability. 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?

The description is somewhat lengthy but front-loaded with the core purpose and usage guidelines. Every sentence adds value, though a slightly more streamlined structure could improve conciseness.

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

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

For a tool with no parameters and no output schema, the description covers all necessary context: what the tool contains, how entries are structured, when to use, and how to apply the results. It leaves no gaps for an AI agent.

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

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

The input schema has zero parameters, so baseline is 4. The description does not need to add parameter info, but it explains what the tool returns (a dictionary of recipes), fulfilling the need for a parameterless tool.

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

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

The description clearly states the tool is a 'content-addressed dictionary of composition recipes' that fuses band facts into derived scores, classifications, and similarity metrics. It distinguishes itself from sibling tools that likely handle single band readouts or data retrieval, making the purpose highly specific.

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

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

Explicitly tells when to use: for composite questions like 'flood risk' versus single band readouts. It also points to an alternative tool ('emem_find_similar' is faster for k-NN patterns), providing clear guidance on tool selection.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: the server-side chain, auto-materialization of bands on miss, signed receipts with fact_cids at root, default slim response, the effect of verbose and include_image on latency and size, and the envelope structure. No contradictions with annotations. Misses details on error handling or rate limits, but overall strong.

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

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

The description is comprehensive but verbose, with several long paragraphs. The first sentence is a good summary, but the detailed breakdown of the process, response structure, and parameter nuances could be more concise. For a tool of this complexity, the length is partly justified, but it could be structured more efficiently with bullets or shorter sentences.

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

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

Despite no output schema, the description thoroughly explains the return envelope: topic_routing, facts, algorithms_for_question, optional scene URL, caveats, receipt, fact_cids. It covers default slim response vs verbose, behavior for out-of-scope questions, and the location resolution process. Given the tool's complexity (8 parameters, server-side chain), this is complete.

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

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

Schema coverage is 100% with descriptions. The description enriches parameters by explaining that cell64 comes from prior emem_locate/emem_recall, place is geocoded via Nominatim, include array enum options are listed, verbose default respects MCP cap, and include_image adds latency. This adds meaningful context 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 title 'Ask a free-text question about a place' and the first sentence clearly state the tool's function: single-shot free-text answer backed by signed receipts. It distinguishes itself from siblings by emphasizing a packaged, citation-bearing answer versus manual primitive composition, and by mentioning the server-side locate→recall→algorithm chain, which is unique among the many sibling tools.

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

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

Explicit 'When to use' section states the tool is for specific real-world places when a packaged answer is preferred over manual composition. It provides guidance on parameter selection (q verbatim, place/cell/lat+lng) and explains how to handle out-of-scope questions (topic_routing.matched_topic: null with full inventory to route elsewhere). This clearly delineates when to use this tool versus alternatives.

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

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

Beyond annotations, the description discloses polygon centroid behavior, cost implications of n_cells, and the MCP size cap affecting default response. No contradictions 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?

The description is concise with two focused paragraphs. The first paragraph defines core functionality, the second provides usage guidance, with no unnecessary words.

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

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

Given no output schema, the description effectively covers return intent (standard situational readout) and response size limits. It could be more explicit about coordinate format, but overall adequately complete.

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

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

While schema covers parameter descriptions, the description adds context on default band sets, polygon fan-out mechanics, and how the 'include' parameter affects response size, providing extra meaning.

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

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

The description clearly states the tool performs a 'one-shot multi-band recall at a place' with a default band set. It differentiates from siblings by noting single-band shortcuts and emem_recall for direct use.

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 specifies when to use: 'when the user names a place and wants the standard situational readout without picking bands.' It also provides when-not-to-use by directing to single-band tools or emem_recall for specific cases.

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, idempotentHint, and non-destructive. The description adds performance context ('slow but possible', 'one upstream fetch per tslot, capped by max_facts') and explains post-condition (emem_trajectory returns full series after completion). It also notes limitations for certain bands ('present_only' status). 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?

The description is well-structured, starting with core action, then return type, performance caveat, and usage guidance. It is concise but includes necessary context, though slightly longer than minimal.

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 100% schema coverage, no output schema, and moderate complexity, the description covers purpose, usage, behavior, limitations, and cross-references other tools. It adequately prepares an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline 3 is appropriate. The description does not add much beyond the schema's parameter descriptions (e.g., band must support historical fetch, cell auto-resolves). The narrative integrates parameters but adds no new semantic details.

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 verb ('materialize and sign') and the resource ('per-tslot fact for one (cell, band) in a window'), distinguishing it from siblings like emem_trajectory (which returns only the latest point) and emem_attest (prefer this over staking an attestation). The return type is also specified.

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 'When to use' section guides the agent to call this tool when history is needed and emem_trajectory returned only the latest point. It also advises against staking attestations when the upstream is publicly fetchable, and directs to check emem_coverage_matrix for band history availability.

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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds that the ontology is 'Active' and includes specific fields (offsets, dims, tempo, privacy), giving context about the data returned. 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?

Two sentences, no wasted words. The first sentence states what the tool returns, the second gives clear usage guidance. Well-structured and front-loaded.

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

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

For a tool with no parameters and no output schema, the description explains the content (offsets, dims, tempo, privacy) and usage. It doesn't describe the output format explicitly, but but the domain (ontology) implies a structured list. Adequate.

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

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

The tool has zero parameters, so schema_description_coverage is 100%. The description does not need to explain parameters. Baseline 4 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 states 'Active band ontology' which implies a listing, and elaborates with 'offsets, dims, tempo, privacy'. While not using a verb like 'list' or 'get', the purpose is clear in context. The 'When to use' section further clarifies its role as a registry. It distinguishes from siblings like emem_compare_bands by establishing this as the source of band names.

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 'Call once at session start to learn the band registry' and mandates that 'every other primitive's `band` argument MUST come from this list.' This provides perfect guidance on when and why to use this tool, including a crucial dependency rule for other tools.

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

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

Annotations declare readOnly, idempotent, not destructive. Description adds context (returns items and grader URL, hand-verified, submission endpoint). Could mention potential errors or limits, but adequate.

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

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

Two concise paragraphs with front-loaded purpose and clear structure. Every sentence adds value, no redundancy.

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

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

Tool has zero parameters, no output schema, but annotations cover safety. Description fully explains what it returns, how to use it, and follow-up step. Complete for a simple fetch tool.

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

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

No parameters; schema coverage 100%. Baseline is 4. Description doesn't need to add parameter info, but clarifies return format and usage, adding value.

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

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

Description clearly states the tool returns hand-verified evaluation items for grading an agent, with examples of items (elevation recall, NDVI, find_similar neighbours). This is specific and distinguishes from siblings.

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 (onboarding or CI), how to use (fetch once, answer items, POST to /v1/benchmark/grade), and purpose (regression check). No ambiguity.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint false) are consistent. Description adds behavioral details: it computes and maps, can use stored trajectory, warns about fallback limitations, and mentions output fields (dnbr, severity_class). No contradictions.

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

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

Concise two-paragraph structure: first paragraph defines the computation, second provides usage guidance and alternatives. Every sentence adds value with no redundancy.

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

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

Covers algorithm, input options, best practices, output hints, and sibling differentiation. No output schema, but description sufficiently indicates what is surfaced. Complete for agent decision-making.

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

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

Schema coverage is 100%, but description adds context: explains the fallback behavior when parameters are omitted and advises to pin scenes around fire date for correct results. This adds value beyond 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 it computes dNBR and maps to USGS burn-severity classes, naming the algorithm (Key & Benson 2006) and output classes. It distinguishes from sibling emem_hunt for active-fire detection.

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 'When to use' section provides context and best practices, including explicit parameter passing vs. stored-trajectory fallback, and directs to emem_hunt for active-fire detection.

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, idempotentHint, destructiveHint. The description adds valuable behavioral context: refresh every 30 seconds, constant-time reads, and behavior when the sidecar is unreachable (empty extensions). 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?

Two paragraphs with clear front-loading: first sentence states the tool's purpose and output fields. Second paragraph provides usage guidance. Every sentence adds value, no redundancy.

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

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

Given no input parameters and no output schema, the description covers refresh interval, constant-time reads, when to use, pairing with siblings, and failure mode. An agent has all necessary information to invoke correctly.

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

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

Input schema has zero parameters, so baseline is 4. Although the description lists output fields (extensions[], cuda_available, etc.), this is not required for parameter semantics but adds context. No input parameters need explanation.

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

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

The description clearly states it provides a 'live capability snapshot' of the GPU sidecar, listing specific fields (extensions[], cuda_available, etc.). It distinguishes itself from sibling tools like emem_topics and emem_explain_algorithm by explaining how they complement each other.

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 'When to use: Call before scheduling a GPU-heavy plan...' and provides guidance on pairing with emem_topics and emem_explain_algorithm. Also describes what to do when extensions[] is empty, covering both usage and alternatives.

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

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

Annotations already declare readOnlyHint=true and isIdempotent=true, indicating a safe read operation. The description adds context about the output being a GeoJSON Feature with specific properties, complementing the annotations without contradiction.

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

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

The description is concise at three sentences, front-loaded with key information, and includes a separate usage section. It is well-organized but could be slightly more compact.

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 parameter, no output schema), the description fully explains the output format and properties, and even provides an alternative approach. It is complete for an agent to understand and use the tool correctly.

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

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

The sole parameter 'cell' is described in the schema as 'cell64 or place name', and the description only repeats that information. With 100% schema coverage, the description adds minimal additional semantic value beyond restating 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 that the tool returns a cell polygon as GeoJSON, specifying mimeType, properties, and usage for mapping libraries. However, it does not explicitly differentiate from sibling tools, though the unique function is evident.

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

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

The description includes a dedicated 'When to use' section that specifies scenarios like map overlays and polygon-clipping ops, and also provides an explicit alternative (REST endpoint for FeatureCollection) for different needs.

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

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

Discloses internal pipeline (STAC search, HTTP-Range COG reads, percentile stretch, PNG encode) and output details (structuredContent fields include STAC item id, capture time, cloud_cover). Annotations already indicate readOnly, idempotent, open world; description adds substantial behavioral context without contradiction.

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

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

Well-structured with pipeline summary, usage guidance, and parameter details. Slightly verbose but every sentence adds value. Could be tightened but still effective.

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?

Completely covers the tool's purpose, output format (ImageContent block with structuredContent), parameter nuances, and usage scenarios. No output schema exists, but description adequately explains return values.

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

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

Adds significant meaning beyond schema: cell can be place name auto-resolved, max_cloud default 20% with advice to raise in tropics, datetime defaults to last 90 days. Schema already has 100% coverage, but description enriches usability with practical guidance.

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

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

Clearly states verb 'returns' and resource 'Sentinel-2 true-colour RGB thumbnail centred on a cell'. Includes specific technique (2-98 percentile stretch) and output format (PNG ImageContent block). Differentiates from sibling tools by focusing on visual true-colour thumbnails.

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 'When to use' section with concrete examples ('show me what this looks like', 'before/after the flood'). Provides advice on raising max_cloud for tropics. Lacks explicit when-not-to-use guidance but gives clear situational context.

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, idempotentHint=true, destructiveHint=false. The description adds that the tool returns a cosine score and per-band deltas, which is beyond the annotations and useful. No contradictions.

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

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

Two sentences plus a usage note. No redundant information; every sentence serves a purpose.

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

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

No output schema exists, but the description explains the return format (cosine score + per-band deltas). For a comparison tool, this is sufficient. Could mention normalization but not necessary.

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% with descriptions for all parameters. The description does not add further semantic detail beyond the schema, but 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 specifies the verb ('compare'), resource ('two cells'), and methodology ('cosine similarity over shared vector bands + per-band scalar deltas'). It differentiates from siblings like emem_compare_bands and emem_diff.

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 trigger phrases are provided ('how similar is X to Y', 'compare these two places', 'difference vector'). However, it lacks guidance on when not to use this tool or mention alternatives, but the context 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?

Annotations declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds significant behavioral details: comparison logic, receipt structure, tslot resolution, and bands_with_no_history. 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?

Well-structured with front-loaded purpose, clear sections, and no redundant information. Every sentence contributes to understanding tool behavior and usage.

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

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

Given no output schema, the description covers return values (signed receipt, tslot_resolution, bands_with_no_history) and explains parameter behavior thoroughly. Addresses the tool's complexity adequately.

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

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

Schema coverage is 100%, but description enhances understanding with auto-pick semantics for tslot parameters, explanation of predicate's verdict, and mention of response fields. Adds value beyond 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 'Compare two bands at the same cell' with specific details on scalar vs vector comparisons and a precise output (signed receipt). It distinguishes itself from sibling tools by focusing on single-cell band comparison.

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 'When to use' section lists three concrete scenarios: cross-source consistency, cross-vintage drift, and any band-vs-band comparison within a single cell. It also explains when to omit tslot parameters, providing clear 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 explains the tool is a one-shot poll, signed for verification, and matches the streaming tick payload. Annotations already indicate read-only, idempotent, non-destructive; description adds useful context without contradiction.

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

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

Two concise paragraphs with clear organization. Title line summarizes content immediately, followed by usage guidance. No wasted words.

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

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

For a parameterless tool with no output schema, the description fully explains what is returned, the purpose, and how to use it. The inclusion of signature verification adds 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?

No parameters exist, so baseline is 4. The description adds value by detailing the output, though parameter semantics dimension is not heavily tested.

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 returns a signed snapshot of corpus liveness including specific data fields. It distinguishes itself from the continuous SSE stream, providing a clear contrast.

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

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

Explicitly provides use cases (dashboard, report, cache refresh) and contrasts with the streaming alternative. Includes guidance on when to use this tool versus the continuous feed.

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 read-only and idempotent behavior. The description adds substantial detail: output dimensions (1440×720), projection (Plate-Carrée), bin size, color scale (log-scale), continent envelopes, and the multi-content-block reply format including an EmbeddedResource and text summary. It also mentions the alternative REST endpoint, exceeding what annotations provide.

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

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

The description is well-structured with clear sections and no redundancy. It is slightly verbose but every sentence adds value, earning a 4 rather than a 5 due to minor wordiness.

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

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

Given no parameters and no output schema, the description is fully comprehensive. It covers the tool's purpose, invocation triggers, output format, dimensions, color scheme, and even an alternative REST endpoint, leaving no gaps for an agent.

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

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

With zero parameters, the baseline is 4 per guidelines. The description correctly omits parameter details as none exist, so no deduction is needed.

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

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

The description clearly states that the tool returns a 'Live SVG render of the responder's corpus density', which is a specific verb+resource combination. It distinguishes itself from siblings by focusing on a visual coverage map, leaving no ambiguity about its purpose.

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

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

The description explicitly lists query patterns that trigger this tool ('where do you have data?', 'show me the coverage'), providing clear context. However, it does not mention when not to use it or offer alternatives, so it scores 4 instead of 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?

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds context about the returned fields (e.g., has_materializer, facts_count) and warns about cube placeholders. No contradictions.

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

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

Well-structured: a concise summary followed by detailed usage guidance and field explanations. Every sentence adds value; no wasted words.

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

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

No output schema, but the description thoroughly explains the return fields and their practical implications. Combined with annotations, it provides complete context for using the tool.

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

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

There are zero parameters, so baseline 4 applies. The description does not need to add parameter information.

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

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

The description clearly states the tool's purpose: 'Per-band live status — what data is alive AND auto-materializable, with history bounds, tempo cadence, and the responder pubkey that signs the band.' It distinguishes itself from siblings like `emem_recall` by advising to call this before recall.

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 guidance: 'When to use: Call BEFORE emem_recall when you don't know which bands answer at this responder.' It explains how to interpret each returned field and when to use other tools like `emem_backfill`. It also tells which bands to ignore.

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, idempotentHint, destructiveHint. Description adds context: catalog is driven by same registry as recall path, so listed items materialize exactly. Makes behavior predictable.

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

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

Description is front-loaded with key information and structured well. Slightly verbose but every sentence adds value. Could be slightly more concise but overall good.

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

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

Given no parameters and no output schema, the description fully covers what the tool returns (history windows, kind, backfill support) and provides clear usage context. Nothing 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?

Input schema has no parameters, so no parameter descriptions needed. Schema coverage is 100%. Baseline score of 4 applies due to zero parameters.

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

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

Description clearly states it is a temporal catalog per band, listing history availability, kind, tempo seconds, wire path, and backfill support. It distinguishes from siblings by specifying that it should be called before emem_backfill or historical recall to avoid errors.

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: before emem_backfill or any historical recall, to check if a band has meaningful past. Also mentions what to avoid (trial-and-error 422s on now-only bands) and to enumerate per-year vintages.

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 behavioral traits beyond annotations: independent degradation when bands are missing, output renaming to avoid confusion, and an 'inconclusive' response when neither half is computable. No contradiction with annotations (readOnlyHint=true is consistent with a nondestructive proxy).

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

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

The description is front-loaded with the formula and key behavioral notes, then usage guidelines. It is slightly verbose with the mathematical details but each part is relevant and well-organized. No wasted sentences.

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

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

Given the single-parameter input and moderate complexity, the description covers all necessary aspects: formula, edge cases (missing bands, inconclusive), output handling (renamed score), and explicit comparisons to sibling tools. No output schema is present, but the description sufficiently explains the return behavior.

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% (the single 'cell' parameter is fully described in schema). The description adds no new semantic meaning about the parameter beyond 'cell64 or place name' and 'known cell' in context, so baseline 3 holds.

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

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

The description clearly states it is a composite deforestation-alert score using NDVI drop and embedding change, with a specific formula. It distinguishes itself from siblings like emem_hunt, emem_triple_consensus, and emem_eudr_dds by specifying its single-score, known-cell focus.

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

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

Explicit 'When to use' section provides clear guidance: use for a single 0..1 alert at a known cell, do not treat half-score as full composite, and directs to emem_hunt for multi-cell discovery, emem_triple_consensus for the three-encoder ensemble, and emem_eudr_dds for EUDR evidence.

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?

Description adds value beyond annotations by stating the return type (signed DerivativeFact + receipt) and that the delta is content-addressed and citable. No contradictions 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?

Three concise sentences: purpose, usage, return type. No extraneous information, well-structured for quick parsing.

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

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

With 0% schema coverage and no output schema, the description fails to explain key concepts (DerivativeFact, cell) and omits error handling or prerequisites, making it incomplete for reliable invocation.

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

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

Schema coverage is 0%, and description only explains 'band' and two 'tslots' parameters. The required 'cell' parameter is not mentioned, leaving a significant gap in understanding.

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

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

Description clearly states it computes a signed delta (DerivativeFact) between two tslots for a band, distinguishing it from general state diff tools. However, the term 'DerivativeFact' is domain-specific and may require additional context.

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 usage triggers ('what changed between t1 and t2', 'give me the delta') but does not mention when to avoid this tool or alternative tools like emem_state_diff.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral context: returns signed list of edges, receipt commits edge CIDs, no deletion, shadowing with as_of_tslot, error on ambiguous input. 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?

The description is lengthy but well-structured with sections: core action, usage, tips. It front-loads important information. Every sentence adds value, though some might consider it verbose for a simple read operation. However, given complexity, it 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?

Without an output schema, the description explains return values (signed list of edges, distinct neighbour fact CIDs) and how to use them (follow with emem_fetch or emem_verify_receipt). It covers enough for an agent to correctly invoke and process results. No gaps.

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

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

Schema description coverage is 100% with all 6 parameters documented. The description adds meaning: explains direction inference from subj/obj, honest error on ambiguous input, as_of_tslot shadowing, pred filter examples. This enhances understanding 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 it reads temporal knowledge-graph edges with specific verbs 'Read temporal knowledge-graph edges' and explains the two directions (out/in). It distinguishes from sibling tools like emem_recall by noting that emem_recall gets a fact while this gets connections. The scope and action are unambiguous.

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

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

The description provides explicit when-to-use scenarios: 'what is this related to', 'what replaced this observation', 'why is this value contested'. It also gives a tip for a quicker alternative (emem_recall with include:["edges"]) and warns about ambiguous/empty subj/obj errors. This fully guides selection.

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

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

The description explains the fusion logic (selects between Cop-DEM for land, GMRT for water) and mentions return fields (elevation_m, source, coherence_note). Annotations already indicate read-only, so description adds value without redundancy.

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

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

The description is concise (about 100 words) and well-structured: purpose first, then usage guidelines, then parameter instructions. Every sentence adds value without fluff.

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

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

The description covers input methods, fusion logic, outputs (including edge case of coastline disagreement), and when to use alternatives. For a tool with no output schema, it provides sufficient context for correct usage.

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

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

The description clarifies the mutual exclusivity of parameters (place, lat+lng, or cell) and provides context for each, such as 'skip geocoding entirely' for cell. This adds meaning beyond the schema descriptions.

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

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

The description clearly states the tool provides a unified elevation value by fusing multiple datasets. It explicitly contrasts with emem_recall which gives individual dataset values, helping the agent distinguish when to use this tool.

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 usage conditions (when user asks 'how high is X' or 'what's the elevation') and provides an alternative tool (emem_recall) for when individual dataset values are needed.

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 read-only, idempotent, and non-destructive. The description adds important details: CPU-only, NaN handling, return of centroid_cid, and 'inconclusive' signal when no vectors. No contradictions.

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

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

Two well-structured paragraphs: first explains the computation, second gives usage guidance. Efficient and no redundant sentences.

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

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

Despite no output schema, the description covers return values (centroid, normalized, cid) and error conditions. It could detail output structure more, but given complexity, it is largely complete.

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

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

Schema coverage is 100%, but the description adds value by explaining the relationship between place, polygon_bbox, and cells as alternatives, and the max_cells cap surfaced as coverage_capped.

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

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

The description clearly states the tool's purpose: mean-pool the 128-D GeoTessera embedding over a region. It distinguishes from siblings by mentioning region_similarity composes and targeting region-level rather than single-cell use.

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 'When to use' section provides explicit context for using the tool for similarity search, clustering, or linear probes. However, it does not explicitly state when not to use or list alternatives among siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds CPU-only constraint, cell requirement, and the inconclusive result. This provides additional behavioral context beyond 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 concise, front-loaded with the definition and interpretation, followed by usage guidelines. Every sentence serves a purpose with no redundancy.

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

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

Given the tool's complexity and no output schema, the description covers key aspects: definition, usage, constraints, and a note on inconclusive results. It lacks detail on the signed result but is otherwise 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 coverage is 100%, so parameters are already described. The description adds value by clarifying the region alternatives (place/polygon_bbox/cells) and the cell count requirement, enhancing understanding beyond 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 quantifies landscape diversity using embeddings, provides the formula, interpretation range, and region specification. It distinguishes itself by mentioning pairing with emem_terrain, implying a complementary 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?

The description explicitly says 'When to use' with specific scenarios (habitat-heterogeneity, monculture vs. mosaic, ranking) and a condition (needs ≥2 cells). It does not explicitly state when not to use, but the context is clear.

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

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

The description adds the behavioral detail that the codes are 'wire-stable' and 'stable', implying they don't change over time. This goes beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) which already indicate safe, read-only, idempotent behavior.

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

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

The description is two sentences long, front-loading the purpose and usage. Every word is necessary; no fluff or redundancy.

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

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

Given the tool's simplicity (no parameters, no output schema, straightforward purpose), the description is fully complete. It tells the agent exactly what the tool does and when to use 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?

With zero parameters, the schema description coverage is 100% by default. The description adds no parameter-specific details, but according to guidelines, a baseline of 4 is appropriate when there are no parameters.

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

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

The description explicitly states the tool is a 'stable error code catalog' and uses the verb 'enumerate' to describe its action. It clearly distinguishes itself from the many sibling tools, none of which appear to provide a similar 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?

The description includes a 'When to use' section that explains the tool is for enumerating error codes when the LLM wants to programmatically branch on responses. While it doesn't explicitly state when not to use it, the context is clear enough for an agent to decide.

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 detailed behavioral traits beyond the annotations: forest definition (10% canopy / 0.5 ha / 5 m height), baseline (JRC GFC2020 V3 with Hansen fallback), per-plot verdict types (pass/fail/not_in_scope/indeterminate/below_mmu), inclusion of signed CIDs, and legality disclaimer. It also notes when fallback layers are absent. This fully informs the agent of the tool's behavior and limitations.

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

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

The description is lengthy but well-structured, starting with the core purpose, then input details, then output description, then usage guidance. Each sentence adds necessary information for a complex regulatory tool. However, could be slightly more concise without losing critical 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 (6 parameters, nested objects, no output schema), the description is exceptionally complete. It explains the output format (Annex II envelope, per-plot verdict, signed CIDs, failing-cell fraction, forest baseline, legality disclaimer) and what to surface to the user. No gaps remain for effective agent invocation.

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

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

The description adds significant meaning beyond the input schema. For example, it explains the geometry rule (Polygon for >4 ha or cattle, Point for ≤4 ha non-cattle per Article 2(28)), the interpretation of cut_off_date (only loss after 2020-12-31 counts), the derivation of max_cells_per_plot (auto-derived based on area), and acceptable forest_baseline_override values. With 83% schema coverage, the description enriches understanding of each parameter.

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

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

The description clearly states the tool's purpose: 'Produce a Due Diligence Statement per Regulation (EU) 2023/1115 for one or more plots.' It specifies the input (plots with geometry, country, commodity code, quantity) and output (Annex II envelope with verdicts). This distinguishes it from all sibling tools, none of which produce EUDR statements.

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 'When to use' paragraph explicitly advises when to call the tool: when a commodity supplier or EU importer needs to evidence due diligence. It recommends pairing with a partner legality module and submitting to TRACES NT. It also clarifies what is out of scope (legality under Article 9(1)(b) is 'structurally out of EO scope'). This provides clear context and alternative/companion 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 already mark the tool as read-only and idempotent. The description adds that it returns the same structure as `/v1/algorithms/{key}` and responds with `cid_not_found` on invalid keys. This adds useful behavioral context beyond annotations, though not extensive.

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

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

The description is concise, with two focused sentences in the first paragraph and clear bullet-style guidance in the second. Every sentence is purposeful, no fluff, and the critical information is front-loaded.

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

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

Given the tool has no output schema, the description outlines the return structure (kind, inputs, formula, output, citation, references) and references the same structure as a known API call. This is sufficient for the tool's moderate complexity, though a bit more detail on output format could be added.

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 schema already describes the `key` parameter with an example and how to obtain valid keys. The description repeats this context but does not add significant new semantics beyond what the schema provides.

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: 'Per-key drill-down on a single composition recipe — full body ... for ONE algorithm key.' It uses specific verbs ('drill-down') and distinguishes from the sibling `emem_algorithms` (catalog), making the tool's unique role obvious.

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

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

The description provides explicit when-to-use guidance: 'Call when you already know the algorithm key ... and need its full math. Cheaper than fetching the 190 KB catalog when you only need one entry.' It also explains what happens on 404 (key not found) and directs to `emem_algorithms` for the live key list, fully covering usage context.

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, idempotentHint, and non-destructive. Description adds that the response is byte-identical across responders and the CID is the validator. No contradictions; additional context beyond annotations.

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

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

Concise and well-structured: first sentence states purpose, followed by details and a clear 'When to use' section. Every sentence adds value, no unnecessary words.

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

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

Given the tool is simple (one parameter, no output schema), the description fully explains what is returned (fact fields like value, unit, sources, signer, etc.) and the property of byte-identical responses. No gaps.

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

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

Schema coverage is 100% with a detailed description of the cid parameter, including its origin from sibling tools. The description repeats this information but does not add new meaning beyond the schema, so baseline 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 the tool fetches a fact by content-address (CID) and returns the full signed fact. It distinguishes itself from siblings by explaining it closes the citation loop, allowing resolution of CIDs from recall, attest, materialize, or verify.

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 'When to use' section details scenarios: whenever a fact_cid is obtained from sibling tools or other agents. It also highlights utility for verifying downstream citations. Clearly defines context without need for exclusion statements.

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 safe read-only operation; description adds behavioral details like tile cap (16 tiles per call), output format, and provenance requirements. 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?

Description is front-loaded with key information, well-structured with sections. While somewhat lengthy, every sentence adds value; minor redundancy could be trimmed but overall 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 no output schema, the description thoroughly explains the return structure (GeoJSON FeatureCollection with polygons and properties). Covers provenance, attribution, and constraints like zoom ranges and tile limits, leaving no major gaps.

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

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

Input schema has 100% description coverage, so baseline is 3. The description adds value by explaining zoom default behavior, the relationship between place and polygon_bbox, and a hint about splitting for wide farms, moving it 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 returns per-field agricultural boundary polygons from the Fields of the World global product, specifying output as GeoJSON FeatureCollection with detailed properties. It distinguishes itself from the sibling emem_recall_polygon by noting an alternative use case.

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

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

Explicit 'When to use' section provides clear conditions (user asks about farms/fields, OSM boundary too coarse). Includes practical guidance on splitting large farms and mentions alternative tool emem_recall_polygon for a different scenario.

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 annotations (readOnly, idempotent), the description adds valuable behavioral details: mode performance trade-offs, bi-temporal filtering bypassing ANN, and default band. This significantly aids 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?

Concise yet comprehensive: usage guideline followed by parameter specifics. No redundant information, each sentence adds value.

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

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

Lacks description of output format (e.g., returned cell IDs or scores). Given no output schema, the description should clarify what the tool returns. Otherwise, strong.

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?

Description enriches schema with practical meaning: key format distinction, multi-year band option, mode performance numbers, and as_of bypass notes. This is critical for correct parameter setting.

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 performs k-NN over the corpus using cell embedding or inline vector, which is specific and actionable. It distinguishes from siblings by focusing on embedding similarity.

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

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

Provides explicit 'When to use' scenarios like 'find places like X', which helps the agent decide. However, it does not mention when not to use or explicitly compare to sibling tools.

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

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

Annotations already state readOnlyHint, idempotentHint, and destructiveHint false. The description adds specific behavioral context about what the tool returns (platform, revisits, resolution, license) and that it helps attribute imagery, going beyond annotations without contradicting them.

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 efficiently structured with a concise first sentence for the main purpose, followed by a 'When to use' section. Every sentence adds value, no redundancy, and it is front-loaded with key information.

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

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

Given the tool has no parameters and no output schema, the description sufficiently explains its purpose, content, and usage context. It also advises pairing with sibling tools for additional metadata, making it contextually complete.

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

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

The input schema has 0 parameters, and schema description coverage is 100%. The description does not need to add parameter details; baseline is 4, and the description effectively explains the tool's output without needing param info.

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

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

The description clearly states the tool provides a per-band satellite-and-sensor fleet inventory naming upstream platform, revisit cadence, native resolution, and license. It distinguishes itself from siblings by specifying its unique content and usage, and mentions pairing with emem_materializers and emem_sources.

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 'When to use' section explicitly lists example user queries ('which satellite is this from', 'what's the revisit time') and directs to pair with specific sibling tools for deeper context, providing clear guidance on when and how to use the tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds context about what signals are retrieved (year-of-loss, land class) and that it provides both historical and current data. No contradictions.

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

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

Three concise sentences with front-loaded purpose and clear usage guidelines. Every sentence adds value; no redundant information.

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

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

Given the tool has 8 parameters and no output schema, the description explains what data is returned (year-of-loss, land class) but does not describe the structure or format of the response. More detail on output would improve 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 coverage is 100%, so all parameters have descriptions. The description does not add additional semantics beyond the schema; it explains the overall tool purpose but does not elaborate on individual parameter meanings.

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 explicitly states the verb 'recall', the resource 'forest signals', and specifies the exact data sources (Hansen GFC + ESA WorldCover). It clearly distinguishes this tool from siblings like emem_deforestation_alert and emem_sar_forest_disturbance.

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

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

Provides explicit when-to-use guidance: 'Use when the user asks about deforestation, canopy cover, forest loss, or wants a forest-vs-not classification.' It also explains what each dataset contributes. However, it does not contrast with alternatives or mention when not to use.

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

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

The description does not add behavioral information beyond what the annotations already provide. Annotations declare readOnlyHint: true, idempotentHint: true, destructiveHint: false. The description adds 'derivation recipes' context but no behavioral traits. The burden is on annotations, and there is no contradiction.

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 short sentences with no extraneous information. It front-loads the purpose and provides immediate usage guidance. Every sentence is valuable.

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

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

Given no parameters and no output schema, the description adequately explains what the tool does and when to use it. It could mention the return format (e.g., list of functions), but the purpose is clear enough for an agent to decide. The context of sibling tools further clarifies its role.

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 schema coverage is 100% (empty). The description does not need to add parameter semantics, as there are none. Baseline 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 the tool's purpose: 'Active function registry (derivation recipes)' and specifies that it tells 'which derivative ops are available for emem_diff or how a band is computed from upstream sources.' This is a specific verb (know, compute) and resource (derivation recipes), and it distinguishes itself from sibling tools like emem_diff and emem_bands.

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 provides a usage condition: 'Call when you need to know which derivative ops are available for emem_diff or how a band is computed from upstream sources.' This gives clear guidance on when to use the tool, though it does not explicitly state when not to use it or list alternatives. However, the context of sibling tools implies that this is a registry query, not a computation tool.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds no contradiction. It provides extra context on returned data (resolution, axis sizes, lineage) and future plans, which is useful beyond 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 well-structured with purpose first, then usage, then technical details. It contains some extra details (e.g., future resolution aims) but remains fairly concise and front-loaded.

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

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

Given no parameters and no output schema, the description fully explains what the tool returns, when to use it, and how it relates to other tools. It is complete for the tool's simplicity.

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

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

No parameters exist, so schema coverage is 100%. The description does not need to clarify parameters; it focuses on output. Baseline 4 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 it returns 'cell64 ground resolution, lat/lng axis sizes, DGGS lineage' and distinguishes from the sibling emem_recall_polygon by noting when each is appropriate.

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

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

Explicitly says 'When to use: Call once at session start (or when the user asks about cell resolution / "how big is a cell")' and mentions alternative tool emem_recall_polygon for cases needing more cells.

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 reading MODIS LST at centre and neighbours, CFL-stable integration, return of signed forecast, materialization of 9 facts on miss, and citation of input CIDs. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent and the description adds valuable behavioral context beyond them.

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

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

The description is well-organized: functional definition, then mechanism, then when-to-use section, then parameter details. Each sentence serves a purpose, and the critical information is front-loaded. No unnecessary words.

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

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

Given no output schema, the description explains the process, inputs, and constraints well, but it lacks details on the exact return format (e.g., temperature value vs. delta) and units. It states 'returns a signed forecast' but does not specify units or interpretation. Slightly incomplete for full contextual 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?

While schema covers all three parameters at 100%, the description adds significant value: it explains the default diffusivity for urban surfaces (Oke 2017), suggests values for water and vegetation, and notes the hours_ahead cap of 168. This enhances parameter understanding 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 is a 'Forward-step 2-D explicit finite-difference solver for the heat equation' over a 3×3 stencil, with the title '2-D heat-equation forecast (urban LST evolution)'. It distinguishes from siblings by emphasizing it is a 'real PDE rollout — not a decay-scoring heuristic'.

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 'When to use' for short-horizon LST forecasts, provides guidance on changing diffusivity per surface type, notes the one-week horizon cap, and gives performance estimates (cold/warm start timings). This clearly defines when and how to use the tool.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive. The description adds detailed behavioral traits: fans out across up to 32 cells, returns top 8 hotspots with specific fields, ranking uses primary scalar only, and oil_slick returns a not_yet_implemented response. No contradictions.

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

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

The description is well-structured with two paragraphs: first explaining the tool mechanism, second giving usage guidance. It is front-loaded with the purpose. However, it is slightly verbose in parts, but still concise considering the amount of detail.

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

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

Given the complexity of the tool (3 parameters, nested object, no output schema), the description covers all necessary aspects: purpose, parameters, behavioral details, output format, and alternative tools. It leaves no major gaps for an agent to use it correctly.

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

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

Schema coverage is 100%, and the description adds significant meaning: explains event keyword mapping to algorithms, region geocoding, and polygon_bbox alternative. It also provides caveats like oil_slick not implemented, which is 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 purpose: event-discovery sweep over a region with a keyword and region input, returning top 8 hotspots with details. It distinguishes itself from siblings like emem_ask, which is mentioned as an alternative for free-text input.

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 provides when to use (open-world discovery questions with examples) and when not (oil_slick not implemented, pointing to proxies). It also mentions emem_ask as an alternative for free-text input, offering clear 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?

Annotations already declare readOnly=true, openWorldHint, idempotentHint, non-destructive. Description adds only that it returns a 'plan or executed result', which is minimal but consistent. No contradictions.

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

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

Reasonably short, but critically fails to explain parameters. It front-loads purpose, but conciseness is not an excuse for omission of essential parameter 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?

With 10 parameters, no output schema, and no parameter descriptions, the definition is severely incomplete. The agent cannot know how to fill parameters like 'claim' (object) or 'window' (array).

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

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

Schema has 10 parameters with 0% description coverage. The description only mentions 'typed Intent' relating to the 'type' enum, leaving the other 9 parameters (a, b, k, key, band, cell, claim, window, description) completely unexplained. The description does not compensate for the lack of schema documentation.

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

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

The description clearly states the tool's purpose: submit an Intent and get a plan or result. It distinguishes itself from siblings by indicating it avoids manual primitive selection.

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 when-to-use guidance with concrete examples ('where is X', 'is A like B') and contrasts with picking primitives directly, making it easy for the agent to decide.

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 annotations (readOnlyHint, idempotentHint, etc.), the description reveals fixed coefficients, clamping to NDVI's physical range, lookback behavior, error response 422, and receipt citation. It adds substantial context without contradicting 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 front-loaded with the core purpose, then formula, then usage. It includes a future v2 note which is slightly extraneous but not excessive. Overall well-organized and informative.

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

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

No output schema exists, so the description should explain return format. It mentions 'returns the prediction clamped to NDVI's physical range' and 'surfaces the count in lookback_months_used', but does not fully specify the output structure (e.g., single value or dict with metadata). Error handling is covered.

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

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

Schema coverage is 100%, but the description adds the formula (α,β,γ), the limit on forecast_horizon_months to 1, and that band supports only 'indices.ndvi' in v1. This algorithmic context goes beyond the schema's basic 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 predicts next-month NDVI at a cell using a constrained JEPA-pattern AR(2) seasonal predictor. It specifies the resource (NDVI at a cell), action (predict), and scope (v1 supports NDVI only, horizon=1 month). It distinguishes from siblings like emem_jepa_predict_v2 by noting v2 is future.

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 'When to use' section explicitly describes scenarios like crop-stress monitoring and growing-season tracking. It advises to chain to emem_backfill if no history exists. However, it does not mention when not to use this tool or compare to other NDVI-related tools like emem_ndvi.

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?

Goes beyond annotations by detailing return structure (per-band value/confidence/lags/via), model receipt contents (model_id, version, skill, honesty warnings), fallback modes (persistence, climatology), and pitfalls (untrained_baseline, NEGATIVE_SKILL). No contradiction with readOnlyHint.

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

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

Well-structured with leading purpose, details, and usage section. Slightly verbose but each part earns its place. Front-loaded with key information.

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

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

Covers expected output, model metadata, skill interpretation, fallback conditions, and error handling. Without an output schema, the description compensates fully by explaining return fields and edge cases.

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% with a single parameter 'cell' already described in schema. Description repeats that cell is cell64 or place name but adds no new semantics beyond 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?

Specifically states it predicts next-step values of 4 environmental scalars (NDVI, LST day/night, PM2.5) using a learned MLP. Clearly distinguishes from v1 which returns a single NDVI scalar via closed-form coefficients.

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 'When to use' section instructs to use for short-horizon forecasts grounded in attested history. Mentions error handling (422 with backfill hint) and advises reading honesty warnings. Contrasts with v1 for single-scalar predictions.

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 annotations (readOnlyHint, idempotentHint), the description reveals the response structure (data_at_this_cell with three sub-fields) and hints at the geocoding services used. No contradictions.

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

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

The description is well-structured with clear sections (purpose, usage, response details). Though somewhat lengthy, every sentence adds value. Could be slightly more concise.

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

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

Given the complexity of the tool (4 parameters, no output schema), the description is complete: it explains the return values, differentiates from a key sibling, and covers usage context. Minor omission: no explanation of what cell64 is, but that's domain-specific.

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% with detailed descriptions for each parameter. The tool description adds no additional parameter semantics beyond what the schema provides, so a 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 it resolves a place mention to a cell64 identifier and returns band inventory. It distinguishes itself from sibling emem_ask by noting when to use each.

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

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

Explicitly says 'When to use' with the condition of needing cell64 or band inventory, and provides a clear alternative (emem_ask for single-shot) for when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about the data type (1 km resolution, 8-day composite) and return value (both fluxes). It does not contradict annotations and provides value beyond them.

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

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

The description is extremely concise with two sentences plus a targeted usage note. Every sentence adds value, and the key information is front-loaded.

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

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

Given the absence of an output schema, the description should explain what the response contains. It mentions returning 'both fluxes' but does not describe the response structure, units, or date ranges. For an 8-parameter tool, this is a 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 coverage is 100% with each parameter having a description. The description adds minimal extra meaning beyond the schema, merely mentioning 'day-8day + night-8day composites' which loosely relates to band parameters but lacks explicit linkage. Baseline 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 the tool retrieves MODIS land surface temperature day and night 8-day composites at a location. This distinguishes it from siblings like emem_ndvi (NDVI) and emem_air (air temperature) by specifying 'land surface temperature' and 'day + night' composites.

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

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

Provides explicit when-to-use guidance: surface heat, urban heat island, thermal anomalies, day/night LST. It also notes that it returns both fluxes for deriving day-night spread. However, it does not mention when NOT to use this tool or list alternative tools for related 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's safe and idempotent. Description adds context about what the output represents and its use in reproducibility, but no additional behavioral details (e.g., caching, update frequency).

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 short sentences, no fluff. First sentence defines the output, second gives usage context. Perfectly concise.

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

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

For a no-parameter tool, the description covers what it returns and why to use it. Lacks exact return format (e.g., mapping or list), but sufficient for agent to understand 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?

No parameters exist, so schema coverage is 100%. Description doesn't need to add parameter info; it appropriately focuses on output. Baseline 4 is justified.

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

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

Description clearly states the tool returns active manifest CIDs for bands, functions, sources, and schema. It distinguishes from sibling tools that operate on individual components, making the purpose specific and unambiguous.

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

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

Explicitly tells when to use: to learn registry versions and cite for reproducibility. While it doesn't mention alternatives or when not to use, the guidance is clear and actionable.

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, idempotentHint=true, destructiveHint=false. Description adds behavioral context such as the agent_hint block explaining trust model and absence-fact contract, which goes beyond annotations. However, no additional side effects or constraints 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.

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

The description is well-structured: first a definition, then usage guidance, then detailed fields. Every sentence provides essential information. It is concise yet comprehensive, with no wasted words.

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

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

Despite no output schema, the description fully enumerates return fields and includes the agent_hint block. It explains when and why to call the tool, making it self-contained and complete for a zero-parameter tool.

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

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

No parameters exist (input schema is empty, schema coverage 100%). Baseline for zero parameters is 4, but the description adds significant value by detailing what the tool returns and how to use it, which helps the agent understand the tool's function without needing parameters.

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

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

The description clearly states the tool's purpose: 'Auto-fetch registry: which bands the responder will materialize on a recall miss...' It lists the specific data fields returned, distinguishing its role from siblings like emem_bands and emem_coverage_matrix. The description is specific and actionable.

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 usage context: 'Call once at session start...' and gives example user queries that would trigger this tool ('do you have flood data here', 'what providers feed this', 'license attribution'). No when-not-to-use stated, but the context is clear and 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral details: each triple runs through auto-materialize recall path, fact_cids are bundled into a content-addressed envelope, and the responder signs. This provides context beyond annotations without contradiction.

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

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

Concise and well-structured. Starts with the primary action, explains process, then provides usage guidance. Every sentence is informative with no redundancy.

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

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

With no output schema, the description explains the output (bundle token format) and offline verification. Covers main aspects: bundling process, token format, use case. Complete for a tool with 2 parameters and good sibling differentiation.

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%. Description adds meaning: explains that purpose affects the CID preimage, triples are recalled via standard path, and the bundle token format is `memb:<bundle_cid>`. This enriches understanding beyond schema descriptions.

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

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

Clearly states 'Compose N (cell, band, tslot?) triples into ONE signed envelope'. Verb (compose) and resource (memory bundle) are explicit. Distinguishes from siblings by contrasting with N separate emem_memory_token composers and providing a concrete example.

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?

Includes a 'When to use' section that explicitly states when to call this tool and when to use an alternative (N separate composers). Also describes offline verifiability via /v1/verify_receipt, giving clear usage context.

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, idempotentHint, destructiveHint, confirming safe, idempotent read. Description adds value by detailing the return structure and error condition (404 with typed code), which goes beyond annotation information.

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 in the main paragraph plus a short usage paragraph. Front-loaded with return structure, no wasted words, 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?

Tool has one parameter, no output schema, but description fully explains what is returned and error behavior. Given low complexity, the description is complete and 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 has 100% description coverage for the single parameter 'token', already defining it as a memb: handle. The description adds 'rebindable handle' context, but adds minimal additional meaning beyond the schema.

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

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

The description clearly states it parses a memb: token and returns the signed bundle envelope with detailed components. It implicitly distinguishes from sibling tool emem_memory_bundle (which creates bundles), though not explicitly stating alternatives.

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

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

Explicitly says when to call: when an agent receives a memb: token from another agent and wants the underlying signed citation set. Provides context about response byte-identity to the original bundle, but does not specify when not to use or mention alternative tools.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description explains output details: severity score range 0–1, per-band kind calculation (scalar, vector, categorical), and inclusion of citations. No contradictions 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?

The description is concise yet comprehensive: two paragraphs front-load the core concept and usage, with no redundant sentences. Every sentence adds value, and structure aids readability.

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

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

Given no output schema, the description fully explains the return format (severity score, citations), severity logic, and relationships to sibling tools. It covers all necessary context for an AI agent to decide when and how to use this tool.

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

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

With 100% schema coverage, the description adds significant value by explaining the semantic role of each parameter (e.g., cell_prefix for region narrowing, min_severity for filtering trivial differences) and detailing severity scoring per band kind, which goes beyond the schema's brief 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 purpose: to surface multi-attester disagreements in the corpus. It uses specific verbs ('surface', 'returns') and distinguishes this from silently merging conflicts, effectively differentiating it from siblings like emem_compare or emem_diff.

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

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

The description provides explicit when-to-use scenarios ('when trust matters', 'audit this claim'), when-not-to-use ('the opposite of a confident single answer'), and how to narrow results (cell_prefix, band, min_severity). It also suggests follow-up tools (emem_diff, emem_edges_recall), offering complete 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 already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral details: embedding model, dimension, L2 normalization, Lance partition, fallback brute-force scan, and indexing delay. No contradiction.

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

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

Description is well-structured and front-loaded with purpose. Slightly verbose but each sentence adds value. No wasted words.

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

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

Given complexity (semantic search, fallback, indexing delay, response fields), description covers all relevant aspects. No output schema, but return details are explained (snippets, receipt fields).

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

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

Schema coverage is 100%, so baseline is 3. Description adds valuable context: q is semantic, kind default value, path_prefix example, attester_pubkey_b32 format. Enhances understanding beyond 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 it performs semantic search over /memories/* files using BGE-base-en-v1.5, differentiating it from siblings like memory_view (paging) and other search tools.

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

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

Explicitly recommends when to use (agent knows topic/paraphrase but not exact path) and when not (use memory_view for full body). Mentions alternatives and fallback behavior, providing clear 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 (`readOnlyHint: true`, `idempotentHint: true`, `destructiveHint: false`) already indicate a safe, idempotent composition operation. The description adds validation behavior (non-empty, no `:` separator), which is helpful but doesn't reveal significant new behavioral traits 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 concise with two short paragraphs. The first paragraph states the exact output format and validation. The second provides usage context. Every sentence is necessary and contributes to clarity, with no redundant information.

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

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

Given the tool's simplicity (composing a token from two inputs), the description fully covers purpose, format, validation, and usage context. It also mentions the expected pairing with another tool. No output schema exists, but the return value is clearly specified. The description is sufficient for correct invocation.

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

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

Schema coverage is 100%, providing the baseline. The description adds value by explaining that both components are validated for non-emptiness and absence of the separator `:`, which goes beyond the schema's pattern description. This clarifies the tool's internal checks.

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 defines the tool's purpose: composing a `memt:` citation handle from a cell64 and a content ID. It explicitly states the format and validation rules. The tool is distinct from siblings like `emem_memory_token_resolve` and `emem_verify_receipt`.

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

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

The description includes an explicit 'When to use' section, detailing the scenario of creating a rebindable citation string for cross-message/reference sharing. It recommends pairing with `emem_verify_receipt`. While it doesn't list when not to use or alternative approaches, the guidance is clear and actionable.

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 read-only and idempotent. Description adds context: returns parsed cell, fact_cid, fact body, and fact_url, plus 404 behavior with typed code. No mention of rate limits or side effects beyond what's implied.

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, front-loaded with the main action, efficient. Every sentence adds value without 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?

No output schema, but description covers return values (parsed cell, fact_cid, fact body, fact_url) and error handling (404 with typed code). Missing details like response format or pagination, but that seems unnecessary for this tool.

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

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

Schema coverage is 100% and parameter has description. Description goes further by explaining the token composition and the benefit over alternative approaches, adding semantic value.

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

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

The description clearly states it dereferences a memory_token to return the signed fact body. It specifies the exact token format and distinguishes from manual string-splitting and chaining GET calls.

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 'When to use' section describes the scenario of receiving a memory_token from another agent or previous turn. Also provides alternative actions on 404 (try /v1/fetch or paste at mirror).

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 annotations (readOnly, idempotent), the description discloses auto-materialization on cache miss, default 16-cell fan-out with mean/median aggregation, and the omitted per-cell arrays due to MCP size limits. This provides useful operational context.

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

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

The description is concise: three sentences plus a 'When to use' section. It is front-loaded with the core action and quickly provides actionable guidance. Every sentence adds value without redundancy.

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

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

Given 8 parameters and no output schema, the description adequately explains the tool's behavior, defaults, and alternatives. However, it does not explicitly describe the default response structure beyond mentioning omitted per-cell arrays. A small gap remains for agents expecting full output details.

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 baseline 3. The description adds value by explaining the composited pipeline ('locate → cell64 → recall'), polygon fan-out behavior, and the include parameter's purpose. This goes beyond the schema's basic 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 recalls NDVI at a point or place using Sentinel-2. It specifies the verb 'recall' and resource 'NDVI', and distinguishes itself as a one-shot, polygon-aware composite. It also contrasts with sibling emem_recall for multi-band batches.

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

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

The description explicitly states when to use: when the user names a place or lat/lng and wants NDVI number. It advises against using for multi-band batches, directing to emem_recall. It also explains polygon behavior and the n_cells parameter for point vs polygon mode.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive. Description adds valuable context: CPU-only, GeoTessera embeddings, formula details, and inconclusive behavior. No contradictions.

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

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

Front-loaded with formula and interpretation, followed by usage guidelines. Every sentence adds value. No wasted words.

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

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

For a single-parameter tool with no output schema, the description fully covers purpose, behavior (inconclusive case), and alternatives. No gaps.

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

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

Schema coverage is 100% (single parameter with description). Description does not add new semantic detail beyond what the schema provides, but this is sufficient given simplicity.

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 defines the tool's purpose: scoring consistency and outlier score using cosine similarity with 8 neighbors. It explicitly distinguishes from sibling tools like emem_state_diff by stating it is for spatial outlier detection, not temporal change.

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

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

Provides explicit when-to-use guidance (flag anomalous cell, change/edge detection) and when-not-to-use (year-over-year change, directing to emem_state_diff or emem_triple_consensus). Also specifies the inconclusive signed result condition.

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, idempotentHint, and non-destructive behavior. The description adds that the tool queries facts and can aggregate, which aligns with annotations. No contradictions.

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

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

Two sentences plus a usage note. No wasted words, front-loaded with core 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?

Given the tool has 5 parameters and no output schema, the description covers the essential behavior. However, it does not describe the return format or error handling, leaving minor gaps.

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

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

Schema description coverage is 80%, so most parameters are already documented. The description adds value by explaining the `agg` options and geometry format, but does not substantially enhance 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 that the tool queries facts over a region (single cell or list of cells) with optional per-band aggregation. Examples of user queries further clarify the purpose. This distinguishes it from sibling tools like emem_recall.

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 says 'Call when the user asks ...' and provides examples. It also gives guidance on using the `agg` parameter, but does not explicitly list when not to use it or alternatives.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds valuable behavioral details: auto-materialization on miss, response carries materialize_notes, timing (~180ms first call, ~10ms cached), and that empty results without notes indicate no materializer. No contradictions.

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

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

The description is somewhat long but every sentence adds value. It is structured with a lead sentence, a 'When to use' section, and important notes in bold. Could be slightly tighter, but the information density is high.

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

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

No output schema is provided, but the description explains what is returned (every Primary fact, materialize_notes) and handles edge cases (empty result with no notes). It covers auto-materialization, timing, and scoping. Complete enough for a recall tool with good annotations.

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

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

Schema coverage is 100%, so the schema already describes all parameters. The description adds value by explaining the 'band' parameter as a convenience alias for 'bands' and their merging behavior, and the 'scope' parameter's filtering effect. This goes beyond the schema descriptions.

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

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

The description clearly states the verb 'Recall' and the resource 'facts about a cell'. It also distinguishes the key feature 'auto-materializes on miss', which sets it apart from siblings like emem_recall_many and emem_recall_polygon. The title reinforces the purpose.

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

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

The description explicitly advises calling after emem_locate or with a known cell64. It explains when auto-materialization occurs and references related tools (emem_coverage_matrix, emem_materializers) for checking materializer status. However, it does not directly compare with emem_recall_many or emem_recall_polygon for when to use each.

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 provide readOnlyHint, idempotentHint, etc. Description adds parallel fan-out, aggregation, auto-materialization, and contract reference to emem_recall.

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

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

Two concise paragraphs: functionality then usage. Front-loaded key info, 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?

No output schema, and description relies on 'same contract as emem_recall' without explaining return structure. Lacks error handling or partial results details.

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?

100% schema coverage; description adds usage guidance: pass cells list, bands shape same as emem_recall, batch limit.

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 recalls facts across up to 256 cells, distinguishes from siblings emem_recall (single cell) and emem_recall_polygon (polygon query).

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 defines when to use: after emem_find_similar, emem_recall_polygon, or for precomputed sets; includes batch recommendation for >256 cells.

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, idempotentHint, not destructive. Description adds value by explaining return values (merged_facts, by_cell, polygon_bbox.source indicator), fallback behavior (centre_cell_bbox), and special farm query handling including performance implications for `ftw_fields`.

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

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

The description is a single paragraph of 4 sentences, each serving a purpose: purpose, use case, parameter/return details, and special case. No wasted words; front-loaded with key information.

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

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

Despite no output schema, the description explains key return components and fallback behavior. It covers the main parameters and special include options. However, it could explicitly list all return fields or provide a more structured summary, but overall it's sufficient for an agent to understand usage.

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

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

Schema coverage is 88% (high), so baseline is 3. Description adds meaningful context for `include` (explains ftw_fields and performance), `place` (geocoder resolution), and `polygon_bbox` (alternative). Other parameters like `as_of_tslot` and `as_of_signed_at` are not elaborated further, but schema already describes them adequately.

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 what the tool does: 'Recall facts across every cell inside a place's polygon.' It explains the problem it solves (closing place-name-drift gap for wide features) and distinguishes from sibling tools like emem_recall and emem_field_boundaries.

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: 'When to use: Call when the user names a wide feature... where one cell is too small.' It also provides alternatives: using `place` vs `polygon_bbox` and mentions dedicated `emem_field_boundaries` for pure-fetch shape.

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 (readOnlyHint, idempotentHint, etc.) are present, and the description adds key behavioral context: CPU-based computation (no GPU), coverage surfacing, and the edge case of returning a signed 'inconclusive' when cells lack embeddings. No contradictions.

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

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

The description is concise at five sentences, with a clear front-loaded purpose and a structured 'When to use' paragraph. Every sentence adds value, no redundancy.

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

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

Given the presence of annotations, full schema coverage, and no output schema, the description sufficiently explains the algorithm, return type (cosine similarity or inconclusive), and edge cases. It also notes performance characteristics (CPU-fetched) and coverage reporting.

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% with detailed descriptions for each parameter. The optional description text adds meaning by explaining the centroid calculation and the nature of region objects (place, bbox, cells). This goes beyond what the schema alone provides, though the schema is already strong.

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 answers 'how alike are these two places?' specifying the use of cosine similarity on mean GeoTessera embeddings with a range of [-1,1] and interpretations (+1 identical, 0 unrelated). It distinguishes from siblings emem_compare and emem_find_similar by mentioning their purposes.

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 'When to use' section provides explicit context for when to call (comparing overall land character) and when not (if no embedding-covered cells, returns inconclusive). It also names alternative tools: emem_compare for cell-to-cell vectors and emem_find_similar for k-NN retrieval.

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