Server Quality Checklist

Tool Scores

• recallA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that it performs a semantic search and returns top-N items, which implies a non-destructive read operation. However, it does not explicitly state that it is read-only, describe behavior when no memories match, or mention any auth or rate-limit considerations. The query-style guidance adds useful context but more behavioral disclosure would be needed for a higher score.

  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 compact, consisting of four short sentences that each deliver distinct value: what the tool does, the result format, when to use it, and query guidance. There is no filler or repetition, and the embedded example is illustrative without adding bulk. This is a model of efficient writing.

  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 full schema coverage and the presence of an output schema, the description needn't explain return values. It provides essential usage context: the tool's purpose, a priority use case (before asking the user), and query formulation advice. It does not discuss edge cases or exclusions, but for a straightforward search tool, this is sufficiently complete.

  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 descriptions for all 5 parameters, so the baseline is 3. The description adds semantic value specifically for the 'query' parameter by clarifying that it expects natural language rather than keywords, with a concrete example. No additional insight is given for type, limit, agent_id, or min_similarity beyond the schema, but this meaningful addition for the most important parameter justifies a 4.

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

  Purpose4/5

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

  The description clearly states the tool searches memories via semantic similarity and returns top-N relevant items. The verb 'search' and resource 'memories' are specific, and 'semantic similarity' implies a distinction from time-based recall siblings. However, it does not explicitly name alternatives like recall_recent or recall_as_of, so it stops short of full differentiation.

  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 explicitly instructs to use this tool FIRST before asking the user to repeat information, establishing a clear priority. It also provides query formatting guidance (natural language vs keywords) with an example. It does not explicitly state when not to use it or mention alternative sibling tools, but the 'FIRST' directive is strong context.

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

• recall_changed_sinceA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It states it returns memories created or updated after the timestamp, but doesn't mention pagination, ordering, or agent filtering behavior. Some behavioral aspects are implied but not fully disclosed.

  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 sentences, front-loading the purpose and then providing usage guidance. Every word contributes value, with no redundancy or fluff.

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

  Completeness3/5

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

  Given the tool has 4 parameters and an output schema, the description is somewhat complete but lacks details on limit behavior, ordering, and required agent_id condition. It covers purpose and usage adequately but leaves gaps in operational details.

  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 75%, so baseline is 3. The description adds context for the 'since' parameter but doesn't elaborate on 'type' or 'limit' beyond schema defaults. No new semantic 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 differential retrieval of memories created or updated after a given timestamp, using specific verbs and resource. It explicitly distinguishes from siblings by using 'differential retrieval' and providing use cases like 'what's new since 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?

  The description gives explicit usage guidance: 'Use this for "what's new since X?" or to catch up on activity between sessions.' This tells the agent when to apply the tool, though it doesn't explicitly mention when not to use it or name alternatives.

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

• recall_recentA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool returns data newest-first but does not mention scoping (e.g., agent-specific), response format, or any potential side effects. For a read-only tool, the description is adequate but minimal.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence with a usage example. Every part is purposeful, no redundancy, and the key action is upfront.

  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 (3 optional params, no required ones, output schema present), the description covers its core functionality and use case. It could mention ordering details or the limit default, but those are in the schema. Slightly above adequate.

  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 input schema already documents all three parameters (type, limit, agent_id). The tool description does not add meaning beyond what the schema provides, meeting the baseline.

  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 returns recently stored memories in reverse chronological order, using a specific verb ('Return') and resource ('memories'). It distinguishes itself from siblings like 'recall' (likely search-based) and 'recall_as_of' by focusing on recency without a specific query.

  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 explicitly advises using this tool to surface fresh context when lacking a specific query, e.g., 'what did we just decide?'. While it implies alternatives for specific recalls, it does not name them explicitly. The sibling list provides additional context.

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

