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

No annotations are provided, so the description carries the full burden and largely fails. It doesn't state that this is a read-only/export operation, how 'full memory' is scoped, whether project filtering applies, or anything about the return format beyond 'as text'.

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 front-loaded sentence with no wasted words. It is efficiently sized, though arguably too terse for the missing behavioral and parameter context.

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 an undocumented project parameter, no annotations, and no output schema, the description leaves key questions unanswered: what scope is exported, whether project filters, and what the output looks like. It is not complete enough for confident invocation.

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

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

Schema coverage is 0% and the description never mentions the 'project' parameter. An agent cannot tell whether this exports all projects or a single one, so the description does not compensate for the schema gap.

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 resource and output form: it exports the full memory as text/markdown. The verb 'export' comes from the name rather than the description, and it doesn't explicitly distinguish itself from siblings like recall or get_context, but the format-based 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?

'To paste into an AI without MCP' implies a usage context, but it never states when to choose this over recall or get_context. There is no exclusion or alternative guidance beyond the implied 'no-MCP' scenario.

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 behavioral burden. 'Delete' implies irreversible destruction, but it does not state whether the removal is permanent or soft, what happens if the id does not exist, or whether any permission 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?

A single front-loaded sentence with the verb and resource first and the scoping parameter last. Efficient, though its brevity contributes to the missing behavioral detail rather than being purely economical.

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 one-parameter tool with no output schema the description is minimal but not unusable. However, with no annotations and no schema descriptions, the destructive semantics and error behavior remain undocumented.

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. 'By id' conveys only that the id selects the memory to remove; it adds no format, type, or validity details beyond the bare parameter name.

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 (delete) and resource (a memory), scoped by id. This is clearly distinguishable from siblings like remember (create) and recall (read), though the description 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?

No guidance on when to use this tool versus alternatives such as recall or remember. The intent is inferable from the verb, but there are no stated conditions, prerequisites, or exclusions.

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 burden, and it does disclose what content comes back (handoff + memories) and the ordering expectation. However it says nothing about scope/empty state (what if no project or no handoff exists), whether the call is read-only, or rate/cost characteristics of an aggregate fetch.

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-loaded with what it returns and immediately followed by the usage directive. Nothing extraneous.

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 2-param read tool with no output schema, the description covers intent and timing but omits scoping behavior (project default), return shape/size implications, and failure modes. Adequate to call, incomplete to call well.

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 only 50%; max_tokens is documented in the schema but 'project' is undocumented there. The description mentions neither parameter, so it fails to compensate for the gap — an agent cannot tell from the description whether omitting project yields a global or default-scoped context.

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?

Names the two things it returns (latest handoff + top memories), which is a specific resource pair rather than a tautology of 'get_context'. It implicitly contrasts with save_handoff/recall by being the read-and-prime entry point, but it never explicitly names a sibling.

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?

'Call first in every chat' gives an explicit, actionable trigger for when to use it. It stops short of naming alternatives (e.g., why not recall or list_projects first) or stating exclusions, so it is clear context without full routing 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 behavioral burden and delivers almost none of it: no statement that the operation is read-only, no pagination or scope behavior, no auth requirements, no hint of what a 'memory count' represents. Only the word 'Projects' plus a count vaguely implies a non-mutating enumeration.

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 words with zero filler — nothing redundant and the resource is front-loaded. It is terse almost to the point of being a label rather than a description, which keeps it from a 5.

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 is genuinely simple (no params, no nested schema), but there is no output schema, so the description is the only place the return value could be explained — and 'memory counts' is left undefined. With the safety profile also absent from annotations, the definition is only marginally 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?

The schema declares zero parameters, so there is nothing for the description to disambiguate; baseline for a no-param tool is 4. Nothing in the description contradicts or duplicates a parameter it does not have.

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 fragment 'Projects with memory counts' does identify the resource (projects) and the payload (memory counts), but it lacks a verb and never states that it lists or enumerates anything. It is also not distinguishable from the other read-oriented siblings (recall, get_context) beyond the resource noun, so purpose is only implied.

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 when-to-use guidance, no mention of alternatives among recall/get_context/export_markdown, and no exclusions. An agent must infer from the name alone that this is the discovery step before recalling memory.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing. 'Search' implies a non-destructive read, but there is no statement about whether results are scoped to a project, how results are ranked or paginated, whether an empty result is a failure, or what the limit applies to.

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?

It is a single short sentence with no filler and the core concept is front-loaded, which is structurally good. However, the brevity is the result of under-specification rather than disciplined editing, so it does not earn a 4.

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 4-parameter tool with zero schema description coverage, no annotations, and no output schema, the description is materially incomplete. An agent cannot tell how to scope the search by kind or project, nor what the limit does, from anything provided.

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% across 4 parameters, and the description only gestures at the query concept via 'keywords'. The kind enum (fact/preference/decision/task/note), the project scope filter, and the limit default/max of 5/30 are never explained, leaving three of four parameters undocumented in both schema and prose.

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 ('Search') and resource ('memory') plus the matching mechanism ('by keywords'), so the agent knows this is a retrieval tool rather than a write. It does not differentiate itself from the sibling get_context, which is presumably also a memory-read tool, so it stops short of a 5.

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

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

There is no guidance on when to use recall versus get_context, list_projects, or other siblings, and no mention of prerequisites or exclusions. The agent must infer usage entirely from the name and one-line description.

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 behavioral burden, and it discloses almost nothing beyond 'durable'. It does not say whether writes are deduplicated, append-only, scoped to a project, or how conflicts are resolved — all material for a persistence tool.

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

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

One short, front-loaded sentence with no filler; the verb leads and the accepted content types follow. It is efficient, though arguably too terse to be informative given the parameter surface.

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 persistence tool with no annotations and no output schema, the definition leaves too much unspecified: retention, project scoping, importance scale meaning, and duplicate handling are all absent. Nothing an agent needs to call it correctly is covered.

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% across 6 parameters, so the description would need to compensate. It enumerates four of the five kind enum values (omitting 'note', which is slightly misleading) but says nothing about importance, tags, project, or source semantics.

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

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

States a specific verb (Save) and the resource types it accepts (durable fact, preference, decision, task), which reads as a write-side memory tool. It does not name or contrast with siblings like recall or save_handoff, but an agent can still tell it apart by the persist-a-statement action.

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 guidance on when to use this over save_handoff, export_markdown, or recall, and no mention of prerequisites or when-not-to-use. The only implied usage is that the content must be a durable statement, which the agent must infer.

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 at all, the description carries the full burden of behavioral disclosure, and it says nothing about whether saving overwrites a prior handoff for the same project, whether writes are persistent, or what permissions are needed. For a mutation tool with zero annotation coverage this is a meaningful gap.

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 tight sentence with the action front-loaded and no filler; 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 3-parameter write tool with no annotations and no output schema, the description is too thin: it omits the project scoping behavior, the meaning of the optional parameters, and any indication of what happens on repeat saves.

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% (only 'summary' is documented), and the description mentions no parameters at all. It does not explain the 'project' grouping key or what 'from_model' is for, so it fails to compensate for the coverage gap.

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 clear verb+resource: 'Save a where-we-left-off summary'. The phrase 'for the next AI' makes the intent concrete and separates it from the storage/retrieval siblings (remember, recall). It does not explicitly contrast with the closest sibling, remember, so it stops short of a 5.

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

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

'for the next AI' implies the trigger is an end-of-session handoff, giving implied usage context. However, it never says when to prefer this over remember, nor when not to use it, leaving the agent to infer the distinction.

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