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

Annotations already declare readOnlyHint=true, and the description adds that it reads files without modifying them. It also discloses the conditional side-effect of calling the observer model when judge=true, which goes beyond the annotation structure. This is useful behavioral context beyond the structured hints.

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 front-load the primary purpose and then add the key behavioral note. No redundant wording or recitation of schema fields. Every sentence earned 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?

The tool has 28 optional parameters and an output schema exists, so return format does not need explanation. The description covers the core purpose and safety profile. However, with many filter options and no direction on how to combine or prioritize them, an agent may struggle to use the tool effectively. Adequate at a high level but missing meaningful usage depth.

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 28 parameters and only 39% schema description coverage, the description must compensate, but it only explains the judge option. It gives no guidance for trust_bias, ownership_scope, visibility filters, exclude/include groups, widen_shared options, or other ambiguous parameters. The single judge clarification is marginal but insufficient for the parameter complexity.

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-resource pair ('Mine recurring memories') and the outcome ('reviewable context candidates'), which clearly distinguishes this from search/explain/remember siblings. An agent can infer this is a discovery/distillation tool, not a lookup or mutation 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?

No explicit guidance on when to use this tool versus siblings like memory_search or memory_pack, and no when-not conditions. The purpose statement implies it's for recurring-pattern mining, but the description does not describe scenarios where an alternative would be more appropriate.

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, so the description's 'Fetch' is consistent. The description adds a behavioral detail by stating the output includes 'surrounding timeline context', which goes beyond the read-only hint. However, it does not disclose details like depth controls, filtering behavior, or what 'surrounding' means in practice. Given the annotations, this is acceptable but minimal.

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 one sentence, which is concise and front-loaded. However, for a tool with 26 parameters and an output schema, this brevity borders on under-specification. It is not verbose, but it fails to earn its place by providing only a trivial summary that could apply to any memory-related 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?

This tool is complex (26 params, output schema present), yet the description only states a bare function. It does not explain the timeline context behavior, the meaning of depth_before/after, or how the output relates to the input. An agent would need to inspect the schema and output schema to understand the tool's purpose and behavior, making the description nearly useless for effective 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?

With 26 parameters and only 35% schema description coverage, the description was expected to compensate by explaining key parameters. It mentions none of them – not the required 'ids', nor the depth controls, filters, or the 'include_observations' flag. The description adds zero semantic value beyond the schema, which is already sparse for many parameters.

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 clear verb ('Fetch') and resource ('memories by ID'), and adds 'surrounding timeline context' which hints at differentiating from sibling tools like memory_get (which likely fetches without context) and memory_timeline (which might show a timeline without specific IDs). It is specific enough to convey the core function, though it does not explicitly name alternatives.

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

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

There is no guidance on when to use this tool versus memory_get, memory_timeline, or other siblings. No conditions, exclusions, or alternatives are mentioned. An agent must infer the appropriate use case solely from the phrase 'surrounding timeline context', which is insufficient given the variety of sibling tools.

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

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

The annotations already establish readOnlyHint=true and openWorldHint=false, so the description does not need to re-assert safety. It adds the 'detailed scoring breakdown' behavior, which is useful context, but it does not disclose how results are selected or whether a prior search is required.

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 efficient sentence with no filler and the core idea is front-loaded. It is concise, though for a tool with 26 parameters it could afford a second clause to clarify usage without becoming verbose.

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 high parameter count, low schema coverage, and many sibling tools, a one-sentence description is insufficient. It does not explain how to supply 'search results' (via ids vs query vs filters), how parameters combine, or how the scoring breakdown is structured, leaving too much to guesswork.

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 35% across 26 parameters, and the description names none of them. The agent gets no help understanding how 'ids', 'query', 'kind', or the many filter parameters behave, so the description does not compensate for the poorly documented 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 states a specific verb and resource: it explains search results and provides a detailed scoring breakdown. This distinguishes it from memory_search, which would return the results themselves, though it does not explicitly name any sibling or contrast with them.

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 phrase 'Explain search results' implies this tool is for post-search analysis rather than for finding memories, but there is no explicit guidance about when to use it versus memory_search, memory_get, or memory_expand. The intended workflow is left to inference.

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 mark the tool as destructive and idempotent, but the description adds meaningful behavioral context: the delete is soft, it is not a secure erasure, it does not inherit the default project, and optional filters must match or the call returns not_found. This genuinely helps predict side effects beyond the schema and annotations alone.

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 compact and front-loaded: it states the core soft-delete behavior first, then the safety-relevant distinction from secure erasure, then the project/filter condition. There is no filler or redundancy.

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

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

