Server Quality Checklist

Tool Scores

• emem_entity_linkA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful context: it records a 'signed equivalence' and persists into a shared reference graph that affects future `emem_entity_resolve` calls. This goes beyond the structured annotations.

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

  Conciseness5/5

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

  The description is well-structured with a clear main statement, a 'When to use' section, and a concrete example. Every sentence contributes value, and the information is front-loaded.

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

  Completeness4/5

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

  The description covers the tool's purpose, usage, effect on future resolve calls, and provides an example. It does not describe failure modes, prerequisites (e.g., the entity must already exist), or the exact return format, but given no output schema and the complexity level, it is largely complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all four parameters. The description provides a concrete example of `entity_token` and `alias` usage, but does not add significant semantic detail beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Record a signed equivalence: bind an alternate label or a stable external id ... to an existing canonical object.' It uses specific verbs and resources, and distinguishes itself from siblings by referencing `emem_entity_resolve` and the shared reference graph.

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

  Usage Guidelines4/5

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

  A dedicated 'When to use' section provides explicit use cases: learning two phrasings denote the same object or attaching an external id to an object minted from free text. It implies the effect on `emem_entity_resolve` but does not mention when NOT to use it or explicitly compare with sibling tools.

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

• emem_entity_resolveA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context: text vs near vs token modes, and that token dereferences directly to the signed entity body. 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.

  Conciseness5/5

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

  The description is concise and well-structured: a main purpose paragraph, a 'When to use' paragraph, and a helpful example. Every sentence adds value without waffle or duplication.

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

  Completeness4/5

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

  The description covers the main use cases (fuzzy text, near filtering, token dereference), gives an example, and distinguishes from siblings. It does not specify return format or error handling, but given the annotations and complete schema, it is sufficiently complete for an agent to use correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description provides an example argument object and clarifies that token bypasses search, but the schema already documents each parameter well. No significant additional semantic value is added.

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

  Purpose5/5

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

  The description clearly states the tool's action: 'Converge a fuzzy phrasing onto the canonical object' and explicitly contrasts it with re-minting, which distinguishes it from sibling mint tools. It also covers token dereference, making the purpose specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description has an explicit 'When to use' section instructing to call BEFORE minting and for token dereference, with the principle 'resolve first, mint only if nothing matches.' It provides clear context but does not name alternative sibling tools explicitly, so it falls short of a 5.

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

• emem_echo_verifyA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavior beyond these: it discloses return values (`matches` and `drift`), the degraded mode for bare cid (`degraded: true`), and the gate semantics. It does not mention rate limits or auth, but given annotation coverage, this is sufficient.

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

  Conciseness5/5

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

  The description is well-structured with a clear opening, a 'When to use' section, an example, and a documentation link. Every sentence contributes to understanding the tool's purpose and usage, with no redundancy or fluff.

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

  Completeness5/5

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

  The description covers the tool's purpose, usage timing, edge cases (bare cid, damaged citations), and return values. Given the existence of an output schema and comprehensive annotations, this description is complete for the tool's moderate complexity.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds practical meaning beyond the schema by explicitly instructing to quote `value_verbatim` as a string and explaining the bare cid behavior for the token parameter. This elevates it to a 4.

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

  Purpose5/5

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

  The description clearly states a specific action: 'Grade a value you are about to emit against the signed fact your citation points at.' It also differentiates from siblings by explaining it catches transcription errors (e.g., retyping `0.2411` for `0.241103`) that other tools in the loop do not notice.

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

  Usage Guidelines4/5

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

  The description provides explicit when-to-use guidance: 'Call immediately before publishing, logging, or handing on any value you took from an emem fact' and recommends pairing with `value_verbatim`. It does not explicitly list when-not-to-use or alternative tools, so it falls short of a 5.

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

