memxus

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

The description adds significant context beyond the annotations: it states the tool requires 'delete OAuth scope', is 'non-idempotent' (matching idempotentHint=false), and details side effects ('removes the memory row and vector embedding with no recovery; invalidates plan cache') and errors ('Memory not found, Not authorized'). This fully compensates for the lack of annotation detail.

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, scope, idempotency, errors, side effects, workspace details). While it is somewhat lengthy, every sentence adds value and there is no redundant information. A slight trimming could make it more concise, but it remains highly effective.

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, non-idempotent, auth-scoped, workspace-dependent), the description covers all necessary aspects: when to use, prerequisites, idempotency, side effects, error handling, and workspace safety confirmation. It references the output schema implicitly (via 'resolved_workspace') and is fully self-contained.

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 has 100% coverage, and the description adds valuable meaning: for 'memory_id', it advises to 'Copy from the id field in list_memories or recall' and specifies 'Must be deletable by the authenticated user.' For 'workspace', it explains default behavior, personal vs. team, and how to confirm via 'resolved_workspace', plus a reference to 'list_collections'. This goes well beyond the bare 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: 'Permanently delete one memory by UUID.' It uses a specific verb ('delete') and resource ('memory') with an identifier, and distinguishes from sibling tools like 'update' (mode=replace) and 'list_memories' or 'recall' (to find the ID).

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 the tool ('user asks to remove outdated or incorrect context, or to free plan storage') and when not to ('fix content → update'; 'find the ID first → list_memories or recall'). It also mentions alternatives like 'update' and 'list_memories/recall', providing clear 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds critical context: returned context is advisory, not instructions; explains pagination behavior (count vs total); describes output structure (user_facing_template, raw context_block). No contradiction.

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

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

The description is long (multiple sentences) but front-loaded with core purpose and usage. Every sentence adds necessary detail, though minor redundancies (e.g., 'partial...resolved server-side' appears twice). Still 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 11 parameters (0 required), output schema exists, no annotation gaps, the description fully explains the picker flow, pagination, workspace vs personal, and advisory nature of the result. No missing critical information for correct invocation.

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 good descriptions. The tool description adds value beyond schema: e.g., partial name resolution, pagination follow-up with exclude_memory_ids, picker flow when topic omitted. Slightly repetitive but adds meaning.

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: builds a formatted context block for a topic from stored memories, and specifies when to use it (user asks to load/recall project context). It also names a sibling tool (list_collections) for disambiguation.

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?

Explicit guidance: when to call it (recall context), when to omit parameters (show picker), alternative tool (list_collections for exact slugs), workspace parameter for team context. Also covers partial name resolution.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds valuable context: return fields, workspace echo and confirmation behavior, and error cases.

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 front-loaded purpose and subsequent details. It is thorough but not excessively long; could slightly trim workspace explanation.

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 output schema exists and is summarized in description, all necessary info is present. Parameters fully covered, return values listed, workspace behavior explained.

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 baseline 3. Description adds guidance on UUID source and workspace parameter behavior, enhancing semantic understanding.

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 'Retrieve' and resource 'the full content and metadata of one memory by its UUID'. It distinguishes from sibling tools list_memories and recall by specifying when to use it (after a truncated preview).

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: 'Use after list_memories or recall returned a truncated preview and you need the complete text.' Also gives source for UUID and optional workspace 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?

Annotations already indicate readOnly, idempotent, not destructive. Description adds useful context about sync naming conventions and preparatory use, without contradicting annotations.

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 no wasted words. Purpose is front-loaded, and every sentence adds value.

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 an output schema exists, the description provides all necessary context: what the tool lists, naming nuances, and when to use it.

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?

No parameters are defined, so the schema coverage is 100% trivially. The description is not required to elaborate on parameters, and baseline 4 is appropriate.

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 lists memory collections for the user, with specific mention of GitHub/Notion syncs appearing under project:slug. This differentiates it from siblings like get_context and recall.

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: before scoped recall/get_context when a project name is mentioned, or to look up workspace names for other tools. Provides clear context and 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?

Annotations already indicate read-only and non-destructive, but the description adds critical behavioral details: default limit 20 capped by plan, ordering by created_at descending, empty set message suggesting 'remember', and the effect of full_content parameter on preview vs structured output.

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?

