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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains the async pipeline process (extraction → embedding → consolidation → knowledge compilation) and latency ('becomes searchable within seconds'), which are important behavioral traits not inferable from the schema alone. It doesn't cover error conditions or permissions, keeping it from a perfect score.

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

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

The description is well-structured with clear sections (purpose, usage guidelines, behavioral details) and every sentence adds value. It's front-loaded with the core purpose, avoids redundancy, and maintains an efficient length for the complexity of the tool.

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

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

For a tool with 7 parameters, no annotations, and no output schema, the description provides strong contextual coverage. It explains purpose, usage, behavioral process, and latency. The main gap is lack of information about return values or error handling, which would be helpful given the absence of output schema.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide overall context about what constitutes a good 'memory' value, which slightly enhances understanding. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verb ('Store') and resource ('persistent memory'), and distinguishes it from siblings by specifying it's for storing new memories rather than retrieving, updating, or deleting them. The opening sentence establishes the core function unambiguously.

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

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

The description provides explicit guidance with dedicated 'When to use' and 'When NOT to use' sections, listing concrete examples of appropriate scenarios (preferences, facts, decisions) and exclusions (temporary info, greetings). It also references sibling tool 'add_memory_to_pool' as an alternative for specific use cases.

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

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

With no annotations provided, the description carries full burden and does well by explaining the tool's key behavioral trait: memories are 'visible to all pool members' (shared visibility). It doesn't cover other potential behavioral aspects like error conditions, rate limits, or authentication requirements, but provides solid core context.

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

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

The description is perfectly structured and front-loaded with the core purpose, followed by usage guidelines. Every sentence earns its place with no wasted words, and the bullet-point style for usage guidelines enhances readability without sacrificing conciseness.

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

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

For a write operation with no annotations and no output schema, the description provides strong contextual completeness by clearly explaining the tool's purpose, usage context, and key behavioral trait (shared visibility). It could be more complete by mentioning what happens on success/failure or return values, but covers the essential context well.

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

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

With 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description adds minimal parameter-specific context beyond the schema (only implying 'memory' should be team-relevant information), meeting the baseline 3 for high schema coverage.

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

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

The description clearly states the specific action ('Store a memory in a shared pool') and resource ('shared pool'), and explicitly distinguishes it from the sibling tool 'add_memory' by specifying it's for team/group relevance rather than individual user context. This provides excellent differentiation from alternatives.

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

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

The description provides explicit guidance with dedicated 'When to use' and 'When NOT to use' sections, including concrete examples ('Team decisions, shared project facts, group preferences') and a clear alternative ('use add_memory'). This gives the agent perfect context for tool selection.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the operation is permanent ('permanently remove'), has side effects on related data structures ('removes it from vector index and knowledge graph'), and requires a specific identifier ('by ID'). However, it doesn't mention potential errors (e.g., invalid ID), permissions, or rate limits, leaving some gaps.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by clear usage guidelines in bullet-like sections. Every sentence earns its place by adding critical information without redundancy, making it highly efficient and well-structured.

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

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

Given the tool's complexity (destructive operation with side effects), no annotations, and no output schema, the description does well by covering purpose, usage, and parameter guidance. However, it lacks details on error handling or return values, which could be important for a deletion tool, leaving minor gaps in completeness.

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

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

The schema description coverage is 100%, so the schema already documents the single parameter 'memory_id' as a UUID. The description adds value by emphasizing the need to 'search first if you only have the memory text,' providing practical guidance beyond the schema's technical definition.

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

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

The description clearly states the action ('permanently remove'), the resource ('a memory by ID'), and the scope of the operation ('also removes it from vector index and knowledge graph'). It distinguishes this tool from its sibling 'update_memory' by emphasizing permanent deletion versus correction.

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

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

The description explicitly provides 'When to use' scenarios (info is completely wrong, user explicitly says 'forget this' or 'remove that') and 'When NOT to use' guidance (info just needs correction, use update_memory instead). It names a specific alternative tool, making it clear when to choose this over siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it retrieves a consolidated knowledge profile compiled from memories through a processing pipeline, maintains versions, and gets richer over time. It also mentions that knowledge may not exist for new users and suggests a fallback. However, it doesn't detail potential rate limits, authentication needs, or exact response format beyond 'structured Markdown document.'

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

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

The description is well-structured and appropriately sized. It front-loads the purpose, followed by usage guidelines and behavioral context. Each sentence adds value: the first defines the tool, the second provides usage rules, the third gives behavioral details. There's minimal redundancy, though the explanation of the processing pipeline could be slightly more concise.

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

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