• emem_entityA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate idempotent, non-destructive, open-world, and not read-only. The description adds valuable context beyond annotations: same name mints the same cid, external ids (GERS/OSM) dominate identity, returns a signed receipt, and it is an 'antidote to referential drift'. This gives the agent clear expectations about behavior and state changes without contradicting the annotations.

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

  Conciseness5/5

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

  Although the description is fairly long, it is well-structured with a clear purpose statement, a 'When to use' section, sibling differentiation, and an explicit example. Every sentence adds value; there is no fluff or redundancy. Front-loading the main behavior makes it easy to grasp quickly.

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

  Completeness5/5

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

  The tool has 8 parameters, nested objects, no output schema, and many siblings. The description covers return values (entity_token and signed receipt), anchor options, external-id precedence, and usage context. It also provides a concrete example. This is complete enough for an agent to select and invoke the tool correctly without additional external documentation.

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

  Parameters3/5

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

  Schema description coverage is 100%, with every parameter (label, kind, place, cell, lat, lng, parent, external_ids) already documented in the schema. The description reinforces the anchoring options and notes that external_ids dominate convergence, but it does not add significant new semantic information beyond the schema. Baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb-object pair ('Mint or get a canonical object identity') and clearly states what the tool does: gives a real-world object a content-addressed identity. It distinguishes from siblings by explicitly naming emem_entity_resolve and emem_entity_link, as well as emem_locate and emem_recall, so the agent knows exactly when to choose this tool.

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

  Usage Guidelines5/5

  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 a conversation refers to a THING...'), names alternatives with contrasting behavior (emem_entity_resolve, emem_entity_link, emem_locate), and gives clear exclusions (do not call for observations or to name a place). It also explains anchoring with place/cell/lat+lng and handing the returned token to other agents.

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

• emem_memory_tokenA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnly and idempotent behavior, so the bar is lower. The description adds meaningful context beyond that: validation rules ('non-empty and free of the `:` separator'), the output format, the alternative `:<state_cid>` form, and the link to the 'cite' operation. It does not contradict annotations; it enriches the behavioral picture.

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

  Conciseness4/5

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

  The description is front-loaded with the primary purpose and format, then structured with a 'When to use' section and detailed cost analysis. The length is justified by the need for sibling differentiation and guidance on when not to use the tool, though the cost metrics are more detailed than strictly necessary.

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

  Completeness5/5

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

  Given the presence of an output schema and strong annotations, the description is highly complete: it explains the token format, validation, usage context, alternatives, pairing with verification, and an example. It covers all key aspects of selection and invocation for a 4-parameter tool, leaving no significant gaps.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds value by specifying the validation rule that cell and fact_cid cannot contain ':', and by providing a concrete example with realistic values. It does not cover band/observed_on in the description, but the schema already documents those adequately, so this extra is appreciated but not essential.

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

  Purpose5/5

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

  The description states a clear, specific action: 'Mint a citation handle, `emem:fact:<cell64>:<fact_cid>` (or `:<state_cid>`)'. It distinguishes itself from siblings by explicitly mentioning emem_entity for objects and emem_memory_bundle for many facts, so the resource and scope are unambiguous.

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

  Usage Guidelines5/5

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

  The 'When to use' section provides explicit guidance: call when a single rebindable string is needed to cite a fact across contexts, and says to pair with emem_verify_receipt. It gives clear exclusions: use emem_entity for objects and emem_memory_bundle for many facts, and includes cost analysis to justify when this tool is the wrong choice.

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