For a tool with 23 parameters and 26% schema coverage, the description is not fully complete: it is enough for the minimal call 'memory_id only', and an output schema exists, but it does not explain the rich filter parameter space. This leaves gaps for any agent that needs to scope the delete with project, visibility, trust, actor, or workspace parameters in a meaningful way.

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 very low at 26%, so the description should compensate. It only clarifies memory_id and the general behavior of 'optional filters must match'; it does not explain the many filter parameters such as ownership_scope, visibility, trust_bias, workspace filters, or the include/exclude arrays. Thus it leaves most parameters functionally undocumented.

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 names a precise verb and resource: 'soft-delete a memory by exact ID' and immediately clarifies its effect ('no longer appears in normal retrieval') and limits ('not secure erasure'). This is enough for an agent to distinguish the tool from its read/search siblings without opening the schema.

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 the usage: call it when you want to forget a specific memory by ID. It adds useful caveats about the default project and optional filters matching, but it never gives explicit when-to-use versus alternatives or when-not-to-use guidance, so it relies on the agent to infer 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 readOnlyHint=true already covering the safety profile, the description adds meaningful behavioral detail: it does not inherit the default project, optional filters constrain the lookup, and a mismatch returns not_found. These are non-obvious behaviors that an agent cannot derive from the annotations alone.

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, front-loaded with the core operation and immediately followed by the two most important behavioral constraints (default project behavior, not_found on mismatch). No filler or repetition of the input schema.

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 the core invocation, the not_found outcome, and a key project-scoping gotcha, and an output schema exists so return values do not need explanation. Still, given the high parameter count and low schema coverage, an agent receives very little guidance on when or how to use the many filtering parameters. It is minimally viable 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 26%, so the description must compensate for the many undocumented parameters. It does not: it only says 'optional filters constrain the lookup' without explaining specific parameters like trust_bias, widen_shared_when_weak, personal_first, or the include/exclude filter families. Property names are partially self-explanatory, but the description provides almost no semantic help for the 23-parameter surface.

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: 'Fetch one memory by exact ID.' This clearly distinguishes the tool from sibling search/recent tools that perform broader lookups, and the exact-ID emphasis makes its narrow purpose unambiguous.

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

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

The description implies usage context – an agent should call this when it has a specific memory ID – and it provides a useful caveat about not inheriting the default project. However, it does not explicitly say when to prefer this over memory_search, memory_get_observations, or other siblings, nor does it give exclusion criteria. Usage guidance is implied rather than 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context: it does not inherit the default project, and missing/filtered-out IDs are silently omitted rather than reported as not_found. This goes beyond the annotations and helps an agent predict result behavior.

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, front-loaded with the primary action and resource, followed by two critical behavioral caveats. No wasted words; 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?

The tool has 23 parameters and an output schema, and the description covers the core fetch-by-IDs behavior plus two important caveats. However, with 26% schema coverage and many filter parameters, an agent may not know how filters interact with the ID-based fetch or what the output schema contains. The description is adequate for the primary use case but incomplete for advanced filtering scenarios.

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 26%, so the description carries some burden for parameter meaning. The description clarifies the key 'ids' parameter semantics (exact IDs, omission behavior) and the 'project' parameter (does not inherit default). However, most of the 23 parameters remain undocumented in both schema and description, so the description only partially compensates for the low 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 states a specific verb ('Fetch') and resource ('multiple memories by exact IDs'), and distinguishes itself from a default-project behavior. It is clear enough to separate from siblings like memory_get (singular) and memory_search (query-based), though it does not explicitly name those 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?

The description implies usage: use this when you have exact memory IDs and want to fetch multiple memories. It notes that it does not inherit the default project, which is a useful context signal. However, it does not explicitly state when to prefer this over memory_get or memory_search, nor does it mention 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 declare readOnlyHint=true and openWorldHint=false, and the description doesn't contradict them. The description adds that it is a learning/instruction tool, which is mild behavioral context, but does not specify what the agent will actually receive from it. Given annotations, this is acceptable.

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, zero fluff. The purpose is in the first line and the usage guidance in the second. This is as lean as a description can be.

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 no parameters and has an output schema, the description is sufficient for a call-first help tool. It could mention what the output format is, but the presence of a schema covers that, and the simple nature of this tool does not demand more.

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, so the input schema carries no information to enhance. Per the rubric, a no-parameter tool starts at 4, and the description doesn't need to add parameter details that simply don't exist.

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: 'Learn how to use codemem memory tools'. The verb 'learn' plus resource and the specific 'first if unfamiliar' hint distinguish it from the sibling tools like memory_search and memory_schema, although it doesn't explicitly name a non-overlap.

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 says 'Call this first if unfamiliar', giving a clear condition for when to invoke this tool. It does not list alternatives or state when not to use it, but the 'first' ordering provides enough guidance for a meta/help tool.

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 openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it discloses the automatic fallback from semantic to keyword-only search when embeddings are unavailable, and the compact mode's token-saving behavior. This is useful operational transparency.

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 and front-loads the core purpose and fallback behavior before the routing guidance. It is efficient, though the second sentence could arguably be more specific about which sibling to use for what. 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?

