Synapse Layer — Continuous Consciousness Infrastructure

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 mentions the tool 'returns database status, memory count, and engine version', which gives some output context, but lacks details on permissions, rate limits, or potential side effects. This is adequate but has gaps for a tool with zero 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 front-loaded and concise, consisting of two efficient sentences that directly state the tool's purpose and return values without any wasted words. Every sentence earns its place by providing essential information.

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 (0 parameters, no output schema, no annotations), the description is minimally complete. It explains what the tool does and what it returns, but for a health check tool, it could benefit from more context on error handling or typical use cases. It's adequate but leaves room for improvement.

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 tool has 0 parameters with 100% schema description coverage, so the schema already documents this fully. The description doesn't need to add parameter information, and it doesn't contradict the schema. A baseline of 4 is appropriate as the description compensates by not introducing confusion.

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 ('verify system availability and memory pipeline integrity') and resources ('database status, memory count, and engine version'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'process_text' or 'search', which prevents a perfect score.

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 no guidance on when to use this tool versus alternatives like 'search' or 'recall'. It implies usage for system health checks but doesn't specify contexts, prerequisites, or exclusions, leaving the agent without clear decision-making criteria.

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?

Discloses essential behavior: returns context and profile, and that it's required for cross-session continuity. No annotations exist, so the description must carry the full burden, which it does well. A score of 5 would require additional details like cost or side effects.

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?

Three concise sentences, each adding crucial information. No filler, all imperative and front-loaded with the key instruction.

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 no parameters and no output schema, the description fully covers what the agent needs to know: when to call, what it returns, and consequences of skipping. Context signals confirm no missing elements.

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 has no parameters, so the description naturally adds no parameter info. Baseline of 4 is appropriate as there is nothing to add.

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?

Clearly states the tool's purpose: initializes context by returning persistent memory and user profile. The verb 'initialize' combined with 'FIRST action in every new conversation' specifies both the function and its critical timing.

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?

Explicitly states when to use ('FIRST action in every new conversation'), and what happens if skipped ('respond without knowing who the user is or what they are building'). No sibling tool serves this initialization purpose, so no alternatives needed.

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. It discloses the default scope behavior ('fail-closed') and authentication implications ('authenticated tenant'), which are valuable behavioral traits. However, it doesn't mention pagination, rate limits, error conditions, or what the return format looks like, leaving gaps for a listing operation.

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 establishes core functionality, the second explains the key parameter nuance. Every word earns its place, and the most important information (default scope behavior) 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 listing tool with 3 parameters and no output schema, the description provides adequate core functionality explanation but lacks details about return format, pagination behavior, error handling, and comparison with similar sibling tools. The absence of annotations means more behavioral context should ideally be included.

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 fully documents all three parameters. The description adds minimal value beyond the schema - it mentions scope options but doesn't provide additional semantic context about parameter interactions or usage patterns that aren't already in the parameter descriptions.

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 ('memories'), specifies ordering ('by creation date'), and distinguishes scope options. It explicitly differentiates from potential sibling tools by defining the specific listing operation rather than recall/search/store operations.

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 about when to use different scope parameters ('agent' vs 'tenant'), including the default behavior. However, it doesn't explicitly mention when NOT to use this tool versus alternatives like 'search' or 'recall', nor does it compare with sibling tools for similar functionality.

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 must fully disclose behavioral traits. It only states 'Record feedback' without detailing idempotency, overwrite behavior, or rate limits. This is insufficient for a mutation 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?

Three concise sentences with no redundant information. The core action, purpose, and constraint are 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?

Given no output schema, the description explains the purpose and impact on recall quality. It lacks details on return value or potential errors, but is adequate for a feedback tool among siblings.

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?

Input schema coverage is 100%, so the schema already documents parameters. The description adds a constraint ('memory must belong to the authenticated user') but does not enhance semantic understanding beyond schema.

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 starts with 'Record feedback on a previously recalled memory', which is a specific verb+resource. It clearly distinguishes from siblings like save_memory or recall_memory by focusing on feedback.

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 states the data 'is used to improve future recall quality via usage-based boosting' and requires the memory to belong to the authenticated user. It implies when to use (after recall), but lacks explicit when-not-to-use or 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?

Discloses encryption method (AES-256-GCM), token single-use, and governance requirement (reason). Without annotations, this provides solid behavioral insight beyond basic purpose.

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?

Concise two-sentence description plus governance note; no extraneous text. Essential information is front-loaded 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?

Covers encryption, single-use, and reason requirement. Lacks explicit mention of output format, but given tool complexity and no output schema, it is still reasonably 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 coverage is 100% with existing descriptions. Description adds specifics: token format (64 hex chars), reason length constraint (10-200 chars), and default for consuming_agent. This enhances usability.

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?

Explicitly states the action ('Consume a one-time handover token') and the resource ('encrypted memory packages'). Clearly distinct from sibling tools like list_memories or save_memory, which deal with memory operations directly.

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?

Describes when to use (when a handover token is available) and mentions token generation from Forge UI or API. Does not explicitly exclude alternative scenarios, but the context is clear enough.

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 describes the processing pipeline (policy evaluation, PII/secret redaction, deduplication, persistence), which adds context beyond basic functionality. However, it lacks details on permissions, rate limits, error handling, or what 'persistence' entails (e.g., storage location or format), leaving gaps for a tool with significant processing implications.

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 concise and front-loaded, with two sentences that efficiently outline the tool's purpose and pipeline. Every sentence adds value: the first defines the scanning function, and the second details the processing steps. It avoids redundancy and is appropriately sized for the tool's complexity.

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 (processing text through multiple stages) and lack of annotations and output schema, the description is moderately complete. It covers the core functionality and pipeline but omits details on output format, error cases, or integration with sibling tools. This leaves the agent with incomplete context for effective use, especially without an output schema to clarify results.

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 no specific parameter information beyond implying that 'text' is the primary input for scanning. It doesn't explain how parameters like 'source' or 'project' affect the processing, so it meets the baseline but doesn't enhance understanding beyond the schema.

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 function: scanning free-form text for specific event types (milestones, decisions, alerts, strategic events) and processing them through a pipeline. It uses specific verbs like 'scans,' 'detects,' and 'passes through,' making the purpose explicit. However, it doesn't differentiate from sibling tools like 'save_to_synapse' or 'search,' which might have overlapping text-processing functions.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'save_to_synapse' (which might save processed data) or 'search' (which might query processed events), nor does it specify prerequisites or exclusions. Usage is implied from the description but not explicitly stated.

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 adds useful context about the tool being 'deterministic' and 'essential for multi-session agent logic,' which helps understand its reliability and use case. However, it lacks details on permissions, rate limits, error handling, or what the return format looks like (e.g., structured memories vs. raw text), leaving gaps for a tool with 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.

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

The description is highly concise and front-loaded, with three sentences that each earn their place: the first defines the core action, the second explains its importance, and the third gives usage timing. There's zero waste or redundancy, making it easy for an agent to parse quickly.

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 (memory retrieval with 3 parameters) and lack of annotations and output schema, the description is adequate but has clear gaps. It covers purpose and usage context well, but without annotations, it should ideally disclose more about behavioral traits like response format or limitations. The description is complete enough for basic understanding but falls short of fully compensating for 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?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain query formatting or agent_id implications). Baseline score of 3 is appropriate as the schema does the heavy lifting, but no extra value is added.

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 ('retrieves past context and decisions') and identifies the resource ('past context and decisions'). It distinguishes from siblings like 'search' by focusing on deterministic retrieval of historical data rather than general searching. However, it doesn't explicitly differentiate from 'process_text' or 'save_to_synapse' in terms of memory vs. processing/storage operations.

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 the tool ('Call before responding when prior context, preferences, or decisions may exist') and highlights its role in 'multi-session agent logic.' It implies usage for memory retrieval scenarios but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools like 'search' for non-deterministic 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: it describes the default scope as 'agent (fail-closed)' and explains cross-agent transfer with 'tenant' scope, which clarifies access control behavior. However, it doesn't cover other behavioral traits like rate limits, error handling, or what 'Neural Handover™' entails operationally, leaving gaps for a tool with 5 parameters.

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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds key usage details. Both sentences earn their place by providing essential information without redundancy. It could be slightly more structured by explicitly listing modes, but overall it's efficient and clear.

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 (5 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose and key usage guidelines but lacks details on behavioral aspects like return values, error cases, or how 'Neural Handover™' works. Without an output schema, the description should ideally hint at what's returned (e.g., memories as objects), but it doesn't, leaving gaps for effective agent use.

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 mentions 'default scope is "agent" (fail-closed)' and 'pass scope="tenant" to enable cross-agent context transfer', which slightly elaborates on the 'scope' parameter. However, it doesn't provide additional meaning for other parameters like 'mode' or 'query', sticking close to the baseline.

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: 'Recall memories via Neural Handover™.' It specifies the action (recall) and resource (memories), distinguishing it from siblings like 'save_memory' or 'list_memories'. However, it doesn't explicitly differentiate from 'recall' (a sibling tool with a similar name), leaving some ambiguity.

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 usage: it explains the default scope ('agent') and when to use 'tenant' scope for cross-agent context transfer. It mentions multiple modes (temporal, semantic, etc.) but doesn't specify when to choose one mode over another or compare to alternatives like 'search' or 'recall' (sibling tools), missing explicit when-not/alternatives guidance.

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, the description carries full burden and adds valuable behavioral context: it discloses encryption (AES-256-GCM), processing steps (PII redaction, intent validation, deduplication), and the alias relationship. However, it lacks details on permissions, error handling, or response format, leaving gaps for a mutation 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 concise and front-loaded, with two sentences that efficiently cover key points: encryption, processing steps, and the alias. No wasted words, though it could be slightly more structured for clarity.

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 mutation tool with no annotations and no output schema, the description provides moderate context: it covers security and processing behaviors but misses details on permissions, response format, or error handling. Given the complexity, it's incomplete but not entirely inadequate.

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. The description adds no additional parameter semantics beyond implying 'content' is encrypted and processed, but this is minimal value over the schema's descriptions. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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: 'Save a memory with AES-256-GCM encryption' specifies the verb (save) and resource (memory) with security context. It distinguishes from siblings like 'store_memory' by mentioning encryption and processing steps, though it doesn't explicitly differentiate from 'save_to_synapse' beyond noting it's an alias.

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?

No explicit guidance on when to use this tool versus alternatives like 'store_memory' or 'save_to_synapse' is provided. The mention of 'Alias for save_to_synapse' implies an alternative but doesn't specify when to choose one over the other, leaving usage context unclear.

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 adds useful context about encryption, redaction, validation, and deduplication, which are behavioral traits beyond basic storage. However, it lacks details on permissions, rate limits, error handling, or what 'persists' entails (e.g., overwrite vs. append), leaving gaps for a mutation 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 a single, dense sentence that efficiently covers key aspects (purpose and processing steps) without fluff. It's front-loaded with the core action ('Persists...') and avoids redundancy. However, it could be slightly more structured (e.g., breaking into clauses) for clarity, preventing a perfect score.

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 no annotations and no output schema, the description partially compensates by detailing processing behavior. However, for a 6-parameter mutation tool, it lacks information on return values, error cases, or operational constraints (e.g., storage limits). It's adequate but has clear gaps in context for safe and effective use.

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 no specific parameter semantics beyond implying 'content' is the memory to store. It doesn't explain relationships between parameters (e.g., how 'type' interacts with processing) or provide examples, meeting the baseline of 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 tool's purpose: 'Persists user preferences, task progress, and facts' with specific processing steps (encryption, redaction, validation, deduplication). It distinguishes from siblings like 'recall' (retrieval) and 'search' (querying) by focusing on storage. However, it doesn't explicitly name the sibling alternatives for differentiation, keeping it at a 4 instead of 5.

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 no guidance on when to use this tool versus alternatives. It mentions processing steps but doesn't specify scenarios, prerequisites, or exclusions (e.g., compared to 'process_text' or 'recall'). This lack of explicit usage context results in minimal guidance for an AI agent.

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 the behavioral trait of 'full-text matching' and scope ('entire memory pool'), but lacks details on permissions, rate limits, error conditions, or what the search returns (since no output schema exists).

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 concise sentences with zero waste—the first explains the core functionality and differentiation, the second provides usage guidance. Every word earns its place.

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 no annotations and no output schema, the description adequately covers purpose and usage but lacks details on return values, error handling, or operational constraints. It's complete enough for basic understanding but leaves gaps for a search tool.

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 no additional parameter semantics beyond what's in the schema, meeting the baseline for high 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 specific verbs ('search', 'queries') and resources ('cross-agent memory', 'entire memory pool'), and explicitly distinguishes it from the sibling tool 'recall' by contrasting scopes ('single agent' vs 'entire memory pool').

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 this tool ('ideal for finding related context across agents, projects, or time periods') and when not to use it (vs 'recall' for single-agent scoping), naming the alternative tool directly.

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 exist, so the description bears full responsibility for behavioral disclosure. It reveals that the tool requires an admin token with timing-safe comparison, returns zero PII, and operates on aggregated operational metrics. This is transparent, though it could explicitly state it is a read-only operation.

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?

Description is brief and front-loaded with the main purpose. Every sentence adds value: admin-only nature, metrics returned, authentication requirements, and data privacy. No unnecessary words.

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 moderate complexity and full schema coverage, the description is mostly complete. It specifies required authentication, return metrics, and privacy properties. However, it could mention that the output is read-only and whether any pagination or limits apply, but these are minor omissions.

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?

Input schema describes both parameters (admin_token, window_hours) with full coverage. The description adds context beyond the schema: the token must match an environment variable, timing-safe comparison, and default window values. This adds meaningful guidance.

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?

Description clearly states it is an 'Admin-only SLO observability report' that returns specific metrics (percentile latencies, error rates, per-tool breakdown). This specific verb+resource distinguishes it from all sibling tools, which are unrelated.

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 indicates it is admin-only and requires authentication, providing clear context for use. While it does not explicitly state when not to use it or list alternatives, the unique purpose and sibling distinctiveness imply appropriate 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?

With no annotations provided, the description carries the full burden and discloses key behavioral traits: encryption (AES-256-GCM), processing steps (PII redaction, intent validation, deduplication), and the alias relationship. However, it doesn't cover aspects like error handling or performance, 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 and key features in two efficient sentences, with no wasted words. Every phrase adds value, such as specifying encryption and processing steps, making it highly concise 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 (encryption, processing steps) and no output schema, the description covers the core behavior but lacks details on return values or error cases. With no annotations, it's adequate but incomplete for full agent understanding, scoring as minimum viable.

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 parameters. The description adds no specific parameter information beyond implying 'content' is stored securely, which aligns with the schema but doesn't provide extra semantic value, meeting the baseline for high 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 specific verbs ('store context, preferences, or facts') and distinguishes it from siblings by mentioning it's a 'canonical alias for save_memory/save_to_synapse', which helps differentiate it from those similarly named tools.

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?

It provides clear context on when to use this tool by specifying it's for storing encrypted content with processing steps like PII redaction, but it doesn't explicitly state when not to use it or name alternatives beyond the alias reference, which limits full guidance.

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