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

With no annotations provided, the description carries the behavioral burden. It discloses that memories are stored with auto-categorization and importance scoring, which are meaningful behavioral traits. It does not detail return values or effects on existing memories, but for a straightforward add operation this is adequate.

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 filler. The core action is front-loaded, and the second sentence provides immediately useful examples of appropriate content. Every part contributes to understanding 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?

The description establishes the tool's purpose, primary use cases, and key behaviors, and the schema provides the required content plus a type enum. However, with no output schema and low parameter coverage, an agent may be uncertain about optional parameters like tags, project, and how importance scoring interacts with the provided importance value. It is adequate but not 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 only 20%, so the description must compensate. It hints at 'type' and 'importance' via 'auto-categorization and importance scoring', but it does not clarify the 'tags' or 'project' parameters, nor the meaning and range of the importance score. This is insufficient coverage for a 5-parameter tool.

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?

States a specific verb ('Store') and resource ('a memory'), and describes the added behaviors of auto-categorization and importance scoring. This clearly differentiates it from sibling tools like memory_search, memory_list, and memory_forget.

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 second sentence provides clear context for when to use the tool by listing concrete content types: decisions, findings, debug insights, infrastructure details, user preferences, and session summaries. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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 behavioral disclosure burden. It adds useful context that deletion is never automatic, but it does not state whether deletion is permanent, what happens to linked memories, or whether any confirmation is involved. For a simple delete operation this is adequate but not fully transparent.

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 short sentences with no filler. The core operation is front-loaded, and the second sentence justifies the tool's existence by explaining why manual deletion may be necessary. 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?

For a single-parameter tool with no output schema, the description is nearly complete. It identifies the action, the target, and the typical use case. A minor gap is that it does not mention what happens after deletion or whether the operation is reversible, but those are not essential for invoking this tool 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 description coverage is 100%, and the only parameter, memoryId, is already clearly documented as 'The ID of the memory to delete.' The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description states a precise action ('Delete a memory by ID') with a clear resource and method. It is unequivocally distinct from sibling tools like memory_add, memory_search, and memory_list, so an agent can immediately identify this as the deletion operation.

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 gives clear guidance on when to use this tool: for outdated or incorrect information. It also notes that memories are never automatically deleted, which implies this is the manual cleanup mechanism. It does not explicitly name alternatives or exclusion conditions, but the sibling set makes the distinction obvious.

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 behavioral transparency burden. The verb 'Show' strongly implies a read-only informational operation, but side-effect freedom, authentication needs, and output format are not explicitly disclosed.

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, focused sentence that immediately states the tool's purpose. Every word earns its place, and there is no filler or repetition.

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 zero-parameter help-oriented tool, the description covers the essential output: server configuration and available tools. No output schema exists, but the description provides a sufficient picture of what the agent should expect.

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 zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. The description appropriately focuses on what the tool returns rather than parameter details.

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 uses a specific verb, 'Show,' and names the exact resources: 'server configuration and available tools.' This clearly distinguishes memory_help from its siblings, which all perform memory operations like add, link, search, list, forget, and profile.

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 this tool is for discovering server configuration and available tools, likely an orientation/help entry point. However, it does not explicitly state when to use this over siblings or when not to use it.

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 present, so the description carries the full burden. It does disclose the bidirectional nature of the link and the auto-linker threshold context, but it does not mention side effects like whether existing links are replaced, what happens if a memory ID does not exist, or whether the operation is idempotent. This leaves some behavioral ambiguity.

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 the core action front-loaded. The first sentence specifies the verb and object, and the second adds relevant contextual guidance without any filler or redundant phrasing.

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 two-parameter linking tool, the description covers its purpose, usage context, and a key behavioral nuance. However, with no annotations and no output schema, it does not specify error behavior or the return value, leaving minor gaps in what an agent might need to know.

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 already covers id1 and id2 with 100% coverage, giving the baseline of 3. The description adds meaningful semantic context by stating that the two memories are 'related' and that the link is bidirectional, implying the parameters are symmetric and order-independence. This goes beyond the schema's minimal 'First memory ID' and 'Second memory ID.'

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 uses a specific verb and resource: 'Link two related memories bidirectionally.' This clearly differentiates it from sibling tools like memory_add, memory_search, and memory_list, which handle other operations. The bidirectional detail adds precision to the 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?