Given the tool's complexity (consolidated knowledge with a processing pipeline) and the absence of both annotations and an output schema, the description does a good job of providing context. It explains what the tool returns, when to use it, and how it relates to other tools. However, without an output schema, it could benefit from more detail about the exact structure of the Markdown document or example output to fully compensate for the missing structured data.

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

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

The schema description coverage is 100%, so the schema already documents all three parameters. The description adds some semantic context: it explains that 'merged=true' is 'RECOMMENDED for context loading' and that the knowledge is 'compiled from memories through the processing pipeline.' However, it doesn't provide additional meaning beyond what's in the schema descriptions for user_id or category parameters. The baseline of 3 is appropriate when the schema does most of the work.

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

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

The description clearly states the tool's purpose: 'Retrieve the user's consolidated knowledge profile — a structured Markdown document compiled automatically from their memories.' It specifies the verb ('retrieve'), resource ('knowledge profile'), and format ('structured Markdown document'), distinguishing it from sibling tools like search_memories or get_memories that handle individual memories rather than consolidated knowledge.

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

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

The description provides explicit usage guidelines: 'When to use: START OF EVERY CONVERSATION. Call with merged=true to load the full user context before responding.' It also specifies when not to use: 'When NOT to use: Looking for specific info (use search_memories).' and mentions fallback behavior: 'Knowledge may not exist yet for brand-new users — fall back to search_memories if this returns empty.' This clearly differentiates it from alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: chronological ordering, pagination support, and the absence of relevance ranking. However, it doesn't mention potential rate limits, authentication requirements, or error conditions, leaving some behavioral aspects uncovered.

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

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

The description is efficiently structured with two brief paragraphs: one stating the core functionality and differentiation, and another providing clear usage guidelines. Every sentence adds value without redundancy, and key information is front-loaded.

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

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

For a read-only list tool with no output schema, the description provides good context about ordering, pagination, and sibling differentiation. However, it doesn't describe the return format (e.g., what fields memories include) or potential limitations like maximum result sets, leaving minor gaps in completeness.

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

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

The schema description coverage is 100%, providing full parameter documentation. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain interactions between user_id and agent_id filters). This meets the baseline expectation when schema coverage is high.

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

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

The description clearly states the tool's purpose with specific verbs ('List stored memories chronologically with pagination') and explicitly distinguishes it from its sibling 'search_memories' by noting it 'does NOT rank by relevance.' This provides clear differentiation from alternatives.

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

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

The description includes explicit 'When to use' and 'When NOT to use' sections, naming specific alternatives ('search_memories' and 'get_knowledge') and providing clear contexts ('Browsing, auditing, or when you need to see everything' vs. 'Looking for specific info' or 'loading user profile'). This offers comprehensive guidance on tool selection.

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

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

No annotations are provided, so the description carries the full burden. It mentions retrieving 'full details (timestamps, metadata, categories)', which adds useful context about the return format. However, it doesn't disclose other behavioral traits like error handling, permissions needed, or rate limits, leaving some gaps for a tool with no annotation coverage.

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

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

The description is two sentences that are front-loaded with the core purpose and usage guidelines. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly efficient and easy to parse.

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

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

Given the tool's low complexity (1 parameter, no nested objects) and high schema coverage, the description is mostly complete. It covers purpose, usage, and some return details. However, with no output schema and no annotations, it could benefit from more behavioral context like error cases or response structure, slightly reducing completeness.

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

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

Schema description coverage is 100%, so the schema already documents the 'memory_id' parameter as a UUID. The description adds minimal value beyond this by implying the ID comes from search results, but doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose with a specific verb ('Retrieve') and resource ('a single memory by ID'), and distinguishes it from siblings like 'get_memories' (plural) and 'search_memories' by specifying it's for single-item retrieval when you already have an ID. This provides precise differentiation.

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

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

The description explicitly states when to use this tool ('Use when you have an ID from search results and need full details'), providing clear context for its application. It implies alternatives like 'search_memories' for when you don't have an ID, making the guidance comprehensive and actionable.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool uses LLM for interpretation and answer generation, consumes tokens (implying cost/rate limits), and has performance characteristics (slower with higher limits). However, it doesn't mention permissions, error handling, or response format, leaving some gaps.

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

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

The description is well-structured and front-loaded, with the core purpose stated first, followed by usage guidelines and examples. Every sentence adds value—no wasted words—and it efficiently communicates essential information in a compact form.

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

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

