emem — Earth memory protocol

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that the tool composes multiple steps (locate→recall→aggregate) and notes the data resolution and coverage, providing useful 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 with two sentences plus a 'When to use' section. It is front-loaded with the core purpose and reserves the second part for usage guidance. 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?

The tool has 7 parameters and no output schema. The description explains the tool's workflow (composing locate/recall/aggregate), the data source (CAMS), and usage context. It could mention the return format or aggregation details but is sufficiently complete for a read-only snapshot tool given the 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 itself documents parameters thoroughly. The description adds minimal additional param semantics beyond mentioning the composition process and data source characteristics.

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 at a place, specifying PM2.5, NO2, O3. It distinguishes from siblings by mentioning the data source (CAMS) and the composition of locate/recall/aggregate, aiding 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?

The description explicitly provides a usage scenario ('when user names a place and asks about air quality...') and suggests an alternative for finer-grained data (pair with stations). It lacks explicit when-not-to-use but is adequate.

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

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

With no annotations provided, the description carries the full burden. It explains the tool is a content-addressed dictionary, that the agent applies formulas and quotes algorithm key and CID for reproducibility. It also notes that embedding entries operate on geotessera and warns that emem_find_similar is faster for k-NN, showing good transparency.

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

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

The description is well-structured and front-loaded with the core purpose, followed by usage guidelines and details about entry structure. It is concise enough without being overly verbose, though a slight trim could be possible.

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 0 parameters, no output schema, and no annotations, the description completely covers what the tool does, when to use it, what entries contain, and how to leverage results (quoting CID). It even contrasts with an alternative tool, making it fully adequate for an agent.

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

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

The input schema has 0 parameters (empty object), so schema coverage is 100%. The description does not need to add parameter info, but it adds value by detailing the internal structure of each entry (kind, bands, formula, output, citation). Baseline for 0 params is 4, and this meets it.

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 'dictionary of composition recipes' for composite queries, distinguishing it from siblings like emem_bands and emem_recall that handle single band readouts. It explicitly mentions the kinds of entries (solo, combined, embedding) and their components.

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 when the user's question is COMPOSITE (flood risk, urban density, water consensus, change-since-2020) rather than a single band readout.' Also provides a clear alternative: 'for the most common k-NN pattern the protocol-native emem_find_similar is faster.'

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

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

No annotations are provided, so the description carries the full burden. It fully discloses the chain of operations (locate → recall → algorithm chain), the return envelope structure, honest caveats about resolution and cadence, and the out-of-scope 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?

The description is long but well-structured with clear sections and front-loading of the main purpose. Every sentence provides unique value, though it could be slightly trimmed without losing 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?

No output schema exists, so the description must explain the return value. It does so thoroughly: topic_routing, facts, algorithms for question, optional Sentinel-2 RGB scene URL, and caveats. Parameter usage and out-of-scope behavior are also covered. Extremely 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%, baseline 3. The description adds significant context beyond the schema: explains the role of q, the alternatives for location (place, cell, lat+lng), and the effect of include_image. This extra detail raises the score.

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

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

The description clearly states the tool performs a single-shot free-text answer about real-world locations with signed satellite/elevation/water/built-up receipts. It distinguishes from sibling tools like emem_locate, emem_recall, and emem_algorithms by describing the full chain (locate → recall → algorithm chain) executed server-side.

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 trigger condition: when the user asks a question mentioning a real-world place and you would otherwise refuse or fall back. It tells the agent to forward the question verbatim and specifies parameters. However, it does not mention when to avoid this tool or suggest alternatives among siblings, though the trigger is very specific.

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, etc. The description adds useful context: default centroid behavior for polygons, cost implications of n_cells, and default band set. 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 paragraphs, front-loaded with purpose. Every sentence adds value—no redundancy. 'When to use' is clearly separated. Highly efficient.

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

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

Given 7 parameters and no output schema, the description covers the main use, parameter trade-offs, and alternatives. It lacks explanation of return format, but the purpose and behavior are clear enough for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value: explains n_cells polygon fan-out, default band set, and when to use place vs lat/lng. It deepens understanding 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 'One-shot multi-band recall at a place' and specifies the default band set, contrasting with single-band siblings like emem_recall. It explicitly names the verb 'recall' and resource 'multi-band snapshot'.

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 tells when to use (standard situational readout) and when not (single band: use emem_recall or domain-specific shortcuts). It also explains polygon behavior with n_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 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?

No annotations provided, but the description indicates it's a read-only list retrieval with no side effects. It could mention if the registry is static or dynamic.

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

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

Two sentences with no waste; first defines content, second gives usage guidance.

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?

Adequate for a simple listing tool; could mention return format but not essential given context.

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

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

Input schema has no parameters, so schema coverage is 100%. Description adds no param info, 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 it provides the band registry (offsets, dims, tempo, privacy) and distinguishes it from siblings as a foundational setup 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?

Explicitly says 'Call once at session start' and mandates that band arguments from other primitives must come from this list, providing clear when and why.

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 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?

No annotations provided, but the description fully discloses output format (GeoJSON Feature, Polygon geometry, properties list), usage context (Mapbox/Leaflet/Deck.gl/QGIS), and constraints.

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 efficient paragraphs: first defines output, second provides usage guidance. 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?

Given no output schema, description thoroughly explains return type, geometry, and included properties. Complete for a single-parameter tool.

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

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

Schema coverage is 100% and description adds minimal beyond 'cell64 or place name'. Baseline 3 is appropriate since description doesn't elaborate on accepted formats.

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

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