The description explicitly states the condition: memories with similarity > 0.7 are auto-linked, and this tool is for 'connections the auto-linker missed.' This gives a concrete when-to-use and implies when not to use it, making the usage context unambiguous.

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 for behavioral disclosure. It does reveal that this is a browsing/pagination operation and that it filters by category rather than semantic meaning, but it does not mention sorting, return format, or how filters combine. This is acceptable for a low-risk list tool but not comprehensive.

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 with no filler. The core purpose and the key distinguishing use case are front-loaded, 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 five parameters, 0% schema description coverage, no annotations, and no output schema, this description leaves important gaps. An agent is not told what the response looks like, how filters interact, or what valid type values are. The description establishes purpose but not enough operational context for fully 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 description coverage is 0%, so the description must compensate. It mentions type, tags, project, and pagination, but does not explain the format or behavior of the tags array, possible type values, how filters combine, or the meaning of limit and offset beyond saying 'pagination.' The parameter semantics are therefore only partially clarified.

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 uses a specific verb ('Browse') with a clear resource ('memories') and identifies the filtering dimensions: type, tags, and project. It also explicitly contrasts itself with searching by meaning, which distinguishes it from the sibling memory_search tool.

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 clearly states when to use this tool: 'when you need to review all memories in a category rather than searching by meaning.' It names the alternative behavior but does not explicitly name memory_search as the alternative, so it falls just short of the strongest 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?

No annotations are provided, so the description carries the full burden. It only describes the tool's domain, not what happens on set (overwrite semantics), whether get/list have side effects, or any persistence or authorization behavior. The action enum supplies the operations but not their behavioral 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?

A single sentence with front-loaded purpose, concrete examples, and an explicit alternative. No filler or repetition of schema details.

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

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

Given the low complexity, the schema covers required parameters and allowed actions, and the description covers selection criteria. A minor gap is the lack of output or return information for the list action, but the action name and key-value domain make this largely self-evident.

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 already documents key ('Required for get and set') and value ('Required for set'), and the action enum lists valid actions. The description adds value by giving example keys and clarifying that values are structured preferences/settings, which helps an agent construct valid key/value pairs.

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 identifies the tool as a key-value store for user preferences and settings and gives concrete example keys (preferred_language, editor, timezone). It also distinguishes the target data type from general knowledge and names memory_add as the alternative, so an agent can tell it apart from siblings.

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 explicitly states when to use the tool ('Use this for structured data...') and when not to ('not for general knowledge'), directly naming memory_add as the alternative. This is specific and actionable, covering both positive and negative selection 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?

With no annotations, the description carries the full behavioral disclosure burden. It does say the search is semantic and returns results 'ranked by relevance,' which is useful. But it does not explicitly state that the operation is read-only or side-effect free, nor does it mention behavior for no results or how relevance scoring works. Adequate but not rich.

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

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

Three sentences with no wasted words: the core action is front-loaded, followed by usage timing, then a one-line statement about output order. Every sentence earns its place and the structure is ideal for quick parsing by an AI agent.

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 6-parameter tool with no annotations and no output schema, the description provides a strong high-level purpose and usage window but omits parameter semantics and output shape. An agent can issue a basic query, but may be unsure how tags, type, project, and min_score affect behavior or what fields the returned results contain.

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 only 17% (only query has a description), so the description must compensate. It does not explain tags, type, limit, project, or min_score. 'Ranked by relevance' hints at limit and min_score, and 'across all memories' suggests the default scope, but an agent cannot confidently use the filtering parameters based on the description alone.

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 opens with a specific verb-resource pair: 'Semantic search across all memories.' This clearly states what the tool does and distinguishes it from siblings like memory_list (which likely lists memories non-semantically). The added usage cues ('start of a session, before making decisions') reinforce its role as a context-retrieval tool.

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 is given for when to use the tool: 'at the start of a session, before making decisions, or when you need context about a topic.' However, it does not explicitly state when not to use it or name alternatives such as memory_list for exact listing, so it stops short of full exclusion logic.

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