Given the tool's complexity (LLM-based querying) and lack of annotations or output schema, the description does a good job covering purpose, usage, and behavioral traits. However, it doesn't explain the return format or potential errors, which could be important for an AI agent. It's mostly complete but has minor gaps.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema—it implies natural language input for 'query' but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('ask a natural language question', 'get an AI-generated answer') and distinguishes it from siblings by emphasizing its unique capability ('Most powerful graph tool — uses LLM to interpret relationships and compose an answer'). It explicitly differentiates from graph_search and search_memories, making its role distinct.

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

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

The description provides explicit guidance on when to use ('Complex relationship questions') and when not to use ('Simple entity lookup', 'Simple memory retrieval'), naming specific alternatives (graph_search and search_memories) and explaining trade-offs (cost and speed). This gives clear context for tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains the tool's function (semantic similarity search), scope (entities extracted from memories), and constraints (conceptual matching rather than exact text). It doesn't mention rate limits, authentication needs, or detailed output format, but provides solid operational context for a search tool.

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

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

The description is perfectly structured with three focused sentences: purpose statement, when-to-use guidance, and when-not-to-use guidance. Every sentence earns its place by providing distinct value. It's front-loaded with the core functionality and efficiently addresses usage context.

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

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

For a search tool with 4 parameters (100% schema coverage) and no output schema, the description provides excellent operational context. It clearly explains what the tool does, when to use it, and how it differs from alternatives. The main gap is the lack of output format information, but given the tool's relatively straightforward search nature and good parameter documentation, this is a minor limitation.

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

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

The input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the specific action ('search the knowledge graph for entities'), the resource ('entities like people, organizations, technologies'), and the mechanism ('by semantic similarity'). It distinguishes this tool from siblings like search_memories and graph_traverse by specifying it's for entity discovery rather than memory content or relationship paths.

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

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

The description provides explicit 'When to use' guidance with three specific scenarios (discover mentions, find by concept, check existence) and 'When NOT to use' guidance with two clear alternatives (search_memories for content, graph_traverse for paths). This gives comprehensive context for tool selection among siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool traverses relationships bidirectionally, has a depth limit (3 hops), and provides concrete examples of relationship discovery. However, it doesn't mention performance characteristics like rate limits or potential data volume impacts, which would be helpful for a traversal tool.

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

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

The description is perfectly structured and concise: it starts with the core functionality, then provides clear usage guidelines with 'When to use'/'When NOT to use' sections, and ends with a workflow example. Every sentence adds value with zero wasted words, and the information is front-loaded appropriately.

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

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

For a graph traversal tool with 5 parameters, 100% schema coverage, but no annotations or output schema, the description provides excellent contextual completeness. It covers purpose, usage guidelines, behavioral context, and workflow examples. The only minor gap is the lack of information about return format or structure, which would be helpful since there's no output schema.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema - it mentions the 'from' parameter in the workflow example but doesn't provide additional context about parameter interactions or usage patterns. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('walk relationships', 'discover connections') and resources ('starting entity', 'bidirectionally', 'up to 3 hops deep'). It distinguishes this tool from sibling tools like graph_search (prerequisite) and graph_query (alternative for natural language queries).

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

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

