emem — Earth memory protocol

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

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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 the tool is read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it uses a CFL-stable timestep, samples GMRT depth along a seaward gradient, and cites depth fact CIDs. It also clarifies that a 422 is returned for land-locked cells. This goes beyond annotations, hence a 4.

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

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

The description is moderately long but well-structured with a clear purpose statement and a separate 'When to use' section. It front-loads the core function and avoids redundancy with schema. Every sentence provides useful information, though it could be slightly more concise in the technical details. Still highly 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?

With 4 parameters, no output schema, and good annotations, the description covers the return values (arrival height, time, depth, phase-speed profiles) and error handling (422 for land-locked). It explains the solver's process and references to depth CIDs. While the exact output structure isn't detailed, the summary is sufficient for an AI to understand behavior. A 4 reflects adequate completeness for this complexity.

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

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

All input parameters have descriptions in the schema (100% coverage). The description enhances understanding by providing additional context: n_offshore_cells default of 8 corresponds to 80m at 10m grid, period_s typical range 6-18s, and offshore_height_m as Hs. It also explains how depth is derived from GMRT. This adds meaningful value beyond the schema, warranting 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 explicitly states the tool solves the shallow-water wave equation to model swell propagation to a coast, returning specific profiles. It uses specific verbs and resources, making the purpose highly clear. While it doesn't contrast with siblings like emem_heat_solve, the unique physics and output are distinct enough for an AI to understand its role.

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

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

The description includes a 'When to use' section that clearly states the tool is for predicting swell arrival at a coast, applicable to storm-surge planning, shoreline-impact assessment, and surf forecasting. It also notes the error case for land-locked cells. However, it does not provide explicit when-not-to-use guidance or mention alternative tools, which would make it a 5.

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