• emem_toolsA
  4.6/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint/idempotentHint true, and the description adds substantial non-obvious behavior on top: the tool advertises only a small core loop by default so absence from a tool list does not mean absence from the server, and the ALL-CAPS warning explains that hosts strip _meta/_discovery fields so the 108 count is deliberately repeated in the description. It also discloses that catalogued tools stay callable by name through tools/call at either endpoint.

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

  Conciseness4/5

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

  Purpose is front-loaded and the When-to-use section is clearly delineated with an example, but the middle is verbose: the capslock sentence packs a real operational fact into a long, winding justification, and two sentences about catalogued tools being callable via tools/call partly repeat each other.

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

  Completeness5/5

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

  For a six-parameter discovery tool with no output schema, the description covers return shape (working-loop order, question-grouped tools, one-line triggers, full descriptor for name), the critical 108-vs-16 context trap, the tools/call mechanism, and routing to alternatives. Nothing an agent needs to invoke it correctly is missing.

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

  Parameters3/5

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

  Schema description coverage is 100% with each of the six parameters already richly documented (substring match semantics, name short-circuit, did_you_mean, category-not-safety warning). The description adds only light usage pointers — pass q for topic, name for exact schema, no arguments for the whole map — plus an example, so it stays at the baseline rather than compensating for any schema gap.

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

  Purpose5/5

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

  Opens by naming the exact job — 'The map of emem's tool surface' — and describes the concrete returns: the working loop in walk order, then tools grouped by question with one-line triggers. It distinguishes itself from siblings by naming what it is not: emem_ask for one-shot answers and the /mcp/full endpoint for a fully registered catalog.

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

  Usage Guidelines5/5

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

  Has an explicit 'When to use' section saying to call this FIRST when you don't know which tool answers or need a capability not visible in the tool list. It also states exclusions and alternatives: reconnect to /mcp/full to register the full catalog, or use emem_ask for a one-shot answer without picking a primitive.

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

• emem_find_similarA
  4.7/5.0
  Behavior5/5

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

  Annotations declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context beyond those: empty results mean no attested vector nearby rather than no similarity, nothing is materialised, and scope/as_of options force brute-force scans. This deepens the agent's understanding of side effects and result semantics.

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

  Conciseness5/5

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

  The description is well-structured with clear paragraphs covering functionality, mode details, usage guidance, and an example. It is appropriately sized for a tool with 10 parameters and complex behaviour, with the core purpose front-loaded.

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

  Completeness5/5

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

  The description covers return format (neighbours with cell64, score, band, signed receipt), empty-result semantics, mode differences, when to use, and parameter example. Given no output schema exists, this level of detail makes the description fully adequate for an agent to use the tool correctly.

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

  Parameters4/5

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

  Schema coverage is 100% with detailed descriptions for all 10 parameters. The description adds a concrete example argument, explains mode-specific tradeoffs (cosine vs hamming), and clarifies band selection for multi_year and binary variants, providing meaningful value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool performs k-NN similarity search over the corpus using cell embeddings or inline vectors, and returns ordered neighbours. The 'When to use' section explicitly distinguishes it from sibling tools by listing concrete query patterns like 'find places like X'.

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

  Usage Guidelines4/5

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

  Provides a dedicated 'When to use' section with specific user phrasings and behaviours (e.g., 'find places like X', 'where else looks like this'). However, it does not explicitly mention when not to use the tool or name alternative sibling tools, so it stops short of full exclusion guidance.

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