Given the tool's complexity (27 parameters, output schema present), the description is adequate but not complete. It explains the search strategy and routing, but an agent would still be uncertain about what the output block looks like, how the many filter parameters interact, and what 'formatted context block' means concretely. The output schema helps, but the description doesn't bridge the gap for the large parameter surface.

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 37%, so the description carries some burden for parameter meaning. The description explains the core 'context' parameter and the 'compact' behavior, but most of the 27 parameters (e.g., trust_bias, personal_first, widen_shared_when_weak) are undocumented in both schema and description. The description adds value for the main parameters but doesn't compensate for the large undocumented surface.

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 ('Build') and resource ('formatted context block for a concept or task'), and distinguishes it from siblings by naming memory_search and memory_search_index for exact identifiers. It could be slightly clearer about what 'formatted context block' means, but the core purpose is clear.

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 says 'Use for conceptually relevant context; use memory_search or memory_search_index for exact identifiers,' which provides a clear when-to-use and alternative. It doesn't enumerate all sibling alternatives (e.g., memory_recent, memory_timeline), but the primary routing guidance is present.

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 establish readOnlyHint=truecars, so the read-only nature is covered. The description adds 'newest first' ordering, which is useful, but it does not disclose defaults, time-window semantics, filtering behavior, or pagination, leaving significant behavioral gaps.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently states the action and ordering, though it is so brief it edges toward under-specification rather than ideal conciseness.

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

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

With 23 parameters and a complex filtering surface, a one-sentence description leaves much unsaid about intended usage. The presence of an output schema helps, but the description alone does not adequately orient the agent to the tool's full context.

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 very low (roughly 3 of 23 properties have descriptions), and the tool description adds no parameter meaning. Most parameters, including visibility, trust, workspace, and widening controls, are undocumented in both description and 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 'Return recent memories, newest first' uses a specific verb and states the ordering behavior, making the core purpose clear. It does not explicitly differentiate from sibling tools like memory_search or memory_get, so it loses a point for lacking sibling contrast.

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

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

The description implies usage for fetching recent memories but provides no guidance on when to use this tool instead of alternatives, nor any exclusions or context. No sibling tool comparisons or use-case nuances are given.

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=false and idempotentHint=false, and the description's 'Create a new memory' is consistent with those. The description adds little behavioral detail beyond that—no mention of persistence, side effects, or availability—though the existing annotations carry most of the safety burden.

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 a clear verb-first structure; the core action is front-loaded and there is no filler. 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 simple create tool with full schema coverage, an output schema, and annotations, the description is nearly complete. The main gap is that it never addresses the related memory_learn tool, which could leave an agent unsure which creation route to 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 five parameters, including the kind enum and confidence range. The description's use cases hint at suitable memory content but do not add meaningful parameter-level detail 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 opens with a specific verb and resource ('Create a new memory') and gives concrete use cases ('milestones, decisions, and notable facts'). It is clear, but it does not explicitly distinguish itself from the similarly named sibling memory_learn, so it falls short of full sibling differentiation.

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

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

It provides explicit usage context: 'Use for milestones, decisions, and notable facts.' However, it does not say when not to use this tool or name an alternative such as memory_learn or memory_get, so the when-not guidance is missing.

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 include readOnlyHint=true, indicating this is a safe read operation. The description adds that the tool returns schema, which is useful context. However, it doesn't disclose additional behavioral aspects such as whether the schema reflects the latest state or if there is any caching. With annotations covering safety, the description adds some value but not rich detail, so a 3 is appropriate.

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, clear sentence that efficiently conveys the tool's purpose. It is appropriately concise and front-loads the key information. No redundancy or fluff, so it earns a 4. Could potentially be slightly more specific but is already 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 has zero parameters and an output schema exists, the description need not detail return values. The description clearly states the content of the schema (kinds, fields, filters) which is the main information an agent needs. It is complete for a metadata-retrieval tool, though it could mention if it's the full or partial schema.

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

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

The tool has zero parameters, so the schema provides no parameter definitions. The description explains what the tool returns (kinds, fields, filters), which is the core semantic information. Since there are no parameters to describe, the description is effective at conveying the purpose, earning a baseline of 4.

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 it returns the memory schema with kinds, fields, and filters. This is clear and specific about what the tool does. However, it doesn't distinguish it from siblings like memory_explain, which might also provide schema-related information. The description is clear but not fully oriented against 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?