The description clearly states it returns a cell polygon as a GeoJSON Feature with specific properties, distinguishing it from siblings like emem_recall_polygon.

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 (map overlays, polygon-clipping ops) and provides an alternative REST endpoint for related but different functionality.

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

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

No annotations provided, but description fully discloses pipeline (STAC search, COG reads, percentile stretch, PNG encode), output format (ImageContent), dimensions, and structuredContent details. Also explains behavior under high cloud cover.

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

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

Well-structured with clear sections: purpose, technical details, usage guidance. Some redundancy (e.g., '256×256 px' repeated), but overall efficient and front-loaded.

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

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

No output schema, but description covers return (ImageContent, structuredContent) and all parameters thoroughly. Includes edge cases and practical tips.

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 significant value: explains cell as cell64 or place name, max_cloud advice for tropics, datetime as RFC 3339 interval with default. Exceeds baseline.

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

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

Clearly states 'True-colour Sentinel-2 L2A RGB thumbnail centred on a cell' and distinguishes from siblings like emem_cell_geojson by specifying visual nature. Uses specific verb and resource.

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?

Dedicated 'When to use' section with example queries and context for cloud cover and datetime. Does not explicitly mention when not to use, but provides strong positive guidance.

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

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

No annotations exist, so description carries full burden. It discloses output: 'Returns a single cosine score and per-band deltas.' However, it does not mention any side effects, authorization needs, or whether the operation is read-only. For a comparison tool, this is acceptable but not comprehensive.

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

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

The description is two sentences followed by a usage note, all front-loaded with the core purpose. Every sentence adds value with no superfluous text. Highly efficient.

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

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

Given no output schema, the description clearly explains the return format (cosine score and per-band deltas). With only three simple parameters and a well-defined operation, the description is fully adequate 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 covers 100% of parameters with descriptions. The description adds no extra semantics beyond the schema; it only restates that it works 'over shared vector bands' which is already implied by the function. 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 'Compare two cells: cosine similarity over shared vector bands + per-band scalar deltas.' This specifies the verb (compare) and resource (cells) with precise mathematical operations, distinguishing it from siblings like emem_compare_bands or emem_find_similar.

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 with example user queries: 'how similar is X to Y', 'compare these two places', or wants a difference vector. While it doesn't mention alternatives or when not to use, the positive 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?

With no annotations, the description carries full burden. It details the return value (signed receipt with source fact CIDs) and explains predicate behavior (verdict). It does not mention side effects, auth needs, or rate limits, but those are less applicable for a read-only comparison tool.

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

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

Two concise paragraphs: first defines the tool's functionality, second provides usage scenarios and defaults. No redundant or unclear sentences; every sentence adds necessary context.

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 (6 parameters, nested objects, no output schema), the description adequately explains the comparison types and return format. It covers the key use cases and edge cases (e.g., tslot defaults), though a brief note on error conditions 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%, yet the description adds value by explaining comparison logic (scalar vs vector, metric choices) and default tslot behavior beyond the schema's parameter descriptions. It also clarifies how the predicate affects the response.

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 it compares two bands at the same cell, distinguishing scalar and vector pairs, and explicitly ties to use cases like cross-source consistency and cross-vintage drift. This provides a specific verb+resource and differentiates it from general compare or diff 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 states when to use (cross-source consistency, cross-vintage drift, band-vs-band comparison) and notes required parameters and defaults. However, it lacks explicit guidance on when not to use or 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?

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?

With no annotations, the description carries the full burden. It discloses output format, dimensions, log-scale, and multi-content-block reply, but does not mention latency, caching, or auth needs.

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

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

The description is front-loaded with the main purpose and structured into paragraphs. It is slightly verbose with technical details like dimensions and mime type, but overall well-organized.

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

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

Despite no parameters and no output schema, the description is comprehensive: it covers purpose, usage triggers, output format, dimensions, and an alternative retrieval method. It is sufficient 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 input schema has zero parameters, so baseline is 4. The description adds value beyond the schema by explaining the output and use case, which is sufficient.

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

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

The description clearly states the tool returns a live SVG render of corpus density as an EmbeddedResource, and it distinguishes from siblings like emem_coverage_matrix by focusing on a visual coverage map.

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 call it (e.g., 'where do you have data?') and provides an alternative REST endpoint for bare bytes, but does not contrast with similar sibling tools like emem_coverage_matrix.

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

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

With no annotations, description fully reveals behavior: returns fields like has_materializer (auto-fetch+sign capability), facts_count (cached cells), last_attested_unix_s (freshness). Explains implications of false materializer and zero facts. 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, front-loaded with purpose. Each sentence adds unique value: purpose, usage guidance, return field semantics. 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, so description must cover return values, which it does thoroughly. With zero parameters, description is fully 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?

Input schema has zero parameters, so baseline is 4. Description adds no parameter info, but none 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?

Description states 'Per-band live status — the canonical what data is alive AND auto-materializable probe.' It uses a specific verb+resource ('probe'), and distinguishes from siblings like emem_recall and emem_materializers by clarifying its role as a preliminary check.

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 advises 'Call BEFORE emem_recall when you don't know which bands answer at this responder.' Also tells when not to use a band: 'don't bother recalling' if has_materializer=false and facts_count=0. Provides clear context for decision-making.

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?

No annotations are present, so the description must cover behavioral traits. It mentions the return type (signed DerivativeFact + receipt) and content-addressed nature, but does not disclose whether the operation is read-only, destructive, or what permissions are needed.

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?

