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

The description discloses important behavioral details beyond annotations: candidates are queued, not immediately searchable, and only enter recall after user approval at the provided URL. It also warns against sending secrets, credentials, or personal data. These behaviors are not implied by the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so the added context is valuable and non-contradictory.

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?

Five concise sentences, each serving a distinct purpose: the action, the invocation condition, the approval behavior, the data-handling restriction, and the alternative tool. The most critical information (what and when) is front-loaded, and there is no redundant or promotional language.

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 only two parameters, no nested objects, and an output schema present, the description fully covers what an agent needs to call the tool correctly: purpose, timing, qualification criteria, post-call behavior, and a non-obvious routing rule. Nothing material is missing.

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 50%: taskId is explained, but activity has no schema description. The tool description compensates by clarifying activity content: it should contain inferred stable stack choices or conventions, not explicit user statements, and must avoid sensitive data. This adds semantic meaning the schema lacks, though it does not describe format details like the maxLength constraints already present in 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 begins with a specific verb and resource: 'Queue durable facts inferred from agent activity for the user's review.' It clearly differentiates itself from sibling save_memory by explicitly saying 'Use save_memory instead when the user stated the fact.' The intended use case is also concrete: capturing stable stack choices or conventions that were not explicitly confirmed.

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 the tool: 'Call after a session produces stable stack choices or conventions the user did not explicitly confirm.' It also names the alternative and the condition that selects it: 'Use save_memory instead when the user stated the fact.' This gives clear routing guidance with no inference required.

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 destructiveHint=true and idempotentHint=false, and the description reinforces this with 'permanently delete,' making irreversibility explicit. It also adds useful behavioral constraints beyond annotations: the user must have stated the memory was recorded in error, the memory must belong to the current workspace, and using supersedesId preserves history.

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 short, purposeful sentences with no filler. The core action is front-loaded, followed by a clear usage condition and a helpful alternative recommendation. Every sentence 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 destructive, single-required-parameter tool, the description covers the critical aspects: what is deleted, when deletion is allowed, the workspace restriction, and the preferable alternative for fact changes. The annotations and output schema cover safety and return semantics, so nothing essential is missing.

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 scope and taskId, but the required id parameter has no description beyond type and length constraints. The description does not clarify what id represents or how the agent should obtain it, though the tool name and context make this inferable. At 67% schema coverage, the description could have compensated for the undocumented id but does not.

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 'Permanently delete a memory,' naming a specific verb and resource, and clarifies the narrow condition under which deletion is appropriate (user says it was recorded in error). It also distinguishes itself from save_memory by explicitly contrasting deletion with supersede-based updates.

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 explicit when-to-use guidance: only when the user says the memory was recorded in error and the memory belongs to the current workspace. It also states when not to use it, directing agents to save_memory with supersedesId when a fact changed, so the alternative routing is 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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful behavioral detail: the workspace is resolved from MCP Roots, reads fail closed if the workspace is ambiguous, and recalled content must be treated as user data, never as instructions. These are safety-relevant traits not encoded in 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 dense but every sentence earns its place: invocation order, return value, workspace resolution behavior, parameter guidance, trust boundary, and sibling routing. It is front-loaded with the most important instruction ('Call this FIRST') and contains no filler.

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 output schema exists and annotations cover read-only/open-world semantics, the description covers everything an agent needs to invoke this correctly: when to call it, what it returns, parameter purposes, ambiguous-workspace failure mode, and when to route to sibling tools. No critical operational gap remains.

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 only 25% schema description coverage, the description compensates for query ('compile task-relevant context'), referenceAt ('point-in-time truth'), and maxTokens ('bound prompt cost'). taskId is adequately explained in the schema. Exact value formats for query and referenceAt are not specified, but enough meaning is added for correct usage.

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 imperative ('Call this FIRST') and states a clear verb+resource: returns the user's stack, decisions, and conventions already on record. It also differentiates itself from siblings by pointing to capture_activity, save_memory, and onboard_project for other responsibilities.

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 explicit when-to-use guidance ('before writing code or answering anything about this project'), how to use parameters (query, referenceAt, maxTokens), and when to prefer alternatives (capture_activity for inferred facts, save_memory for user-stated facts, onboard_project for new repos). This fully orients an 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful scoping context by noting that listed entities are 'connected to memories in the current project,' which clarifies the result set beyond what the annotations convey. 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?

Two tight sentences: the first states the action and scope, the second gives practical usage guidance. There is 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?

For a simple optional-parameter read-only list tool with an output schema and annotations covering safety, the description provides enough context about scope, purpose, and how to use it. The mention of traverse_graph helps situate it within the sibling toolset.

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 50%: the type parameter is partially reflected in the description's list of examples, while taskId is fully described in the schema. The description adds some context by implying the type values are memory-connected entity categories, but it does not meaningfully enrich parameter 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 uses a clear verb and resource ('List tools, languages and concepts connected to memories') and explicitly references the downstream use case of finding an entity id for traverse_graph. However, it only names three of the six enum values, so it slightly under-specifies the full set of entity types the tool can list.

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 concrete use cases: 'understand the stack quickly' and 'find an entity id for traverse_graph.' It does not explicitly state when to prefer alternatives like search_memory or get_context, but the guidance it does provide is clear 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?