The description implies that this tool is used to retrieve schema information, which is a common first step before using other memory tools. It doesn't explicitly mention when to use it over alternatives like memory_explain, or when not to use it. There is clear context but no explicit exclusions or alternatives, so the guidance is implied rather than explicit.

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 adds some behavioral context beyond the annotations by clarifying that its output is full body text of matching memories. However, it doesn't reveal other behavioral traits like ordering, match semantics, scope defaults, or performance implications, so it is only moderately more transparent. The absence of contradiction with the readOnlyHint/openWorldHint annotations is not an issue here.

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 exceptionally concise: two sentences, each contributing essential information. The first sentence states when and what the tool does; the second covers output behavior and the sibling alternative. No filler, no repeated 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 tool's high complexity (24 parameters, only 29% schema description coverage), the description leaves out major needed context such as the semantics of many filtering fields, search ordering, and how results are scoped. It does provide a basic high-level contract, but for a tool of this complexity, the description is not complete enough to guide correct use without further investigation.

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

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

The input schema's description coverage is only 29%, so the description would need to compensate, but it does not discuss any of the many filter parameters. The tool provides no parameter semantics beyond the schema's minimal descriptions, leaving many associated parameters (e.g., trust_bias, ownership_scope, visibility arrays) unexplained, making this a weak area for correct agent selection and use.

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 action ('keyword-search') and a specific resource ('memories'), clarifying it is a text-search tool for exact terms or identifiers. It also differentiates from the sibling tool by declaring that it returns full body text, whereas memory_search_index returns compact candidates.

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 tells the agent when to use this tool: when the user knows exact terms or identifiers and needs full body text. It also provides an alternative by naming memory_search_index and the condition that selects it ('only need compact candidates'). This is explicit guidance on when not to use this tool.

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, so the description doesn't need to restate safety. It adds useful behavioral context: returns compact entries without bodies, and suggests follow-up expansion. However, it doesn't explain filtering semantics, trust_bias, or how the 24 parameters affect results, which would be valuable for a search tool with many filters.

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, front-loaded with the core purpose and a clear follow-up action. Every word earns its place; no fluff 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?

Despite having an output schema, the tool has 24 parameters with only 29% schema coverage and no enums. The description does not explain the filtering model, trust/visibility semantics, or how to combine parameters. For a complex search tool, this is incomplete: an agent cannot reliably know what filters exist or how they interact.

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 29%, and the description does not compensate. It mentions query and the compact return format, but does not explain the many filter parameters (kind, project, scope_id, visibility, trust_bias, ownership_scope, include/exclude lists, widen_shared_*). With 24 parameters and most undocumented, the description leaves the agent guessing about how to construct effective searches.

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 performs keyword search over memories and returns compact entries with IDs and titles, which distinguishes it from memory_get and memory_get_observations. It does not explicitly name sibling search tools like memory_search or memory_recent, but the focus on exact terms/identifiers and compact results gives reasonable differentiation.

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

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

The description says to use it when you know exact terms or identifiers, and tells the agent to expand selected IDs with memory_get or memory_get_observations. It does not explicitly say when not to use it or name alternative search tools like memory_search, but the guidance is clear enough for basic selection.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the behavioral constraint of a chronological window around an anchor, which is useful context beyond the annotations. However, it does not disclose behaviors like default depth (depth_before/depth_after default 3), ordering direction, or how anchor selection resolves when both memory_id and query are provided. 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 a single 13-word sentence with no filler. It front-loads the core operation ('Get a chronological window') and then adds the key modifier ('around an anchor (by ID or query)'). Every word earns its place, and the structure is immediately scannable.

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?

Despite having an output schema and read-only annotations, this is a highly complex tool (26 parameters, many filters, 0 required). The description fails to explain how to invoke it correctly: whether memory_id or query is required, how they interact, what the default window sizes are, or how filtering parameters shape results. An agent would need substantial external knowledge to call this tool effectively, so the description is not complete for the tool's 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 description coverage is only 35%, so the description must compensate for the many undocumented parameters (26 total, 0 required). It only clarifies that the anchor can be specified 'by ID or query', which maps to memory_id and query. It says nothing about depth_before/depth_after, filters (visibility, trust, scope, workspace), or the many include/exclude arrays. This is minimal added meaning over the schema and leaves most parameters semantically unexplained.

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 names a specific verb ('Get'), resource ('memories'), and a distinctive scoping concept ('chronological window around an anchor'). It differentiates from siblings like memory_recent and memory_search through the anchor/window framing, though it does not explicitly name any sibling. This is clear but slightly below a 5 because the differentiation is implicit rather than stated.

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 when to use the tool: when you need memories around a specific anchor in chronological order. However, it gives no explicit guidance about when to prefer this over alternatives such as memory_search or memory_recent, and no exclusions or prerequisites. Usage context is present only by inference.

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