Extremely concise: two sentences plus a usage directive. Every sentence adds value and the key action 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 annotations and output schema, and 0% parameter coverage, the description is insufficient. It lacks details on input formats, parameter constraints, and a fuller explanation of the return value.

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

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

Schema coverage is 0%, and the description adds no information about the parameters (cell, band, tslot_a, tslot_b) beyond their names. The user cannot infer what these parameters mean from the description.

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

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

Clearly states it computes a DerivativeFact (delta) between two tslots for a band. The verb 'compute' and resource 'delta between band values' are specific. However, it does not explicitly distinguish from siblings like emem_compare, which might also compute differences.

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 phrases: 'what changed between t1 and t2' and 'give me the delta'. However, it does not mention when not to use or suggest alternatives such as emem_compare.

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 explains fusion logic (Cop-DEM for land, GMRT for water) and that a coherence_note is returned when surfaces disagree. Annotations already provide readOnlyHint, etc., but description adds valuable 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?

Two short, front-loaded paragraphs. First explains what it does, second gives usage guidelines. 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, description covers return fields (elevation_m, source, coherence_note) and explains fusion logic, parameter options, and when to use. Completely adequate for an agent to invoke correctly.

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

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

Schema has 100% coverage with descriptions. Description clarifies parameter groups (place, lat+lng, or cell) as mutually exclusive options, adding meaning 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 fuses three datasets into a single elevation value, specifying the verb 'returns' and the resource 'elevation across Cop-DEM, GMRT, WorldCover'. It distinguishes from sibling emem_recall by noting it handles land/water/coast automatically.

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' for elevation queries, and 'Otherwise, prefer emem_recall' with specific band names. This clearly differentiates 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?

With no annotations, the description must cover behavior. It implies a read-only, stable operation but does not detail idempotency, rate limits, or output specifics. For a simple catalog, this is adequate but minimal.

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 sentences, front-loaded with the purpose and directly stating when to use. 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 tool with no output schema or annotations, the description could mention the format of the error codes. However, 'catalog' implies a list, which might be sufficient for an LLM to understand the 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?

Input schema has 0 parameters, so schema coverage is 100%. The description does not need to add parameter information, meeting the baseline for 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 clearly states it is a 'Stable error code catalog' and explains it enumerates wire-stable error codes. This sets it apart from sibling tools like emem_functions or emem_schema, which deal with different resources.

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

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

Provides explicit guidance: 'use when the LLM wants to programmatically branch on responses.' This is clear context for usage, though it doesn't specify when not to use, which is acceptable given its unique purpose.

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?

Adds substantial behavioral context: forest definition, data sources, fallbacks, and explicitly states what is out of scope (legality). 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?

Comprehensive but not verbose; front-loaded with purpose and structured logically. Could be slightly more concise but maintains clarity.

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

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

For a complex regulatory tool with no output schema, description covers purpose, usage, behavioral details, and parameter semantics sufficiently.

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 meaningful context like geometry type rules (Polygon/Point based on size and cattle exemption) and cut-off date semantics. Schema coverage is 83%, so baseline 3, but description adds extra 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?