• recall_as_ofA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It explains the core behavior: returning memories known before a given timestamp. The parameter descriptions (notably for 'as_of') provide additional detail on timestamp interpretation. No contradictions or omissions about side effects (it is read-only). The description is adequate for understanding the tool's behavior.

  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 sentences, front-loading the purpose ('Point-in-time recall') followed by immediate usage guidance. Every word serves a purpose; no filler or repetition. Excellent 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?

  Given the tool's 4 parameters and existence of an output schema, the description covers the essential information: purpose, when to use, and key behavior. It does not detail return structure or parameter limits, but those are covered by the schema and output schema. The description is sufficient for an agent to make correct selection and invocation decisions.

  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 75% (3 of 4 parameters have descriptions in the schema). The tool description adds value by contextualizing the 'as_of' parameter with usage examples, but does not describe 'type', 'limit', or 'agent_id' beyond what the schema already provides. For a high-coverage schema, a baseline of 3 is appropriate, with slight bonus for the usage context on 'as_of'.

  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 purpose: 'return only memories that were known before the given timestamp.' It explicitly contrasts with siblings by focusing on point-in-time recall, and provides concrete examples of when to use it (historical questions, reconstructing context). This distinguishes it from other recall tools like 'recall' (current memories) or 'recall_recent' (recent memories).

  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: 'Use this when the user asks historical questions... or to reconstruct context at a previous moment.' It does not explicitly mention when not to use it or name alternative tools, but the context is clear enough for an agent to infer that non-historical queries should use other recall tools.

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

• rememberA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses useful behavioral traits: memory is typed, carries confidence/provenance, and content is capped at 10000 characters. However, it does not mention behavior on duplicate storage, overwrite semantics, or what happens on failure, which are relevant for a persistence tool.

  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 four sentences, front-loaded with the primary purpose. Every sentence contributes: purpose, usage trigger, behavioral features, and content length constraint. No unnecessary filler.

  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 complexity (8 params, enums, output schema), the description covers purpose, usage, and key constraints well. The output schema exists, so return values need not be described. It lacks explicit handling of duplicates/overwrites, but this is a minor gap for a store operation with optional tags and provenance.

  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 explaining why parameters like type, confidence, and provenance exist ('so later retrievals can rank and filter intelligently') and emphasizes the atomicity expected in content ('store atomic, self-contained statements'), enriching beyond the schema's individual 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 opens with 'Store a single piece of information in the agent's long-term memory,' which clearly identifies the verb (store), resource (long-term memory), and scope (single piece). It distinguishes from siblings like recall (retrieval) and batch_remember (batch storage) through the explicit 'single piece' phrasing.

  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 clear guidance on when to use the tool: 'Use this whenever the user shares a stable fact, preference, decision, goal, or instruction you should recall in a future conversation.' It does not explicitly name alternatives or state when not to use it, but the context strongly implies it is for single-item storage versus retrieval or batch, which is sufficient.

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

• answerA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that the answer is LLM-generated, grounded only in stored memories (RAG), and returns answer text plus supporting sources. This is strong context, though it could also mention behavior when no memories are found or the effects of kiosk_mode; however, those are partially captured in the schema.

  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 clearly structured sentences: first states purpose and grounding, second gives selection guidance and return value. Every sentence adds value, with no filler or repetition of schema details.

  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 complexity (5 parameters, output schema), the description covers purpose, usage guidance, grounding behavior, and return contents. It doesn't explicitly discuss failure modes such as no memory found, but that is addressed by the kiosk_mode parameter and output schema, making the description adequately complete for an agent.

  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%: every parameter has a clear description. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline score 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 clearly states the tool's function: 'Ask a natural-language question and get an LLM-generated answer grounded ONLY in the agent's stored memories (RAG).' It also explicitly contrasts with a sibling tool ('Prefer this over `recall`'), distinguishing a synthesized answer from a ranked list.

  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 direct usage guidance: 'Prefer this over `recall` when you need a synthesized answer rather than a ranked list.' This tells the agent exactly when to choose this tool over a close alternative, and the rest of the description implies when not to use it (e.g., when a ranked list is desired).

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

• batch_rememberA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It adds useful context beyond the schema, such as the 'item without a source is attributed to the calling client' and the emphasis on 'independent facts.' However, it does not mention potential partial failures, idempotency, or other side effects, which would be richer context.

  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 extremely concise, consisting of two front-loaded sentences that convey purpose, usage context, and an alternative. Every word adds value, and it avoids redundancy with the schema.

  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 rich schema and presence of an output schema, the description covers purpose, usage, and distinctions effectively. It lacks an explicit note on error handling or atomicity, which might be relevant for a batch operation, but overall it is sufficiently complete for agent decision-making.

  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 the schema itself already explains the `memories` parameter, including field details, limits, and source attribution. The tool description does not add new parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

  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 with a specific verb and resource: 'Store many memories at once (up to 100).' It also distinguishes itself from the sibling tool `remember` by explicitly saying 'For a single item, prefer `remember`.'

  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: 'Use this when you have a list of independent facts to persist - e.g. extracting structured data from a document.' It also gives an exclusion by directing single-item use to `remember`, which clarifies the appropriate context for each tool.

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