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_find_similarA
  4.6/5.0
  Behavior5/5

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

  The description discloses far more than annotations alone: mode tradeoffs (~1000× faster, ~65% recall@10), the open-world empty-result meaning ("empty result means nobody has attested a vector nearby"), and the ANN fast-path bypass for scope/as_of with the honest-cost tradeoff ("brute-force scan instead... the call is slower"). Filter semantics ("DROPPED rather than treated as false") and bi-temporal candidate-dropping are also candidly stated. No contradiction with annotations; there is only a soft tension between readOnlyHint=false and "materialises nothing", but the receipt is returned to the caller rather than persisted.

  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 text is front-loaded with mechanism and return shape, then a labeled "When to use" block, then an example. It is on the longer side and the mode paragraph partly duplicates the schema's mode description, but every sentence carries either selection or invocation information rather than 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?

  For a 10-parameter tool with nested objects and no output schema, the description covers the entire invocation surface: return contract (neighbours with cell64/score/band plus signed receipt), empty-result semantics, k bounds, key forms, band choices, mode tradeoffs, and the scope/filter/as_of behaviors. An agent can select and invoke this tool correctly from the text alone.

  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% and the schema's own parameter descriptions are already rich (mode byte-costs, filter drop rule, scope bypass). The description still adds non-redundant value: key formats (cell64 vs inline:[x,y,...]), band dimensionality (128-D foundation vs 1152-D 9-vintage 2017–2025 fusion) with the exact band name to pass, and a concrete example. That lifts it above the baseline-3 for fully covered schemas.

  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 opening line names a specific operation – k-NN over the corpus – with explicit input forms ("by cell embedding or inline vector") and a concrete return contract ("neighbours ordered nearest-first, each with cell64, score and the band scanned"). The trigger phrases "find places like X" / "where else looks like this" clearly separate it from siblings like emem_recall and emem_locate. It adds method and output detail well beyond the title.

  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?

  There is an explicit "When to use" block with concrete user-phrasing triggers and the embedding-input case, plus a worked example argument {"key":"damO.zb000.xUti.zde78","k":10}. What is missing is explicit when-not-to-use guidance or named sibling alternatives, so exclusion routing is left to inference.

  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_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_guard_verdictA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantial behavioral context: the ADVISORY that nothing is blocked, that a citation this responder does not hold is never a denial, and critically that 'a check that read nothing still answers allow.' It also discloses exact deny codes and fix semantics. This is exactly the kind of subtle behavior an agent must know before relying on the result.

  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 information-dense, and every section earns its place: output format, codes, advisory, when-to-use, shape caveats, enforcement alternative, example. The core purpose and machine-readable output are front-loaded before the caveats. It loses one point only because a few asides (the memory-algebra link, the selfhost integration list) are tangential for a single invocation decision.

  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 tool with 5 parameters, an output schema, and subtle behavioral traps, the description is remarkably complete. It covers the exact output string format, all deny codes and fixes, the advisory open-world behavior, empty-read behavior, cross-framework payload handling, the enforcement alternative, and a worked example. An agent has everything needed to call this correctly and interpret the result.

  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 earns a 4 by adding practical semantics beyond the schema: a concrete example argument, the rationale for claim_gating ('reports on the absence of a citation rather than on a failed check'), and the practical consequence of shape selection ('a CloudEvent whose citation sits at data.text is invisible to the native reader'). It also clarifies that shape only affects reading, not the output envelope.

  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 verb and resource: 'Run emem-guard's policy pipeline over text you are about to send, against this responder's corpus,' then specifies exactly what happens (finds every emem: citation, resolves each one, returns allow or deny). It differentiates from siblings by framing this as the consult-inline tool versus emem_guard_selfhost for enforcement, and by the draft-checking scenario, which none of the sibling names suggest.

  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?

  Explicit 'When to use' guidance names concrete triggers: call on your own draft before asserting something, or on a tool result before reasoning on it. It also gives explicit when-not-to-use guidance: 'To ENFORCE this rather than consult it, run your own node: emem_guard_selfhost returns the procedure.' The shape parameter guidance further clarifies when to set non-native shapes versus sending native texts/messages.

  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 non-destructive, so the description's added value is context beyond that. It discloses two non-obvious behaviors: a typo in an undeclared key is reported in `_unrecognised_arguments` rather than erroring, and coordinates win when both coordinates and a place name arrive. It also explains the response's three sub-fields, which is useful given no output schema.

  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 longer than average but well-structured: purpose first, then input rules, then when-to-use and response details, then an example. Every section carries necessary content for a spatial-resolution tool with six parameters and no output schema. A minor wordiness, such as the metaphorical 'so two models refer to the same ground instead of two descriptions of it,' is acceptable and aids clarity.

  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 on the burden of explaining return shape, which it does by naming `data_at_this_cell` and its three sub-fields. It also covers input alternatives, aliases, precedence, error-friendly behavior, and explicit routes to sibling tools. An agent has everything needed to call this 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 description coverage is 100%, so baseline is 3. The description adds value by summarizing that `q`, `query`, and `name` are all accepted spellings of `place`, and that coordinates win when both are supplied. This is a concise cross-field semantic that is not immediately obvious from the individual property 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 names a specific verb and resource: it 'mints the canonical, vendor-neutral address (cell64) for a real-world place' and also returns a topic-grouped inventory of bands and algorithms. It clearly distinguishes itself from emem_entity (object identity) and emem_ask (single-shot full chain).

  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?

  Explicitly states when to use: 'whenever the input refers to a real-world location and the next step needs the cell64 identifier or wants to know which bands are available before recalling.' It names alternatives and when to choose them: use emem_entity for first-class object identity and emem_ask for the single-shot packaged answer. It also clarifies coordinate vs. text input precedence.

  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_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.