Server Quality Checklist

Tool Scores

• icx_reset_sessionA
  4.2/5.0
  Behavior4/5

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

  Annotations only give readOnlyHint: false, indicating a mutation. The description goes beyond this by specifying exactly what is mutated (session dialogue) and what is preserved (crystallized knowledge, facts, weights). It adds valuable context about the side-effect scope, though it does not cover potential edge cases like timeouts or effects on concurrent sessions.

  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 two terse sentences plus a usage directive. The core action is front-loaded ('Resets conversational dialogue history'), followed by the preserving qualifier and the usage scenario. No filler or redundancy; every clause earns its place.

  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?

  Given the tool's simplicity (one optional param, no required fields) and the presence of an output schema, the description covers purpose, side effects, and usage context. It does not describe the return value, but the output schema covers that. Minor omission: it doesn't explain what happens if the space_id is invalid or if resets affect multiple sessions, but these are not essential for basic usage.

  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?

  The schema covers the sole parameter space_id with a clear description ('Optional memory space partition whose turn history should be reset. Defaults to caller default space.'). The tool description adds no additional meaning about the parameter beyond what the schema provides. With 100% schema coverage, baseline 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 clearly states the verb ('Resets') and the resource ('conversational dialogue history') while adding a critical qualifier: it preserves all crystallized knowledge and memory weights. This distinguishes it from siblings like icx_search_facts or icx_recall_scoped, which interact with long-term memory rather than session state. The final sentence reinforces the specific scope of the mutation.

  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?

  Explicitly provides a when-to-use scenario: 'Use when starting a new conversation topic while retaining all learned knowledge.' It also clarifies what is not reset (persistent memory). However, it does not explicitly name alternative tools (e.g., 'for full memory reset, use X') or state when not to use it, so it's slightly below the highest bar.

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

• icx_inspect_spaceA
  4.3/5.0
  Behavior4/5

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

  Annotations already include readOnlyHint=true, and the description reinforces with 'Read-only with no side effects.' It adds value by declaring the tool performs an 'audit' with real-time telemetry, which signals a non-mutating inspection. No contradiction.

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

  Conciseness5/5

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

  Two concise sentences: the first lists the tool's outputs and actions, the second gives use cases and safety. No filler words.

  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?

  Tool is simple with one optional parameter, has an output schema (so return values are already documented), and annotations cover read-only safety. Description covers health monitoring and verification cases, which is complete for this scope.

  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 coverage is 100% for the single optional parameter. The description mentions 'defaults to caller default space' which echoes schema, but does not add new detail beyond that. Baseline 3 is appropriate since schema fully documents the param.

  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 ('Audits and retrieves') on a specific resource ('partitioned memory space'), and lists specific telemetry items ('active node count, total synapses, grounded facts count, memory state, and contradiction alarms'). It clearly distinguishes from siblings which focus on recall, search, and session operations.

  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?

  States when to use: 'monitor memory health, verify ingestion, or inspect space capacity.' Does not explicitly name alternatives or when not to use, but the use cases are clear given sibling tools have distinct functions.

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

• icx_quote_slotA
  4.3/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already establishes the read-only safety profile. The description adds context about exact character-for-character retrieval and 'no side effects,' but does not disclose edge-case behavior such as out-of-range index handling or access requirements. With annotations present, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is three sentences, each earning its place: the core function, the intended use case, and the alternative tool. It is front-loaded with the most important information and contains no 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 moderate complexity, full schema coverage, readOnlyHint annotation, and presence of an output schema, the description is complete. It explains what the tool returns, when to use it, and how it differs from the closest sibling, without needing to restate schema details or output structure.

  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 fully documents family, index, and space_id. The description adds minimal semantic value beyond the schema, mostly reinforcing that index is an 'ordinal slot index.' This meets the baseline for schema-covered parameters but does not elevate it.

  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: 'Retrieves exact character-for-character verbatim text quotes from stored document registers by document family and ordinal slot index.' This clearly distinguishes it from the semantic sibling tool icx_recall_scoped by emphasizing exactness over paraphrasing.

  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 usage guidance is provided: 'Use this tool when exact contractual wording, legal clauses, or code revisions must be quoted without AI paraphrasing.' It also names the alternative for semantic QA: 'Use icx_recall_scoped for semantic QA instead.' This fully addresses when to use and when not to use.

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