The description provides explicit guidance on when to use ('You found an entity via graph_search and want to discover connections'), when NOT to use ('You don't have an entity ID yet', 'You want a natural language answer'), and alternatives ('use graph_search first', 'use graph_query'). It includes a typical workflow example that reinforces proper usage.

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

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

No annotations are provided, so the description carries full burden. It describes the tool's behavior (listing entities with memory counts) but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or pagination behavior. The description provides basic functionality but lacks operational details.

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

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

The description is perfectly concise with two sentences that each serve distinct purposes: the first defines the tool's function, the second provides usage guidance. Every word earns its place with zero redundancy or unnecessary elaboration.

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

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

For a tool with no annotations, no output schema, and 0 parameters, the description provides adequate basic information about what the tool does and when to use it. However, it doesn't describe the return format (what the list looks like, structure of entities with memory counts) or address potential limitations, which would be helpful given the lack of structured output documentation.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since there are none, and the schema fully documents the empty input structure.

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

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

The description clearly states the specific action ('List all users and agents'), the target resource ('that have stored memories'), and includes a distinguishing feature ('with memory count per entity'). It precisely defines what the tool does without being tautological.

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

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

The description explicitly provides usage guidance: 'Use to discover who is in the system before scoping searches.' This tells the agent when to use this tool (for discovery before more targeted operations) and implies alternatives like search_memories or get_memories for more specific queries.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a read operation (lists pools) and describes the return format (name, access level, member count, memory count), but doesn't mention potential limitations like pagination, rate limits, or authentication requirements.

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

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

Two sentences with zero waste: the first states the action and resource, the second adds context about pools and specifies the return data. Every sentence adds value beyond what's obvious from the tool name.

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

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

For a simple list tool with 0 parameters and no output schema, the description is reasonably complete: it explains what the tool does, what pools are, and what data is returned. However, without annotations or output schema, it could benefit from more behavioral context (e.g., pagination, sorting).

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and output.

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

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

The description clearly states the verb ('List') and resource ('all shared memory pools in the workspace'), specifying what information is returned (name, access level, member count, memory count). It distinguishes from siblings like 'search_pool' by indicating this lists ALL pools without filtering.

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

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

The description implies usage context by stating it lists 'all shared memory pools in the workspace' and describes pools as 'collaborative spaces where multiple users/agents contribute and read memories.' However, it doesn't explicitly state when to use this vs. alternatives like 'search_pool' or provide exclusions.

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

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

With no annotations provided, the description carries full burden and does well by explaining the tool's primary retrieval function and search modes. It could improve by mentioning potential limitations (e.g., search accuracy, performance characteristics) or authentication requirements, but covers core behavioral aspects adequately for a retrieval tool.

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

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

The description is well-structured with clear sections (purpose, usage guidelines, search modes), front-loaded with the core purpose, and every sentence adds value. No wasted words while maintaining comprehensive coverage.

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

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

For a retrieval tool with 8 parameters, 100% schema coverage, and no output schema, the description provides excellent context about when to use, search modes, and sibling differentiation. It could slightly improve by mentioning what the output looks like (memory objects with scores?) since there's no output schema, but otherwise very complete.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds value by explaining the three search modes (hybrid, semantic, keyword) with usage examples, but doesn't provide additional parameter semantics beyond what's in the schema descriptions. Baseline 3 is appropriate when schema does heavy lifting.

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

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

The description clearly states the tool's purpose: 'Find relevant memories by meaning, keywords, or both' and identifies it as 'the primary retrieval tool.' It distinguishes from siblings like get_knowledge (full user profile) and get_memories (chronological browsing), providing specific verb+resource differentiation.

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

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

The description explicitly provides 'When to use' scenarios (need context, recall stored info, user asks about X) and 'When NOT to use' with named alternatives (get_knowledge for full profile, get_memories for chronological browsing). It also includes guidance on search mode selection with specific examples.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions scoping to one pool, it doesn't describe what gets returned (formats, structure), whether results are paginated, authentication requirements, rate limits, or error conditions. For a search tool with no annotation coverage, this leaves significant behavioral gaps.

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

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

The description is extremely concise with just two sentences that each serve a clear purpose: the first defines the tool's function, and the second provides usage guidance. There's zero wasted language or redundancy.

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

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

For a search tool with 4 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate basic context about purpose and scoping. However, it doesn't address what the search returns (formats, structure) or behavioral aspects like error handling, which would be important for a tool with no output schema.

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

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

The schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the tool searches within a specific shared pool, which is a specific verb+resource combination. It distinguishes from sibling 'search_memories' by specifying the scoping to one pool, though it doesn't fully differentiate from other search-related siblings like 'graph_search' or 'graph_query'.

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

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

The description provides clear context for when to use this tool ('for team/project context') and explicitly mentions the alternative 'search_memories' for comparison. However, it doesn't specify when NOT to use it or mention other potential alternatives among the many sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the mutation nature ('Replace'), consequences (triggers re-processing including embedding, categorization, consolidation), and operational preferences (prefer over delete+add). However, it lacks details on permissions, error handling, or rate limits, which would elevate it to a 5.

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

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

The description is front-loaded with the core purpose, followed by structured usage guidelines. Every sentence earns its place by providing essential operational or contextual information without redundancy, making it highly efficient and well-organized.

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

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

Given the mutation complexity and lack of annotations or output schema, the description is largely complete for tool selection—it covers purpose, usage, and behavioral effects. However, it omits details on return values or error responses, which would be needed for full invocation support, preventing a perfect score.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any additional meaning or context beyond what the schema provides for memory_id, memory, or priority, resulting in a baseline score of 3.

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

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

The description clearly states the specific action ('Replace an existing memory with new text') and resource ('memory'), distinguishing it from siblings like delete_memory (removal) and add_memory (creation). It explicitly mentions triggering re-processing, which adds operational context beyond basic replacement.

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

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

The description provides explicit 'When to use' scenarios (correcting facts, preference changes, outdated info) and 'When NOT to use' guidance (completely wrong info, directing to delete_memory). It also advises preferring this tool over delete+add for fixing existing info, offering clear alternatives.

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