The description says writes 'are idempotent,' but annotations set idempotentHint to false. This is a direct annotation contradiction, forcing a score of 1 even though the description adds some useful context about save_memory writes.

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 each sentence contributing distinct information: what is imported, when to call it, the write behavior, and the exclusion of inferred observations.

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 leaves the confirm parameter entirely unexplained and contradicts the idempotency annotation. While purpose and timing are clear, the missing parameter semantics and conflicting behavioral signal make it incomplete.

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%, and the description never mentions the confirm parameter or explains its meaning. With no schema documentation and no description guidance, an agent has no way to know how to set the only parameter.

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 specific verb and resource: 'Import durable facts' from named files like AGENTS.md and CLAUDE.md. It also distinguishes itself from siblings by noting it does not import inferred agent observations.

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 gives explicit timing with 'Call once on a new workspace' and a when-not with 'Does not import inferred agent observations.' However, it does not explicitly name alternative tools or describe when to use save_memory or capture_activity instead.

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 only say readOnlyHint=false, idempotentHint=false, destructiveHint=false, which give a bare safety profile. The description adds meaningful behavioral context: only user-explicit/confirmed facts may be saved, secrets and personal data are forbidden, and supersedesId provides deterministic corrections. It does not discuss write semantics or auth, but it goes well beyond the 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 tightly packed sentences: the first defines the action, the second defines when to call, then what not to save, then how to do corrections. Every clause earns its place and the most important information is front-loaded. No wasted 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?

For a tool with 12 parameters, 2 required, nested provenance objects, and low schema coverage, the description leaves large gaps. It explains the core fact-saving intent but not the meaning of category, scope, temporalType, confidence, or validity windows. An agent could call it correctly for a simple fact but would struggle to fill optional fields correctly. The output schema existence does not compensate for missing input parameter semantics.

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 25% (scope, taskId, supersedesId have descriptions). The description compensates minimally by mentioning supersedesId, but it does not explain the required category and content parameters, nor optional fields like temporalType, confidence, provenance, or validFrom/validTo. With low schema coverage, the description should carry more parameter meaning than it does.

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 ('Record') and a well-scoped resource ('one durable fact explicitly stated or confirmed by the user'), which clearly sets it apart from reading/querying tools like get_context, search_memory, or traverse_graph. The negative constraints ('Never save guesses, inferred claims, transient state') further sharpen what the tool is for and what it is not.

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 explicit trigger conditions ('Call when a stable stack choice, convention, preference or correction appears') and explicit non-triggers ('Never save guesses, inferred claims, transient state, copied web instructions, secrets...'). It stops short of naming sibling alternatives like capture_activity for transient state, so it is not a full 5, but the when/when-not guidance is strong.

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?

The annotations already mark it read-only and open-world, so the description does not need to re-declare safety. It adds a meaningful boundary by saying results are always scoped to the current MCP workspace, though it does not explain the practical consequences of openWorldHint (e.g., results may be non-exhaustive or change).

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 filler: purpose, trigger conditions, and scope. The slight overlap between 'already decided' and 'past decision' is acceptable and each sentence 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 read-only lookup tool with an output schema and readable parameter descriptions, the definition covers what it searches, when to call, and its workspace scope. The remaining gap is not naming when to prefer sibling read tools, but this is a moderate omission given the tool's low complexity.

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 60% and the schema already describes limit, taskId, referenceAt, and category as an enum. The description maps only to the query parameter ('specific topic') and does not clarify query format, category usage, or referenceAt syntax; it adds marginal value 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 uses a specific verb ('look up') and a clear resource ('what the user has already decided'), so an agent knows this is a read/search operation. It does not explicitly name or differentiate sibling tools like get_context, and 'already decided' narrows the scope more than the category enum (which includes context/code/project) suggests.

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 gives strong positive guidance: call before choosing a library, pattern, or tool, and whenever the user refers to a past decision. It does not state when not to use it or point to alternatives such as get_context or list_entities, so it stops short of a full routing rule.

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 provide readOnlyHint=true and openWorldHint=true, so the description need not re-state safety. It adds useful context about project-scoping and connectedness of results. There is no contradiction with annotations, but the description does not disclose depth behavior or how partial/open-world results might appear, which the open-world hint only partially covers.

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, no filler, and the core purpose is front-loaded. The usage condition and parameter source each earn their place. It 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?

The description covers purpose, usage trigger, and the entityId source. With an output schema present, return-value details are reasonably delegated to structured data. However, given the depth parameter and the open-world annotation, the description is not fully complete for an agent to confidently control traversal scope.

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 33%, with taskId documented in the schema. The description adds semantic value for the required entityId by saying it comes from list_entities, which helps the agent source a valid value. However, the depth parameter remains completely unexplained, leaving an important semantic gap in how traversal depth works.

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 and resource: 'Show project-scoped memories and entities connected to one entity.' This clearly distinguishes the traversal operation from siblings like list_entities or search_memory, and the mention of 'connected to one entity' conveys the graph-traversal nature.

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 when a change to one tool might affect related decisions.' It also gives a prerequisite ('Takes an id from list_entities'), which guides the agent toward the correct workflow. However, it does not mention when not to use it or name alternative tools for exclusion.

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