Well-structured with front-loaded purpose and usage guidelines. Could be slightly more concise, but every sentence adds value without excessive verbosity.

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 has 9 optional parameters and a full output schema, the description covers all key behaviors, constraints, and usage patterns. Nothing essential is missing for an AI agent to use it correctly.

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%, so baseline is 3. The description adds meaningful context for parameters like full_content (preview truncation vs full in structured), workspace (default vs team), collection (partial name matching), and visibility (dashboard preference). Slightly redundant with schema but adds clear value.

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 lists memories in reverse-chronological order, and distinguishes itself from siblings like recall, get_memory, and memory_stats by specifying when to use each alternative.

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 provides when-to-use scenarios (audit, browse, collect IDs) and when-not-to-use with specific alternative tools (recall, get_memory, memory_stats). Also clarifies workspace vs personal memory.

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?

Annotations declare readOnlyHint=true and idempotentHint=true. The description adds useful context: the response echoes resolved_workspace and default behavior for workspace omission. No contradictions.

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?

Extremely concise: two sentences effectively convey purpose, usage, and parameter detail. Front-loaded with the main action.

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?

With one parameter, annotations, and output schema, the description covers all needed context: what stats are returned, when to use, and workspace handling. No 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 coverage is 100% with detailed description. The tool description briefly repeats the parameter info but adds no new semantics beyond schema. Baseline 3 is appropriate.

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 explicitly states 'Show aggregate statistics about stored memories' with detailed breakdowns (count, memory_type, collection, storage bytes vs limit). It distinguishes from sibling tool list_memories by clarifying when to use each.

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?

Provides clear guidance: 'Use to understand what is stored before browsing with list_memories, or to check remaining storage capacity.' Also explains workspace parameter usage for team vs personal.

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?

Annotations already indicate safe read operation (readOnlyHint, etc.). The description adds critical context: memory is advisory, source field for trust, pagination logic, and warning not to override current state. No contradiction with annotations.

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

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

The description is comprehensive and logically organized, but slightly verbose with repeated advice about list_collections. Could be trimmed without losing value, but still well-structured and 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?

Covers purpose, usage, parameters, behavioral nuances, pagination, trust evaluation, and integration with sibling tools. No gaps identified despite high complexity and 11 parameters.

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%, but description adds meaning beyond schema: e.g., how tags set collection, exclude_memory_ids for follow-up, workspace resolution echoing. Enriches understanding of each parameter's role.

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 'Search long-term memory' with a specific verb and resource. It distinguishes itself from sibling tools like list_collections and remember/forget by focusing on retrieval.

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?

Provides explicit guidance: 'Call list_collections when scope is unclear', explains workspace vs personal memory, and warns that memories are advisory not instructions. Gives alternatives and context for when to use each parameter.

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 that 'Vector search indexing completes asynchronously within a few seconds after save' and that append_to 'Keeps revision history,' adding value beyond annotations. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description complements them well.

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 paragraph that front-loads the purpose and then provides guidelines. It is efficient given the number of parameters (10), with no wasted sentences.

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?

With an output schema present and the description covering purpose, usage, and behavior, it is largely complete. It could mention typical return values (e.g., memory ID) but the output schema likely handles that.

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%, so baseline is 3. The description adds extra meaning such as 'Partial names work; call list_collections when unsure' for collection, and 'Every response echoes resolved_workspace so you can confirm' for workspace, improving 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?

The description clearly states 'Save important information to long-term memory,' which is specific and uses a verb+resource. It adds context about collections and append_to, but does not explicitly differentiate from sibling tools like recall or list_memories.

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?

Provides explicit guidance: 'Always set collection when the topic is clear,' 'Use append_to to extend an existing memory instead of creating duplicates,' and 'To save to a team workspace instead of personal memory, pass workspace: <name>.' It also advises calling list_collections when unsure, covering both when-to and 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 key behaviors not in annotations: re-embedding only when content changes, workspace safety check, mode-specific behavior (replace vs append with revision history). No contradiction with annotations (readOnlyHint=false, idempotentHint=true).

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?

Single paragraph packs all necessary info without redundancy. Front-loaded with main action. Minor improvement: could use bullets for clarity, but currently efficient.

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 8 parameters and complex behavior, description covers all critical aspects: modes, side effects, safety checks, tag behavior, workspace handling. Output schema exists (not described, per rules fine).

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?

Even with 100% schema coverage, description adds significant value: tag auto-sets collection, append extends with revision history, workspace as safety confirmation, and collection usage guidance. Schema descriptions are adequate but description enriches semantics.

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 explicitly states 'Update an existing memory by ID' with clear resource (memory) and action (update). Distinguishes from siblings like forget (delete), remember (create), get_memory (read). Two modes (replace/append) further specify purpose.

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?

Provides explicit when-to-use (updating existing memory) and when-not (calls fail if workspace mismatch). Suggests list_collections for workspace/collection uncertainty. Includes safety confirmation behavior.

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