• emem_askA
  4.8/5.0
  Behavior5/5

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

  Despite annotations already covering readOnlyHint/destructiveHint/idempotentHint, the description adds substantial behavioral context beyond those: the server-side resolve/classify/recall chain with auto-materializing bands, the signed receipt structure at the envelope root, the caveats block surfacing grid resolution and revisit cadence, and the default slim response size (~5 KB) under MCP's 25 KB cap. It also discloses that `verbose` expands the response, and that the deterministic answer never calls a model.

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

  Conciseness4/5

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

  The description is long and information-dense, but every sentence serves a purpose: usage, parameter interplay, return structure, edge cases, and version-flavored behavior. It is front-loaded with the core purpose, though the middle section is dense and could be organized more tightly. For a tool with 11 parameters and a complex envelope, the length is justified over conciseness.

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

  Completeness5/5

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

  Given the tool's complexity — 11 parameters, a rich multi-band response envelope, fabricated facts, signed receipts, aliases, and output-size control — the description is remarkably complete. It covers parameter resolution order, opt-in heavy sections, output shape, error behaviors (unroutable model, out-of-scope question), and performance caveats (image adds 1-2 s, Cosmos 13-22 s). No output schema exists, so the description rightly carries the burden of return-value disclosure.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: how `place` is geocoded (OSM Nominatim), the mutual exclusivity of location parameters (`cell`, `place`, `lat`+`lng`), the behavior and risks of `model` (including refusal rather than silent substitution), and the distinction between `answer` and `model_answer`. It doesn't fully explain every enum value in `include`, but that's the schema's job.

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

  Purpose5/5

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

  The description opens with a specific verb+resource ('Single-shot free-text answer about a real-world location') and differentiates the tool from a manual primitive composition by describing the server-side locate → recall → algorithm chain. It clearly distinguishes it from siblings like emem_locate, emem_recall, and emem_entity by stating it returns a packaged, citation-bearing answer envelope for a specific location plus question.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use it ('Use when the question concerns a specific real-world place and a packaged, citation-bearing answer is preferable to manual primitive composition') and explains how to forward parameters ('Forward the user's question verbatim as `q` plus the location as `place`...'). It also addresses out-of-scope behavior with `topic_routing.matched_topic: null`, giving the agent clear routing guidance.

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

• emem_locateA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnly, idempotent, and destructiveHint false; the description adds valuable behavior: coordinates win over text when both are sent, aliases are accepted, and unrecognized keys are surfaced in _unrecognised_arguments rather than erroring. It also details the response sub-fields, giving transparency 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.

  Conciseness4/5

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

  The description is structured into focused paragraphs: primary purpose, input rules, when-to-use, response structure, and an example. It is longer than strictly necessary but every sentence provides useful information; the front-loaded purpose and usage guidance make it easy to parse quickly.

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

  Completeness5/5

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

  There is no output schema, so the description correctly takes on the burden of explaining the response shape—live_bands_by_topic, algorithms_for_topic, and declared_but_no_materializer_at_this_responder—with examples. Combined with input-mode guidance, aliases, and error behavior, the tool description is fully self-sufficient.

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

  Parameters4/5

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

  The schema already covers all six parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining precedence rules (lat+lng over place), alias handling, and the typo/fallback behavior, elevating it to a 4.

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

  Purpose5/5

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

  The description clearly states the tool resolves a real-world place to a canonical cell64 identifier and returns band/algorithms inventory. It distinguishes itself from emem_entity (for object identity) and emem_ask (for single-shot full chain), leaving no ambiguity about what the tool does.

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

  Usage Guidelines5/5

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

  There is an explicit 'When to use' section stating to use this tool when a real-world location needs a cell64 or band availability before recall. It also names alternatives (emem_entity for object identity, emem_ask for full-chain answers), providing clear when/where-not guidance.

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

• emem_verify_receiptA
  4.8/5.0
  Behavior5/5

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

  Despite readOnlyHint and other annotations, the description adds substantial behavioral context: v2 binds the inclusion proof so any reshaping looks like tampering, returns 200 with valid:false for structurally-well-formed bad signatures (never 4xx), names the two omissions that silently cause verification failure, and explains the advisory nature of key_epoch_advisory. It also clarifies the distinction between 'receipt_reshaped_after_signing' and 'signature_invalid' when the fact is held.

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

  Conciseness4/5

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

  The description is long and dense, but it is front-loaded with the core purpose and return shape, and uses labeled sections ('When to use') to organize a high volume of necessary caveats. While verbose, every sentence earns its place for a complex cryptographic verification tool; a slightly tighter structure would make it a 5.

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

  Completeness5/5

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

  With no output schema, the description enumerates all return fields, explains version-specific preimage rules, failure modes, exact omission behaviors, and provides a full example. It is sufficiently complete for an agent to invoke the tool correctly in varied contexts, including edge cases.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds semantic depth beyond the schema: it clarifies tolerated spellings (byte[] vs b32), the consequence of omitting the facts parameter (only signature checked, doctored fact survives), and the exact behavior of pubkey_b32 override. It also explains that current_responder_epoch only produces an advisory, never a rejection.

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

  Purpose5/5

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

  The description opens with a specific verb and resource ('Verify a signed receipt envelope server-side'), details the cryptographic process and return fields, and explicitly contrasts with the in-browser /verify path. This clearly distinguishes it from sibling tools like emem_echo_verify and makes the tool's purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description contains a dedicated 'When to use' section that names the exact situations (CDN offline, agent runtime lacks crypto, server-side audit of third-party receipt) and gives explicit instructions on what to pass, what to avoid (omitting merkle_proof or preimage_version, reshaping fields), and when the tool should not be used (offline verifier cannot distinguish reshaping from tampering). This is comprehensive when/when-not guidance.

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

• emem_guard_verdictA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint and openWorldHint, but the description adds critical behavioral nuance: 'ADVISORY: nothing is blocked, and a citation this responder does not hold is never a denial, because it is indistinguishable from one minted elsewhere.' It also reveals that 'a check that read nothing still answers allow,' and details the deny codes and fixes. This goes well beyond the structured annotations.

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

  Conciseness4/5

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

  The description is long but tightly organized: it leads with the core function, then details return codes, advisory behavior, usage guidance, and an example. Every section adds value, though some redundancy exists with the schema (e.g., shape descriptions). It earns a 4 rather than 5 because it is somewhat verbose for a tool that the schema already documents well.

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

  Completeness5/5

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

  Given the tool's complexity—5 parameters, an output schema, and a rich annotation set—the description is remarkably complete. It covers the full workflow, including when to use it, how to handle non-native payloads, what the codes mean, and how to move from consultation to enforcement. It even provides a concrete example argument. No critical context is missing.

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

  Parameters5/5

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

  With 100% schema coverage, the baseline is 3, but the description multiplies meaning: it explains the `shape` parameter's real-world consequence ('a CloudEvent whose citation sits at data.text is invisible to the native reader'), describes `claim_gating` as 'reports on the absence of a citation rather than on a failed check,' and clarifies that unrecognised shapes 'fall back to native rather than erroring.' These are insights not present in the schema.

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

  Purpose5/5

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

  The description opens with a specific action: 'Run emem-guard's policy pipeline over text you are about to send, against this responder's corpus.' It clearly identifies the resource (emem: citations in draft text) and the output (allow/deny with machine-readable reason), and distinguishes this from sibling tools like emem_recall or emem_ask by focusing on verification rather than retrieval or generation.

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

  Usage Guidelines5/5

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

  An explicit 'When to use' section states precisely when to invoke this tool: 'Call it on your own draft before you assert something, or on a tool result before you reason on it.' It also gives an alternative: 'To ENFORCE this rather than consult it, run your own node: emem_guard_selfhost returns the procedure,' and explains how to handle foreign payload shapes. This is model guidance with clear exclusions.

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

• emem_intentA
  4.9/5.0
  Behavior5/5

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

  The description reveals that the plan is 'EXECUTED in the same call', going beyond the annotations to explain side effects. It discloses the error envelope for unknown/missing `type`, the forwarding behavior for type:"ask", and the tslot/date distinction. 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.

  Conciseness4/5

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

  The description is long but well-structured with a table, clear sections, and a concrete example. The opening sentence front-loads the purpose, and every subsequent sentence adds value. Slightly dense but appropriate for the tool's complexity.

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

  Completeness5/5

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

  With no output schema, the description takes responsibility for explaining return values: it lists the resolved cell64, similarity, delta, and verdict. It also covers error handling, forwarding, and all seven intents. The description is complete enough for an agent to use this tool effectively.

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

  Parameters5/5

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

  Even though schema coverage is 100%, the description adds a cross-reference table mapping each `type` to required/optional fields and the answer produced. The example arguments illustrate the expected format. This matrix is not present in the schema and is essential for correctly selecting which fields to send.

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

  Purpose5/5

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

  The description opens with a clear verb+resource: 'Say what you want in one typed object and get the answer, without choosing a primitive.' It then explains the tagged union behavior and distinguishes itself from siblings by naming emem_recall, emem_recall_polygon, and emem_ask as alternatives. The table of seven intents makes the scope explicit.

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

  Usage Guidelines5/5

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

  An explicit 'When to use' section states to call this tool when the question maps to one of the seven rows, and to 'Reach past it for anything else', naming specific alternatives. It also warns that `window` takes tslots not dates and points to emem_trajectory for valid values, and explains that hidden tools are directly callable. This is exemplary usage guidance.

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

• emem_memory_bundleA
  5/5.0
  Behavior5/5

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

  The description discloses mutating behavior (readOnlyHint=false) and adds context: the auto-materialize recall path, content-addressed envelope, responder signature over the full receipt, offline verification via /v1/verify_receipt, the 256-triple cap, and the `members`/`resolved` response fields for partial resolution. 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.

  Conciseness5/5

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

  The description is dense but well-structured, with a leading definition, a 'When to use' subsection, an example, and operational caveats. No word is wasted; even the cap is explained with a rationale. It earns its length.

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

  Completeness5/5

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

  For a complex tool with nested triples, a 256 limit, partial resolution behavior, and no output schema, the description fully covers purpose, usage, verification, and response characteristics. It even addresses error behavior (typed 400) and round-trip planning, making it self-sufficient for an agent.

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

  Parameters5/5

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

  Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it explains that each triple runs through auto-materialize recall, that bundle_token is `emem:bundle:<bundle_cid>`, and importantly the operational cost model ('token is O(1) in size for any N, but covering N facts costs ceil(N/256) calls'). The example also clarifies the triples array structure.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Compose N (cell, band, tslot?) triples into ONE signed envelope.' This clearly distinguishes from sibling tools like `emem_memory_token` (singular) and `emem_memory_token_resolve`, as it bundles multiple facts rather than composing or resolving one.

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

  Usage Guidelines5/5

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

  Provides an explicit 'When to use' section: 'Call when the agent wants to cite multiple (place, band, vintage) facts as one handle.' It names the alternative (`emem_memory_token`) and states 'Use this instead of N separate composers when the citation is conceptually one thing,' plus the 256-cap planning advice.

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

• emem_memory_contradictionsA
  5/5.0
  Behavior5/5

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

  The description adds substantial behavioral context beyond the readOnlyHint annotation: the default scope excludes same-attester disagreements, severity is computed per band kind, and a zero result may mean only a narrower question was answered. It also discloses the output fields (disagreement_scope, providers[]) and the optional emitted edge, giving full insight into the tool's semantics.

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

  Conciseness5/5

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

  The description is long but highly organized: a clear lead sentence, a critical scope caveat, a 'When to use' block, parameter behavior, and a concrete example. No sentence is wasted; the density is justified by the tool's nuance. The structure makes it easy to parse the key points quickly.

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

  Completeness5/5

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

  With no output schema, the description must explain the return value, and it does: severity score, citations to disputed facts, records with disagreement_scope, and a providers[] list. It also covers edge cases like single-responder deployments and how to follow up with emem_diff or emem_edges_recall, making the tool fully comprehensible in context.

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

  Parameters5/5

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

  Even with 100% schema coverage, the description enriches each parameter: cell_prefix and band are framed as region/family narrowers, min_severity is explained with its per-band scoring, and include_same_attester_sources receives a full paragraph detailing when it matters. The example arguments tie all parameters together, demonstrating usage.

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

  Purpose5/5

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

  The description opens with a specific verb ('Surface') and a precise resource ('where the corpus DISAGREES with itself'), immediately distinguishing it from sibling tools like emem_ask or emem_recall. It clearly frames the tool as the opposite of a confident single answer, which clarifies its unique role.

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

  Usage Guidelines5/5

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

  It includes a dedicated 'When to use' section with concrete examples ('is there disagreement about X', 'audit this claim'), explains how to narrow with parameters, and explicitly references sibling tools (emem_diff, emem_edges_recall) for follow-up. It also warns against misinterpreting a zero result, providing vital guidance without being verbose.

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

• emem_memory_token_resolveA
  5/5.0
  Behavior5/5

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

  Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds substantial behavioral context: response top-level fields, the meaning of explicit null for value/unit, the precision nuance with value_verbatim, and the 404 behavior with a typed code. 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.

  Conciseness5/5

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

  The description is long but every sentence earns its place. It is front-loaded with the core purpose, followed by structured use guidance, response details, error handling, and an example. The inclusion of the 'Memory algebra' link is optional but not wasteful.

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

  Completeness5/5

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

  Despite lacking an output schema, the description fully covers the return shape, field semantics, error cases, and usage context. An agent has everything needed to invoke the tool correctly and interpret the result without additional lookups.

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

  Parameters5/5

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

  The single parameter `token` has 100% schema coverage, but the description goes further by explaining the token format in the first line and providing a concrete example argument. It also clarifies what the tool returns in relation to the token, which is beyond the schema.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Parse a `emem:fact:<cell64>:<fact_cid>` citation handle and return the reading it cites.' It clearly distinguishes itself from siblings by explaining it saves the agent from string-splitting and chaining manual GET calls. The title and description align on the same unambiguous purpose.

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

  Usage Guidelines5/5

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

  The 'When to use' section explicitly states when to call this tool: when an agent receives a memory_token from another agent or previous turn and wants the value behind it. It also provides clear alternatives for the failure case (try /v1/fetch or paste at a mirror), and guidance on which fields to read depending on the situation (value/unit vs. value_verbatim).

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

• emem_recallA
  5/5.0
  Behavior5/5

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

  The description discloses materialization on miss, slower first-call behavior, materialize_notes in response, empty-result semantics, responder-bound CIDs, and receipt-relevant filtering. This goes well beyond the annotations (readOnlyHint: false, openWorldHint: true, idempotentHint: true) and gives the agent an accurate model of side effects and response behavior. No contradiction with annotations; the false readOnlyHint is consistent with the described auto-materialization.

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

  Conciseness5/5

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

  The description is long, but the tool is genuinely complex with 14 parameters and rich behavioral caveats. The content is front-loaded with the core read/materialization behavior, then organized into use guidance, important caveats, and an example. Each section earns its place and avoids empty filler.

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

  Completeness5/5

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

  Given the tool's complexity, the presence of an output schema, and full schema coverage, the description is remarkably complete. It covers the calling sequence, materialization behavior, response notes, identity semantics, deterministic/provenance selection, temporal bounds, scope filtering, and the meaning of empty results. An agent has enough context to invoke this tool correctly in a wide range of scenarios.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description adds meaningful semantic context beyond the schema: the distinction between deterministic and provenance filters, how band and bands merge, the meaning of scope filtering for tenant isolation, the behavior of include freshness/edges/provenance, and the bi-temporal meanings of as_of_tslot and as_of_signed_at. This is substantial added value beyond parameter names and brief schema descriptions.

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

  Purpose5/5

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

  The description states a specific action ('Read the signed facts at a canonical address (cell64)') and immediately clarifies the auto-materialization behavior on a miss. It also distinguishes the tool from emem_entity by explaining that fact_cids are responder-specific and do not cross identity boundaries, giving an agent a clear basis for selecting this tool.

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

  Usage Guidelines5/5

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

  The description explicitly says 'Call after emem_locate (or with a known cell64)' and names the alternative tool emem_entity for identity that crosses responders. It also explains when to use deterministic/provenance filtering and that any wired band can be recalled without seeding, giving clear selection and sequencing guidance.

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