• icx_rememberA
  4.4/5.0
  Behavior4/5

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

  With readOnlyHint=false, the annotation already signals a write operation. The description adds valuable behavioral context: states ingestion is additive and non-destructive, mentions 'zero context window decay', and clarifies topological memory nodes. It doesn't detail failure modes or side effects beyond that, but the additive/non-destructive note is strong supplementary transparency.

  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?

  Three sentences, each adding distinct value: what it stores, and when to use/avoid with alternatives. No redundancy, front-loaded with the primary purpose. Ideal conciseness.

  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 tool has 4 parameters (1 required), 100% schema coverage, no enums, and an output schema exists. The description covers purpose, ingestion behavior, non-destructive semantics, and usage boundaries. Minor gap: it doesn't explicitly state what the tool returns (e.g., confirmation or memory ID), but the output schema presumably covers that, and the complexity is moderate.

  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% and each parameter has a meaningful description. The tool description adds context on the purpose of 'family' (deterministic verbatim register quoting) and 'filename' (provenance tag), but these details are already partly in the schema. The description does not add significant new semantic value beyond what the schema provides, so baseline 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 ('Stores... into long-term persistent memory') and clearly identifies the resources (text, documents, code snippets, conversational facts). It distinguishes from siblings by explicitly noting that this is for ingestion, not querying, and references icx_recall_scoped and icx_search_facts as alternatives.

  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 explicit guidance on when to use ('whenever you need to save facts, contracts, documentation, or user details') and when not to use ('Do not use for querying existing memory'), naming the alternative tools. This is a model example of usage direction.

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

• icx_search_factsA
  4.4/5.0
  Behavior4/5

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

  Annotations already include readOnlyHint: true. The description reinforces this by stating 'Read-only with no side effects,' which adds explicit language beyond the annotation. It does not contradict the annotation and gives a clear behavioral statement about the tool's non-mutating nature.

  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 three sentences, each earning its place: purpose, usage guidance, and read-only note. It is front-loaded with the core action and immediately distinguishes from a sibling, with no redundant or extraneous wording.

  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?

  Given the presence of an output schema and readOnlyHint annotation, the description covers the essential context: purpose, usage, alternative, and side-effect statement. It omits details like ordering or match thresholds, but these are not critical given the schema richness. Slight room for improvement in describing result semantics, but overall 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 all parameters are already described. The description adds minimal extra value, only reiterating that query terms are for entity names and keyword discovery, which is largely already in the schema. The baseline of 3 is appropriate since the schema carries the parameter semantics.

  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 explicitly states the tool searches memory lattice nodes and decoded facts via keyword overlap and proximity, covering both resource and method. It also distinguishes itself from a sibling (icx_recall_scoped) by contrasting its use case, making the 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 provides explicit guidance: 'Use this tool for entity exploration or keyword discovery' and 'For natural language question answering with grounded factual citations, use icx_recall_scoped instead.' This clearly indicates when to use and when not to use, with a named alternative.

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

• icx_recall_scopedA
  4.6/5.0
  Behavior4/5

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

  The annotations include readOnlyHint: true and the description says 'Read-only and has no side effects,' but this is only a reinforced safeness; beyond that, it also adds what the annotation doesn't show: the action is 'semantic recall' over 'long-term storage', returning grounded facts, quotes, and source documents. It does not disclose rate limiting, token limits, or partial failures.

  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?

  Four crisp sentences. The first sentence packs the core capability; the second contains examples; the third shows the alternative; the fourth says read-only. No wasteful words.

  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 data is a single high-level semantic retriever with a parameter count of 3 and a large number of sibling alternatives. The input schema and annotations are available; the output schema is presumably present (the signal indicates having an output schema). The description says facts/ citations, but there is no mention of 'no answer' style or edge cases. Existing output schema may resolve but is not shown.

  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 has three properties overall with a 100% description coverage. The description words provide semantic context beyond schema: the user question is 'an input text, keyword, or concept'; top_k is 'the number of grounded facts to retrieve (default 10; min 1; max 50); space_id is 'optional partition area for restricting the memory. This does enough, and while the schema already reports defaults/min/max, its descriptions are not fully redundant with 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 ('performs associative semantic recall across long-term memory'), a precise resource ('to retrieve grounded facts, citations, and source documents'), and an explicit showcase of how it is distinct from its siblings: it calls out icx_find_facts for raw keyword matches and icx_quote_slice for character-exact verbatim quotes.

  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?

  States clearly when to use it ('when answering questions about already saved documents or facts'), exemplars included; the explicit alternatives are stated: for raw keyword matching across all entity names, use icx_find_facts instead; for exact verbatim quotes, use icx_quote_slice.

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