Specific verb+resource: 'Produce a Due Diligence Statement' for one or more plots. Clearly differentiates from siblings (no other EUDR 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?

Explicit usage context: 'Call when a commodity supplier or EU importer needs to evidence due diligence.' Also provides batching guidance and mentions pairing with legality module. Lacks explicit 'when not to use' but 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 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?

No annotations exist, so the description must fully disclose behavior. It explains k-NN search and default band, but does not mention whether the operation is read-only, any authentication or rate limit requirements, how results are ordered, or what the output contains (e.g., list of cell64s with similarity scores). Some behavioral traits remain opaque.

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

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

The description is extremely concise: two sentences plus a 'When to use' section. Every sentence is meaningful and adds value without redundancy. Information is front-loaded with the core action.

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

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

The description covers the essential use case and parameter variations. With no output schema, it might benefit from mentioning the return format (e.g., list of similar cell IDs or scores), but the current description is adequate for an agent to understand invocation. The complexity is moderate, and the description handles the key aspects.

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 67% (key and band have descriptions; k lacks a description but has min/max/default). The description adds value by explaining the 'inline:...' syntax for the key parameter and clarifying the default band as '128-D Tessera foundation embedding', which is not fully captured in 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 performs k-NN search over a corpus by cell embedding or inline vector to find similar places. It uses a specific verb ('find similar') and resource ('embedding'), and its purpose is distinct from sibling tools like emem_query_region or emem_locate.

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

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

Explicitly provides a 'When to use' section with example user queries, which helps the agent identify appropriate invocation scenarios. It does not explicitly state when not to use or list alternatives, but the guidance is clear enough for most 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 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, idempotentHint, and openWorldHint, but the description adds behavioral context by explaining what each dataset offers (e.g., 'Hansen gives year-of-loss for any cell with disturbance since 2001'). This goes beyond the 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 two short paragraphs: the first states purpose, the second gives usage guidance. Every sentence is relevant and no information is redundant. It is front-loaded and easy to scan.

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 fails to explain the output format, which is critical for a retrieval tool with no output schema. It does not mention whether both datasets are always returned or if the user can select specific bands. Given the complexity of the tool (two datasets, multiple parameters), this is a notable 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%, so baseline is 3. The description does not add forest-specific meaning to parameters like 'band' or 'n_cells'; it only mentions the overall data sources. No additional value is provided to clarify how parameters interact with the forest data.

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: 'Recall forest signals at a place', specifying the exact datasets (Hansen GFC and ESA WorldCover) and the kinds of data they provide (tree cover baseline, year-of-loss, land class). This distinguishes it from siblings like emem_water or emem_weather which address other domains.

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

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

Includes a 'When to use' section that lists explicit triggers: user asks about deforestation, canopy cover, forest loss, or forest-vs-not classification. While it does not specify when not to use or name alternatives, the provided guidelines are clear and context-appropriate.

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

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

No annotations provided, so the description must cover behavioral traits. It states it is a 'registry' (suggesting read-only), but does not explicitly confirm lack of side effects, cost, or access requirements. The description adds moderate value beyond the empty schema.

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

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

Two sentences with no padding. The first sentence defines the tool, the second gives usage guidance. Every word earns its place.

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

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

Given zero parameters and no output schema, the description adequately covers the tool's purpose and usage. It doesn't describe the return format, but for a registry listing, that is often self-evident.

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 no parameters, and the description does not need to document any. Baseline 4 is appropriate since no extra parameter information is necessary.

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 specifies it is an 'active function registry (derivation recipes)' and clarifies its use for listing available derivative ops for emem.diff or understanding band computation origins. This is specific but could be more precise about the exact output.

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

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

Explicit 'When to use' guidance tells the agent exactly when to invoke this tool: to determine which derivative operations are available for emem.diff or how a band is computed. This directly addresses the decision between siblings.

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

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

No annotations provided, but the description discloses that the tool returns actual ground resolution and spec target, and implies it is lightweight (call once). No destructive or side-effect behavior, so it is transparent enough for this simple info tool.

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

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

Extremely concise: two sentences plus a 'When to use' paragraph. Every sentence adds value, with no redundant information. 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?

Given no parameters and no output schema, the description provides sufficient context: explains return values, typical usage scenario, and relationship to sibling tools. Complete for the agent to understand when and why to invoke this tool.

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

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

No parameters in input schema (100% coverage by default). The description adds meaning about what the tool returns, which compensates for the lack of parameter details. 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 the tool returns grid encoding details: cell64 ground resolution, lat/lng axis sizes, and DGGS lineage. It specifies the actual resolution values, distinguishing it from sibling tools like emem_cell_geojson or emem_recall_polygon.

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: at session start or when user asks about cell resolution. Also mentions an alternative (emem_recall_polygon) for cases needing more than one cell, providing clear decision criteria.

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

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

The description adds substantial behavioral details beyond annotations: mentions cold/warm performance (~5s cold, ~30ms warm), materialization of 9 MODIS facts on miss, citation of input fact CIDs, and CFL-stable timestep. Annotations already declare idempotent and read-only, and description aligns fully.

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 a technical definition followed by usage guidance. It is slightly verbose but each sentence adds value. Could be more compact, but 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?

Input parameters are fully covered with rich context. Output description is minimal ('returns a signed forecast') and lacks detail on the return format or meaning of the sign. Given no output schema, a bit more 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%, but the description enriches each parameter: ‘diffusivity_m2_per_s’ gets practical values for different surfaces (vegetation, water), ‘hours_ahead’ gets the cap explanation, and ‘cell’ gets context. This goes well 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 defines the tool as a 2-D finite-difference solver for the heat equation applied to urban LST evolution. It distinguishes itself from siblings by emphasizing 'Real PDE rollout — not a decay-scoring heuristic', and specifies the exact science domain and method.

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 scenarios: short-horizon LST forecasts at a specific cell, with guidance on diffusivity values and horizon caps. It lacks explicit 'when not to use' or alternative tools, but the context is clear enough for correct 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 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?

With no annotations provided, the description carries the full burden but only states it submits an intent and receives a plan/result. It does not disclose side effects, auth needs, rate limits, or failure behavior. Missing critical behavioral details.

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, front-loaded with the core purpose, and then a concise usage guideline. 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 complexity (10 params, nested objects, no output schema, no annotations), the description is severely incomplete. It provides no parameter examples, output format, or mapping of intent types to parameters.

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

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

Schema description coverage is 0%. The description adds no meaning to any of the 10 parameters beyond their names and types in the schema. No explanation of how parameters like 'a', 'b', 'k' relate to intent types.

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 'Submit' and resource 'typed Intent', and distinguishes from siblings by indicating it's for when you don't want to pick a primitive yourself, with the planner mapping intent variants to the right tool call.

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 example queries and clarifies that it's for when you don't want to pick a primitive tool, implying alternatives (the sibling tools) exist for direct calls.

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?

Adds significant detail beyond annotations: fixed coefficients from literature, formula y_{t+1} = α*(lag-12 NDVI or recent_mean) + β*(last+slope) + γ*recent_mean, clamping to physical range, and citing input CIDs. Annotations already indicate safe read, but description enriches with exact operational 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?

Front-loaded with key action, method, and formula. Followed by concise 'When to use' section and error handling. Every sentence adds value without redundancy. Efficiently packaged for agent consumption.

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

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

Covers purpose, internal algorithm, parameter details, error conditions (422), chaining to emem_backfill, and future v2 plans. Despite no output schema, description clarifies return value (clamped prediction with lookback_months_used) and fact citation, making invocation safe.

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 meaning beyond schema: e.g., lookback_months will use fewer months if insufficient data and surfaces lookback_months_used; band is limited to indices.ndvi in v1; forecast_horizon_months locked to 1. Schema coverage is 100%, but description gives execution semantics.

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

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

The description clearly states the tool predicts next-month NDVI at a cell using a constrained JEPA-pattern AR(2) seasonal predictor, with specific verbs and resource. It distinguishes from sibling tools like emem_fetch and emem_backfill by focusing on prediction, not retrieval.

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 (one-month-ahead forecast for crop-stress, growing-season tracking) and when not to use (no history, chain to emem_backfill). Mentions return 422 for missing history, providing clear context for 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?

Adds significant behavioral details beyond annotations: reads K=3 recent vintages, uses ONNX model, returns receipt with model block and honesty_warnings, and explains the error condition. 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 the most important information upfront. Could be slightly more concise, but 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?

Covers all aspects: model details, input requirements, error handling, and return structure (receipt with model block), despite no output schema.

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

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

Schema description coverage is 100% and already clear. The description does not add additional information 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 verb (predict), the resource (next-vintage 128-D Tessera embedding), and distinguishes from sibling v1 (embedding vs NDVI scalar).

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 (forecast in embedding space) and when not (cell has <3 consecutive vintages), and hints at alternatives (v1 for 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?

With no annotations, the description carries full burden. It reveals behavioral traits: the responder fetches data on demand (Sentinel, CopDEM, etc.), the response structure has three sub-fields, and it advises to report 'declared_but_no_materializer' honestly. No contradictions with missing 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 dense but efficient, front-loading purpose and usage. Every sentence adds value, though it could be slightly more structured. It remains concise given the tool's complexity.

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

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

Given no output schema, the description thoroughly explains the response structure (three sub-fields). It covers all parameters, usage context, and mentions sibling emem_ask. It is complete for the tool's functionality.

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%, but the description adds value beyond schema by explaining parameter usage: lat/lng are paired, place is free-text, and it gives examples like 'deictic' and 'here'. This extra context justifies a slightly above-baseline score.

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

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

The description clearly states the tool's purpose: 'Resolve any place mention to a cell64 AND return the topic-grouped inventory of every fact knowable about that location'. It uses specific verbs and resources, and distinguishes from siblings by contrasting with emem_ask for the single-shot path.

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 'When to use' trigger: 'any time the user mentions a real-world location', with examples including 'place name, address, lat/lng, deictic'. It also instructs to call this BEFORE answering, web_search, or using certain refusal phrasings, and contrasts with emem_ask.

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 cover safety (readOnly, idempotent). The description adds behavioral context: the tool returns both day and night fluxes, uses MODIS 1 km 8-day composites. This is valuable but does not contradict annotations.

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

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

The description is very concise: three sentences total covering purpose, context, and usage. It front-loads the key information and avoids extraneous content.

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

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

While the tool has 100% schema coverage and annotations, there is no output schema and the description does not explain what the output contains (e.g., format, fields). For a data retrieval tool, this is a moderate gap, but the tool is still understandable.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add new parameter details beyond the schema, but the schema itself is well-described. No additional semantics 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 the tool recalls MODIS land surface temperature composites, specifying day and night, resolution, and composite period. It also mentions specific use cases like urban heat island and thermal anomalies, which distinguishes it from sibling tools.

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

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

The description explicitly provides a 'When to use' section listing concrete scenarios (surface heat, urban heat island, thermal anomalies, day/night LST). It also explains the advantage of getting both day and night fluxes for deriving spread.

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

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

No annotations are provided, so the description carries full behavioral disclosure burden. It indicates a read operation (getting CIDs) with no side effects, but does not explicitly state it is safe/idempotent or mention permissions or rate limits.

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

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

Two short sentences with no wasted words. The key output and usage guidance are front-loaded.

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

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

For a parameterless tool without output schema, the description adequately specifies what is returned and why to use it. It could add detail about the format (e.g., list or object) but is otherwise 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 no parameters (100% coverage), so the description adds value by explaining the returned content (CIDs for bands, functions, sources, schema) 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 'Active manifest CIDs' and lists the categories (bands, functions, sources, schema). It distinguishes from sibling tools like emem_bands, which likely return data rather than CIDs. However, it could use a more direct verb like 'Get' or 'List'.

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 to learn which exact registry versions a responder is serving' and advises citing CIDs for reproducibility. This provides clear context but lacks mention of when not to use 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?

No annotations are present, so description bears full burden. It describes the response structure including an agent_hint block with trust model and absence-fact contract, but does not explicitly state that the operation is read-only, idempotent, or has no side effects. It also does not mention caching or staleness considerations.

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 paragraphs with a clear first-sentence summary followed by usage and content details. 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 zero parameters, no output schema, and a moderate complexity tool, the description fully covers the output fields and includes an agent_hint explaining the trust model. For a registry-fetch tool, 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?

The input schema has zero parameters and 100% schema description coverage, so baseline is 4. The description adds value by detailing the output fields (upstream_scheme, upstream_endpoint, etc.) and the agent_hint block, which helps the agent understand the response structure.

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

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

The description starts with a clear verb phrase 'Auto-fetch registry' and specifies exactly what is returned: bands, provider, license, value shape. It distinguishes itself from siblings like emem_bands and emem_coverage_matrix by focusing on materialization and provider details.

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: Call once at session start' and lists companion tools (emem_bands, emem_coverage_matrix). It also provides example user queries that would trigger this tool, giving concrete 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 indicate read-only and idempotent behavior. The description adds validation details and token format, which is consistent and adds 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 core function, and includes a separate usage paragraph. 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?

For a simple compositional tool with two well-described parameters and annotations indicating safety, the description fully covers purpose, usage, and pairing. No output schema is needed.

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 clear descriptions. The description adds the token format and reiterates the separator constraint, providing useful 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 description clearly states it composes a specific citation handle format (memt:<cell64>:<fact_cid>), with validation of components. This distinguishes it from siblings like emem_verify_receipt and other tools.

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

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

The description explicitly states when to use: for a single rebindable string to cite a place and attested fact across messages, and recommends pairing with emem_verify_receipt. It provides clear context 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 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, it discloses auto-materialization on miss and default 16-cell fan-out for polygon-resolved places, which are key behavioral traits.

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

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

Two concise sentences for purpose and a separate paragraph for usage—no wasted words, 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 7 parameters, no output schema, and annotations, the description covers purpose, usage, behavior, and parameter defaults, making it fully adequate.

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

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

Schema coverage is 100% so baseline is 3; description adds value by explaining default n_cells behavior and aggregation, earning a 4.

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

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

The description clearly states it recalls Sentinel-2 NDVI at a point or place, composes multiple steps, and is polygon-aware, distinguishing it from siblings 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?

Explicitly states when to use (user wants NDVI at a place) and when not (multi-band batches), and directs to alternative emem_recall.

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

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

No annotations, so description must cover behavior. It discloses aggregation option but omits details like return format, performance, or permissions. Adequate but not comprehensive.

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

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

Two efficient sentences plus a usage guideline. Front-loaded with core purpose, 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?

Lacks details on output format or constraints like limits. For a query tool, more behavioral context would help, but the usage guidance partly compensates.

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 meaning beyond schema by explaining geometry as single cell or list of cells and aggregation usage. However, the 'bands' parameter lacks description in both schema and text, reducing coverage.

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

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

The description clearly states the tool queries facts over a region, with optional per-band aggregation. It uses a specific verb-resource combination and distinguishes from siblings by focusing on region-level summary.

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 and aggregation example. However, does not mention when not to use or suggest alternative tools 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?

Details auto-materialization process, response content (materialize_notes), and interpretation of empty results; lacks info on auth, rate limits, or error handling.

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?

Informative and well-structured, but slightly verbose; front-loaded with key 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?

Thoroughly covers recall behavior, materialization, response interpretation, and usage sequence, making it self-contained for an agent.

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

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

Schema coverage is 100%; description adds usage context and examples for each parameter, enhancing clarity 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?

Clearly states 'Recall facts about a cell' with automatic materialization, distinguishing it from sibling tools like emem_recall_polygon and emem_locate.

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 advises use after emem_locate or with known cell64, and explains materialization behavior, but does not explicitly state when not to use or list 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 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?

With no annotations, the description fully carries the transparency burden. It discloses key behaviors: fanning out across polygon, using geocoder, returning merged_facts and by_cell, and a polygon_bbox.source indicator that distinguishes real polygon from fallback. This provides sufficient insight for an agent to understand side effects and return structure.

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 very concise: three short paragraphs that front-load the purpose, then provide usage guidance, and finally explain return values. Every sentence adds value, with no filler or repetition. It is well-structured for quick consumption by an AI agent.

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

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

Given the tool's moderate complexity (5 parameters, nested objects, no output schema), the description covers input modes, behavior, and output structure. It explains return fields (merged_facts, by_cell, polygon_bbox.source) and fallback scenarios. Minor gaps: no mention of tslot semantics or error handling, but overall sufficient for an agent to invoke correctly.

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

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

Schema description coverage is high (80%), so baseline is 3. The description adds context about place resolution and polygon_bbox alternatives but does not provide additional semantic details beyond what's in the schema for bands or tslot. The added value is moderate; it does not compensate for the low coverage of the one undocumented 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 action: 'Recall facts across every cell inside a place's polygon'. It explicitly differentiates from sibling tools like emem_recall by emphasizing polygon fan-out instead of single cell, and solves a specific problem ('place-name-drift gap for wide features'). The verb 'recall' plus resource 'polygon' makes purpose unambiguous.

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

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

The description includes a dedicated 'When to use' section, specifying conditions like 'user names a wide feature ... where one cell is too small'. It explains two input modes (place or polygon_bbox) and mentions fallback behavior. However, it does not explicitly state when NOT to use the tool (e.g., for point features), which would strengthen guidance.

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

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

No annotations are provided, so description carries full burden. It indicates the tool returns a schema bundle, which is likely read-only, but does not mention any behavioral traits like idempotency or data retrieval specifics. Adequate for a simple retrieval tool.

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

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

Two concise sentences with no wasted words. The purpose is front-loaded, and the usage guidance follows directly. Perfectly structured for quick understanding.

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, no output schema, and a simple purpose, the description is largely complete. It explains the tool's nature and usage context, though it assumes knowledge of 'CID' and does not detail output format.

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 in the input schema, so schema coverage is 100% by default. The description does not add parameter information, which is acceptable; baseline score of 4 applies for parameter-less tools.

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

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

Description clearly states the tool provides an 'Active CDDL/JSON schema bundle by CID,' specifying the resource type and identifier. This distinguishes it from sibling tools which focus on other operations like attestation or verification.

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 notes 'Rarely needed at chat time' and 'Useful for offline verification of receipts/attestations,' providing clear context for when to use the tool. Does not name specific alternatives but implies the tool's specialized role.

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 behavioral context beyond annotations, stating that six bands are returned in one envelope. It does not contradict the readOnlyHint, openWorldHint, or idempotentHint annotations. No additional behavioral traits are disclosed, but the annotations already cover safety.

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, consisting of two sentences plus a usage guideline. Every part is useful and front-loaded with the core 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?

Given no output schema and multiple parameters, the description provides a reasonable overview of what the tool returns (six bands) and how to specify input (place or lat/lng). It lacks details on output structure but is sufficient for basic understanding.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add new meaning beyond the schema, as it only broadly refers to 'a place' and mentions six bands, which is already implied by the default band set 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 identifies the tool as recalling a SoilGrids 250 m profile for soil attributes (SOC, pH, texture) at a location. It is specific about what data is returned but does not explicitly differentiate it from sibling tools like emem_water or emem_forest.

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 that gives clear context, such as soil quality or agricultural suitability queries. However, it does not mention when not to use the tool or suggest 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?

No annotations provided, so description bears full burden. It describes the tool as a registry (read-only) and lists content types, but does not disclose authorization needs, rate limits, or whether it returns a list or single item. For a simple read-only tool, this is adequate but not rich.

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 sentences with front-loaded definition and immediate usage guidance. No unnecessary words; every sentence adds value.

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

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

Given no parameters, no output schema, and low complexity, the description is mostly complete. It explains what the tool does and when to use it. However, it lacks detail on the output format (e.g., list of provider names with metadata), which could help agents process the result.

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 (100% schema coverage), so baseline is 4. The description adds context about the registry's content (URL templates, providers, licenses), which goes beyond the empty schema, but it does not affect parameter semantics directly.

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 identifies the tool as an 'Active source-connector registry' listing URL templates, providers, and licenses. The sibling tools are diverse and none are about sources, so it distinguishes well. The 'When to use' further clarifies the purpose: inspecting which EO providers are wired.

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 call the tool: 'when you need to inspect which upstream EO providers are wired.' It also gives a specific use case (license attribution). While it does not mention when not to use it, the narrow scope makes exclusions unnecessary.

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, non-destructive. Description adds critical context: return includes coverage and extras, distinguishes attested-zero from not-yet-materialized, and notes that materialize=true can trigger many fetches on a cold cell.

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, front-loading purpose and views, then usage, then pairing. Each sentence adds value. Slightly long but not wasteful; concise for the complexity.

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

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

For a tool with 6 params, no output schema, and complex behavior, the description covers the two views, response semantics, default values, and paired tools. It explains corner cases (extras, coverage, materialization cost). Complete and informative.

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% coverage, baseline 3. Description adds value by explaining the meaning of encoder bands, cube response structure (coverage/extras), and the effect of materialize flag, going 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 it returns a dense state vector for a place with two views (encoder and cube), using specific verb 'read' implied. Distinguishes from siblings by naming paired tools like emem_find_similar and emem_compare.

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: for downstream tasks or getting a handle. Provides default view and conditions for each view. Mentions pairing with specific siblings. Lacks explicit when-not-to-use, but overall guidance is strong.

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, non-destructive behavior. The description adds that tslot_a and tslot_b must differ, default encoder is geotessera, and explains the specific outputs (per-element residual, L2 norm, cosine, source CIDs). 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?

Two sentences, front-loaded with key output information, no fluff. Every sentence adds value.

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

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

Given moderate complexity and no output schema, the description adequately covers what the tool returns, when to use it, and how to distinguish from alternatives, making it self-contained.

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

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

Schema description coverage is 75%; the description reinforces defaults and constraints already present in the schema (e.g., encoder default, tslot difference) but does not add new semantic meaning 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 'Vector delta between the same cell at two tslots' and lists specific outputs (residual, L2 norm, cosine, CIDs). It distinguishes itself from the sibling tool emem_diff, which is for per-band scalar changes.

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 ('when the user asks how much did X change between A and B for a foundation embedding at one place') and provides an alternative (use emem_diff for per-band scalar change).

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=false, establishing safe, read-only behavior. The description adds crucial details: independent encoder attempts with graceful failures reported as 'missing' with typed reasons, which goes beyond 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?

Both paragraphs are concise and front-loaded: the first describes core behavior, the second gives usage guidance. Every sentence adds value, with no redundant or filler content.

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

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

Given the tool's complexity (multi-encoder fan-out with independent attempts) and the presence of annotations, the description covers behavior well. However, it lacks details about the return structure beyond 'structured per-encoder state map' and 'missing' field. Since there is no output schema, slightly more explanation of the response format 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 33% (only encoders has a description). The description adds context for 'cell' (one cell) and encoders (default set), but does not explain the 'tslot' parameter at all. With low schema coverage, more parameter-level detail in the description would improve this dimension.

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 fans out across multiple foundation-embedding encoders for a single cell and returns a per-encoder state map. This distinguishes it from siblings like emem_state (single encoder) and emem_state_diff, making its purpose unambiguous.

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

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

The description includes an explicit 'When to use' section listing three specific scenarios (cross-encoder consensus, redundancy-aware reasoning, concatenated state for linear probes) and provides guidance on overriding default encoders. This clearly signals appropriate contexts.

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, so the tool is safe and idempotent. The description adds that the plan is 'deterministic and verifiable' and mentions citing algorithm key, providing useful 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?

Two tight paragraphs with no redundancy. The first sentence clearly states the action, and the usage section is efficient. Every sentence adds value.

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

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

For a planner tool with no output schema, the description adequately explains the output (concrete plan with bands, lookback windows, purpose tags). The context of being used before emem_recall is clear, and sibling tools are distinct.

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 parameters are well-documented. The description adds that the 'intent' parameter drives recipe selection with examples (e.g., 'flood_window'), but this is modest extra value. 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 function: walking algorithm registry's temporal_recipe blocks to produce a concrete plan with bands, lookback windows, and purpose tags. It differentiates from siblings like emem_recall by noting it is used before a multi-band recall for time-shaped questions.

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: when the user question references a TIME relationship and the assistant wants to assemble the lookback recipe rather than reasoning about offsets. It hints at not using it for non-temporal questions, though it does not list 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 readOnlyHint true and destructiveHint false. The description adds context about returning three blocks and being a single source of truth, which is valuable 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 informative but somewhat lengthy. It starts with the core purpose and then adds details. Could be slightly trimmed but remains 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?

No output schema, but the description explains the three return blocks and their purpose. It covers what the tool returns and when to use it, making it 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, so the description doesn't need to explain parameters. Baseline for zero parameters is 4.

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

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

The description clearly states it is a 'Topic-grouped registry of every band and algorithm'. It distinguishes from siblings by specifying it's for when the user hasn't named a specific band, and references other tools like emem_algorithms.

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 when the user's question lives in a topic but they haven't named a specific band' with examples. It also advises to browse here before inventing formulas, providing clear guidance 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?

With no annotations, the description fully discloses behavior: returns only already attested facts, does NOT trigger materialization, explains typical behavior for fast-tempo bands (one point), and clarifies tslot constraints (non-negative u64, no negative offset).

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 core purpose, then provides usage guidelines and important behavioral differences in a well-structured, dense paragraph. Every sentence adds essential information without redundancy.

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

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

Given the tool's complexity (3 required params, no output schema, no annotations), the description thoroughly covers purpose, usage context, behavioral transparency, parameter implications, and acknowledges output behavior (returns attested facts). No gaps remain for correct agent selection and invocation.

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

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

Schema description coverage is 33% (only window has description). The description does not add new meaning for cell and band beyond their names; for window it reaffirms the inclusive range but adds no extra semantics. Baseline for low coverage expects more elaboration, which is missing.

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 time series for one (cell, band) over an inclusive tslot window, and explicitly distinguishes it from sibling tool emem_recall by noting it does NOT trigger materialization.

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 specifies when to call ('user asks how did X change over time' for a band with multiple historical tslots), when not to call (for long-term history prefer static summary bands), and provides alternatives: accept latest snapshot, wait for seeding, or commission backfill via emem_intent.

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

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

No annotations provided, so description carries full burden. Mentions return values but omits behavioral traits like read-only status, authentication, rate limits, or side effects. Lacks critical transparency for a verification tool.

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

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

Two sentences plus usage guidance are concise and front-loaded. No unnecessary words, but could benefit from more structured listing of returns.

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, nested parameters, and no annotations, description fails to fully specify tool behavior. Missing parameter explanations, error handling, and verdict format.

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 does not explain any parameters. Despite complex nested objects (claim, cell, mode), no guidance on their meaning or usage.

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

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

Description clearly states the tool verifies a structured claim against a cell's facts, distinguishing it from siblings like emem_ask and emem_compare. The verb 'verify' and resource 'claim against cell facts' are specific.

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

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

Explicitly states when to use: for yes/no questions about cells or when citable evidence is needed. Does not mention when not to use, but 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?

Annotations already indicate readOnly, idempotent, and non-destructive. Description adds substantial behavioral details: recomputes preimage, runs ed25519, returns specific fields, tolerates both byte[] and b32 formats, and never returns 4xx for structurally valid bad signatures. 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 well-structured: starts with purpose, then usage guidance, then behavioral details. Every sentence contributes information. It is not overly verbose considering the complexity of the verification process, though it could be slightly more concise without losing clarity.

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

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

Despite having no output schema, the description completely covers input requirements, process (preimage computation, ed25519), output fields (valid, reason, pubkey_b32), and error handling (returns valid: false for bad signatures, never 4xx). The tolerance for different parameter shapes is also explained. This is highly complete for a verification 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?

Input schema has 100% coverage with descriptions for both parameters. The description adds meaning by explaining the receipt structure requirements (must carry primitive/served_at/request_id/cells/fact_cids and either signature+responder_pubkey or b32 equivalents) and that pubkey_b32 is an optional override. This provides context beyond the schema's generic 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 explicitly states the tool verifies a signed receipt envelope server-side by recomputing the canonical preimage and running ed25519. It clearly identifies the verb (verify), the resource (receipt), and the specific algorithm (ed25519). This distinguishes it from many sibling tools that likely perform other data operations.

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

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

Provides explicit use cases: when in-browser /verify path is blocked or for server-side audit. Also explains what happens on bad signature (200 with false, not 4xx). However, it does not compare to sibling tool 'emem_verify' or specify when not to use this tool, lacking full differentiation.

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 the tool as read-only, idempotent, and non-destructive, which clarifies safety. The description adds value by noting the tool pairs two sources and can detect through clouds, but does not elaborate on other behaviors like response format or rate limits. This meets the baseline with modest additional 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 short (two sentences plus a usage paragraph) and front-loaded with the core verb and resource. Every sentence serves a purpose, with no fluff. The structure is clean and easy to scan.

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 7 parameters, 100% schema coverage, and annotations covering safety, the description provides sufficient context for a geospatial recall tool. It explains the data sources and use cases. The lack of an output schema is acceptable per rules, and the description is complete enough for typical 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?

With 100% schema description coverage, the input schema already documents all parameters meaningfully. The tool description does not repeat or augment parameter details, so it adds no value beyond the schema. Baseline score 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 the tool recalls surface-water signals using two specific data sources (JRC GSW recurrence and Sentinel-1 SAR backscatter) and explains their combined benefit (detecting standing water through clouds). This distinguishes it from sibling tools like emem_forest or emem_fetch, as it is uniquely focused on water detection with both historical and current data.

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

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

The description includes an explicit 'When to use' section listing use cases (flooding, wetlands, surface-water dynamics) and explains the roles of the two data sources. It lacks explicit 'when not to use' guidance or comparison with sibling tools, but the provided context 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.