CP Memory

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal an upsert behavior ('add or update') and a default fact category, which is useful. But it fails to state what 'update' actually does — overwrite, merge, or version — or how confidence affects storage, which matters for a write tool with zero annotation coverage.

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 with the verb–resource pairing front-loaded in the first sentence. The second sentence earns its place by flagging the two parameters that differ from a plain fact write.

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 an 8-parameter tool with 3 required fields and zero annotations, this is under-specified. The output schema covers return values, but the description still lacks conflict behavior, required-parameter semantics, and selection criteria versus memory_update and memory_correct. An agent would need to infer most operational details from parameter names alone.

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 for the schema's bare parameter titles. It adds meaning for category ('explicit') and content ('optional long-form payload') but says nothing about the three required parameters entity, property, value, nor about tags, confidence, or content_type. The core semantics of the required triple remain 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?

States a clear action and resource: 'Add or update a memory fact.' It also flags two meaningful capabilities — explicit category and optional long-form content. However, it does not differentiate from the sibling memory_update, whose name suggests the same 'update a memory fact' operation.

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

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

Provides no guidance on when to use this tool versus the 38 siblings. In particular, it does not distinguish itself from memory_update or memory_correct, leaving the agent to guess which write path is appropriate. Context signals show siblings exist, but the description itself offers no selection criteria.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Add or update' usefully signals upsert behavior rather than a simple create, but it does not explain whether existing aliases are replaced, whether the canonical entity must already exist, how tags are handled, or what side effects occur.

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 short sentence with no filler and the action verb is front-loaded. It is appropriately concise for a simple CRUD tool, though it is terse enough that some semantic burden falls on the 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?

Given no annotations, minimal parameter descriptions, and a simple but nonzero input schema, the description is too thin to fully guide correct invocation. It leaves ambiguous what a canonical entity is, how aliases are stored or updated, and whether tags are merely metadata or affect behavior.

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

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

The schema has 0% description coverage and only title-level parameter names. The description adds some meaning by framing 'entity' as canonical and 'alias' as the associated synonym, but it says nothing about the 'tags' parameter, required vs optional roles, formatting, or allowed values.

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 action ('Add or update') and a specific resource ('an alias for a canonical entity'), so an agent can tell this is alias-management rather than generic memory writes. It does not explicitly differentiate from related tools like memory_alias_list or memory_update, but the resource focus 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?

There is no guidance on when to use this tool versus alternatives such as memory_alias_list or memory_add. The description implies the purpose but provides no context about prerequisites, exclusions, or the preferred situation for calling 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?

With no annotations, the description must carry the behavioral disclosure burden. It conveys that the operation is a read-only listing and that the entity argument is an optional filter, but it does not describe default limit behavior, ordering, or what an omitted entity returns beyond the implicit unfiltered list. This is adequate for a simple list tool but not richly transparent.

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

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

A single front-loaded sentence states the operation and the optional filter with 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 simple list tool with no required parameters and an output schema present, the description covers the core invocation concern: what is listed and how it can be filtered. The only real gap is explaining the exact form of a canonical entity value, but the output schema and known domain conventions reduce that burden.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to the entity parameter by defining it as a canonical-entity filter, but it says nothing about limit, leaving its semantics to be inferred from the schema title and default. Partial compensation keeps this at a middling score.

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 ('List') and resource ('aliases') and immediately states the optional filter ('by canonical entity'), making the tool's role obvious. This clearly distinguishes it from sibling tools like memory_alias_add, which performs a different action on the same resource.

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 to enumerate aliases—and states the filtering condition, but it gives no explicit guidance about when to choose this over alternatives such as memory_alias_add or memory_list, nor any exclusions. It is adequate but leaves the usage decision 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?

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly warns that 'delete' removes rows and that 'mark_wrong' is the safer governance choice, and it frames the operation as preview-or-apply. This is meaningful behavioral disclosure beyond the bare schema, though it is light on details about consequences of mark_wrong.

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 well-structured sentences deliver the essential purpose and safety guidance without filler. The key distinction between preview and apply is front-loaded, and the important preference for mark_wrong over delete is placed immediately after.

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 required parameters, safe defaults, and an output schema, the description is largely complete for correct invocation. It explains what the tool targets, how to act, and which action is safer. The only notable omission is a fuller explanation of what 'mark_wrong' does to the record, but this is not fatal for using the tool safely.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning to the 'action' parameter by defining valid intentions ('mark_wrong' vs 'delete') and implies the dry_run/preview distinction. However, it does not describe the 'limit' parameter or explicitly map 'Preview or apply' to the dry_run boolean, leaving some semantics to inference.

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 ('Preview or apply cleanup') and a specific resource ('auto-extracted noise records that look like implementation explanations rather than real user memory'). This clearly distinguishes the tool from the broader memory management siblings by naming the exact kind of data it targets.

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 guidance on how to invoke the tool safely: 'Prefer action=mark_wrong for safer governance; use delete only when you really want to remove rows.' It also conveys preview-vs-apply semantics. It does not explicitly name alternative sibling tools, but the usage context is clear.

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 behavioral burden. It conveys that this is a read/heuristic operation ('Find possible conflicting memories') and hints at non-determinism with 'possible', but it does not disclose whether results are tentative, whether it performs any state changes, or how conflicts are ranked or returned. However, the simple read-only nature is largely inferable.

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

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

The description is a single focused sentence that front-loads the verb and resource, then adds the two key conflict categories. There is no redundancy, and every word contributes to understanding the tool's purpose.

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 simple: one optional parameter and an output schema is present, so return value documentation is covered. However, the absence of usage guidance and any parameter semantics leaves just enough ambiguity that the description is minimally viable rather than 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 0%, and the description does not mention the 'limit' parameter at all. The schema only shows it is an integer with a default of 50, leaving its meaning and effect on the conflict-finding behavior completely 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 uses a specific verb ('Find') and a specific resource ('possible conflicting memories'), and enumerates the two categories it covers: duplicate facts and personal-memory contradictions. This distinguishes it clearly from the many sibling memory tools, especially listing and retrieval tools.

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 does not state when to prefer this tool over alternatives, nor does it mention any exclusions. While the purpose implies it is for surfacing conflicts, an agent is given no guidance about how it relates to memory_review, memory_personal_review, memory_probe, or other analysis-oriented siblings.

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

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

No annotations are provided, so the description carries the full burden of disclosing side effects. It states that the memory is marked and value may be replaced, but it does not reveal whether prior values are preserved, whether reasons are stored, whether the operation is reversible, or what happens to linked/related memories.

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 wasted words. It conveys the core action, the allowed status values, and the optional value replacement efficiently.

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 primary action and the optional value replacement, which is enough to make a basic call correctly. However, with no annotations and no param descriptions, the 'reason' field and the exact semantics of replacing the value remain under-specified, leaving room for agent uncertainty.

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 for all four parameters. It adds meaning to 'status' by listing allowed values and to 'value' by calling it a replacement, but 'id' and 'reason' are left entirely unexplained, leaving a significant 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?

The description uses a specific action verb ('mark') and a clear resource ('a memory'), and enumerates the possible status values: corrected, stale, wrong, scoped, or confirmed. This makes the tool's purpose immediately obvious and distinguishes it from nearby siblings like memory_update or memory_remove.

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 status list implies scenarios where the tool should be used, such as flagging a memory as stale or wrong. However, there is no explicit guidance about when to prefer this tool over memory_update or memory_remove, and no exclusions are 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?

With no annotations provided, the description carries the full disclosure burden. It usefully reveals a side effect beyond a simple record: the decision is 'mirror[ed] into facts with strong metadata.' However, it does not disclose reversibility, idempotency, failure modes, or what the mirroring actually entails, leaving meaningful behavioral gaps for a write operation.

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 main verb and resource up front. It is efficient and readable, though 'with strong metadata' is vaguely worded and adds little actionable guidance.

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 an output schema and simple string parameters, the definition is thin for a tool with no annotations and zero schema coverage. It omits usage routing vs. sibling tools, parameter-level guidance, and the implications of the mirroring side effect, leaving an agent to guess at several operational details.

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 for undocumented parameters, but it does not. It never explains what title, context, decision, or rationale should contain or how they relate to the 'mirror into facts' behavior. The parameter names are self-explanatory, but the description adds no semantics beyond them.

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 ('Record') and resource ('an architecture or technical decision'), making the core purpose clear. It implicitly differentiates from siblings like memory_add, memory_personal_add, and memory_task_set by restricting content to decisions, though it never names those alternatives explicitly.

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

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

The description gives clear context about content type ('architecture or technical decision'), which implies when to use the tool, but it does not state exclusions or point to alternative tools (e.g., memory_add for general facts, memory_personal_add for personal info). Usage is inferable 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?

No annotations are provided, so the description must carry the behavioral burden. 'List' implies a non-destructive read and 'most recent first' adds a useful ordering detail, but the description does not mention behavior around the limit parameter, pagination, or any filtering/scope attributes.

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

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

The description is a single focused sentence with no filler. The core action and ordering are stated directly, making it easy to process quickly.

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

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

For a simple read-only list tool with one optional parameter and an existing output schema, the description covers the essential behavior and ordering. It is slightly sparse on parameter semantics and selection context, but it is largely complete for invoking the tool correctly.

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

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

The input schema has 0% description coverage, and the description never mentions the 'limit' parameter. The schema only provides a title and default value, so the agent gets minimal semantic guidance; the description should have compensated 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 clearly names the operation: listing recorded decisions. It also specifies the ordering ('most recent first'), and the resource type 'decisions' distinguishes it from siblings like memory_list or memory_decision_add.

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 alternatives such as memory_list, memory_workflow_list, or memory_decision_add. The description states what it does but not the conditions that should lead an agent to select it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the tool can either preview or apply consolidation and describes the operation as 'conservative,' which is useful. However, it does not say what changes are made, whether the original episode is modified or retained, whether the operation is reversible, or what side effects applying consolidation may have.

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 short sentence with no filler. 'Preview or apply' is front-loaded and immediately communicates the two modes, and the phrase 'conservative Episode consolidation into long-term personal memories' efficiently conveys scope. 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 tool with four parameters, no annotations, and zero schema-level parameter descriptions, this description is too thin. It leaves dry_run semantics implicit, ignores limit and subject, and provides no guidance about the output or the consolidation process. The presence of an output schema helps, but the description alone is not enough for an agent to invoke the tool correctly across its modes.

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 does not name or explain any of the four parameters. 'Preview or apply' loosely maps to dry_run, and 'Episode' hints at episode_id, but limit and subject are completely unexplained. The description does not compensate for the lack of parameter documentation 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 states a specific action ('Preview or apply') and a specific resource ('conservative Episode consolidation into long-term personal memories'), so an agent can tell this is about consolidating episodic memories rather than adding, searching, or reviewing them. It is not a tautology and it adds some scope, though it does not explicitly differentiate itself from related sibling tools like memory_personal_derive or memory_review_apply.

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 no guidance on when to use this tool versus its many memory-related siblings. It does not mention alternatives, prerequisites, or situations where consolidation should be avoided. The only implicit context is that both preview and apply modes are available, so an agent must infer when this tool is 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?

No annotations are provided, so the description carries the burden. 'Explain' strongly implies a read-only operation, and 'including meta, payload, and relations' gives some insight into what the explanation contains. However, it does not explicitly confirm that no memory mutations occur or describe any side effects.

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 short, front-loaded sentence with no filler. Every word adds meaning, and it is appropriately sized for the tool's apparent simplicity.

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

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

Given no annotations, zero schema descriptions, and multiple look-up-like sibling tools, the description is incomplete. It does not explain how to identify a memory record, what an 'explain' result looks like beyond three fields, or when this tool is preferable to memory_inspect, memory_probe, or memory_recall.

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 for the three parameters. It does not explain how 'id', 'entity', and 'property' relate to selecting a memory record, whether they are alternatives or combined, or why all are optional. The parameter names are self-descriptive but the selection semantics are ambiguous.

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

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

The description uses a specific verb and resource: 'Explain a memory record' and names the included aspects ('meta, payload, and relations'). It clearly states what the tool does, though it does not explicitly distinguish itself from similar sibling tools like memory_inspect or memory_probe.

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 alternatives. It does not state whether to use it for debugging, for understanding stored relations, or as a read-only diagnostic. No exclusions, prerequisites, or alternative tool references are provided.

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 explicitly states the operation is 'non-destructive', which is critical behavioral context. It also clarifies the report covers the current memory.db and includes restore probes, signaling read-only analysis. It does not disclose details about output size or side effects, but the core safety behavior is clearly communicated.

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 leads with the verb and key safety qualifier ('non-destructive'), then efficiently enumerates the report's contents. Every phrase adds useful information.

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 main purpose and contents adequately, and an output schema exists so return values need not be described. However, there is no usage guidance or parameter explanation, and the meaning of 'governance acceptance report' is not elaborated; the tool is complete enough to call with defaults but not fully self-explanatory.

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 'limit' parameter. The parameter itself is a simple defaulted integer, but because the description does not clarify what the limit applies to (e.g., number of samples per section), the agent is left to infer its meaning.

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

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

The description states a specific verb ('Build') and resource ('governance acceptance report over memory.db'), and lists concrete report contents: auto-extract review queue, conflict samples, corrected samples, and restore probes. This makes the tool's function clear and distinct from most siblings, though it does not explicitly name any alternative or exclude other tools.

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 is provided about when to use this tool versus the many sibling tools like memory_stats, memory_health, or memory_conflicts. There is no mention of prerequisites, typical scenarios, or 'use X instead' instructions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Return' implies a read-only operation, which is some signal, but the description discloses nothing else—no side-effect profile, no mention of what 'active task' refers to, no cost or failure caveats. Minimal value beyond what the phrase 'health' already suggests.

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 front-loaded sentence with zero filler. 'Return' leads, and the four returned data items are packed into 13 words. 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 zero-parameter tool with an output schema, the description need not document return structure, and the four returned domains are stated. However, the unexplained acronym 'CP' and the absence of any routing guidance across 38 siblings leave the description minimally viable but incomplete for confident selection.

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 schema already documents everything and the baseline of 4 applies. The description correctly adds no parameter noise, and names the four data domains it returns, which meaningfully orients the agent toward the output.

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 ('Return') and names four concrete resources: CP Memory health, migration state, FTS state, and active task. This is clear and specific, not a tautology, but it does not explicitly differentiate itself from close siblings like memory_stats or memory_maintenance.

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 is given on when to use this tool versus alternatives such as memory_stats, memory_maintenance, or memory_task_get. Among 38 siblings, an agent is given no decision rule for selecting 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?

With no annotations, the description carries the behavioral burden. 'Inspect' strongly implies a read-only operation and 'user-friendly way' suggests a human-readable result, which is useful. However, it does not explicitly state whether there are side effects, permissions, or formatting caveats, so transparency is partial.

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 concise sentence with no filler. It front-loads the main action and adds a relevant detail about the output, though slightly more structure could clarify parameter usage.

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 an output schema and optional parameters, the description leaves out essential invocation context: how to identify the target record, when to prefer this over memory_probe/memory_explain, and any behavioral caveats. The tool is simple-sounding, but the undocumented parameters 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 adds no meaning to the three parameters. An agent cannot determine what id, entity, and property represent, how they combine, or which are needed to identify a memory record. This is a critical 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?

The description uses a specific verb ('Inspect') and resource ('a memory record'), and clarifies the output scope by mentioning preview, payload, and relations. It is clear enough to distinguish from list/add/update/remove siblings, though it does not explicitly differentiate from similar inspection tools like memory_probe or memory_explain.

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 alternatives. The description does not state any preconditions, exclusions, or preferred contexts, leaving the agent to infer applicability from the tool name alone.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects, but it only says the operation 'create[s]' a relation. It does not explain whether the relation is idempotent, whether existing relations are replaced, or what constraints apply to the relation or record kinds.

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 states the core purpose with no filler words. Every word contributes, and the structure makes the tool's action 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 relatively simple flat parameters, this is a write tool with five required arguments and no annotations; the description is too sparse to tell an agent how to construct a valid call. It lacks parameter meaning, usage conditions, and behavioral 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 0%, so the description must compensate for the five required parameters. It only adds that two records are involved, leaving relation values, kind semantics, and the relationship between source and target unexplained beyond the schema's property names.

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 ('Create') and resource ('explicit memory relation between two records'), making it clear this tool links records rather than creating records or listing links. However, it does not explicitly differentiate itself from sibling tools such as memory_alias_add or memory_add, relying on the term 'relation' to carry the distinction.

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 is given about when to use this tool instead of related sibling tools, nor any conditions or prerequisites such as requiring the source and target records to already exist. The only usage signal is the general purpose implied by the 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?

With no annotations provided, the description is the sole source of behavioral disclosure. 'List explicit memory relations' communicates a read-only operation and introduces the concept of 'explicit' relations, but it does not explain filtering behavior, ordering, pagination, or what happens when no filters are supplied.

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 or redundant wording. It is appropriately brief for stating the high-level purpose, though it sacrifices useful detail that would make it more helpful.

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

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

Given five optional parameters, no annotations, and zero schema description coverage, the one-line description is not sufficient for an agent to understand how to invoke the tool correctly. The presence of an output schema helps with return values, but the description still omits essential information about what 'explicit memory relations' means and how the optional parameters affect the listing.

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 does not mention any of the five parameters or how they influence the results. The agent must infer from parameter names alone that relation, source_id, target_id, source_kind, and target_kind act as filters, which the description fails to clarify.

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 ('List') and a clear resource ('explicit memory relations'), which makes the core purpose understandable. However, it does not explicitly contrast with sibling tools like memory_list or memory_link_add, so differentiation relies on the tool name and resource wording rather than the description itself.

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 no guidance on when to use this tool versus memory_link_add, memory_list, or memory_search. There are no alternative suggestions, exclusions, or context clues beyond the bare act of listing relations.

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 behavioral burden. It clearly indicates a read-style listing operation and 'recent' implies recency ordering, but it does not explicitly state read-only behavior, how 'recent' is defined, or how the limit interacts with ordering. This is acceptable but not richly transparent.

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

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

One short, front-loaded sentence with no filler. It states the core operation and the optional filter in minimal 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?

Although an output schema exists and the tool is simple, the description leaves important context unstated: category semantics, default/pagination behavior, and especially how this list differs from memory_search, memory_recall, and the other memory_* list tools. For a tool with no annotations, this is a notable completeness gap.

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?

Input schema has 0% description coverage, so the description must compensate. It clarifies that 'category' filters the listed facts, but it never explains 'limit' beyond the schema title/default and does not specify category value formatting. The compensation is incomplete for a low-coverage 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 names a specific verb ('List'), resource ('facts'), and scope ('recent'), and specifies an optional category filter. This is clear but it does not explicitly distinguish memory_list from sibling tools like memory_search or memory_recall, so no point for active 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?

No guidance is provided about when to use memory_list versus alternatives such as memory_search, memory_recall, or memory_personal_list. The description states only what the tool does, not the context in which it is the right choice.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does disclose state mutation (backfill, rebuild) plus the potentially destructive 'optionally expire low-value records' path. However, it never mentions the dry_run default of true, the safety consequences of setting expire=true, what qualifies a record as low-value, or whether expiration is reversible.

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 zero filler: the main verb and resource come first, followed by a compact colon-led list of operations. It is efficient, though the brevity sacrifices the safety context that a mutating maintenance tool warrants.

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?

An output schema exists, so return-value coverage is not required, but annotations are absent and schema parameter coverage is 0%, leaving the description as the sole behavioral source. It fails to explain limit, dry_run and its default, or the destructive consequences of expiration, so an agent cannot safely judge whether running this against production memory is appropriate.

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, but it only maps the concept of 'expire low-value records' to the expire flag. The limit parameter (a processing threshold) and the safety-critical dry_run parameter (which defaults to true) are left entirely unexplained, leaving an agent unable to reason about what a call will do.

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 identifies a specific verb and resource ('Run memory maintenance') and enumerates three concrete operations: backfill meta, rebuild indexes, and optionally expire low-value records. This reads as distinct from the many get/list/add siblings, though it does not explicitly differentiate from similarly maintenance-flavored siblings like memory_episode_consolidate and memory_auto_extract_cleanup.

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 is given on when to invoke this tool versus alternatives; the siblings include memory_episode_consolidate and memory_auto_extract_cleanup, which are plausible substitutes for a maintenance task, but no routing information is provided. The only usage signal is the generic phrase 'Run memory maintenance,' which implies intent but states no 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 of behavioral disclosure. It reveals 'add or update' semantics and memory types, but it does not explain whether an existing memory is overwritten, merged, or versioned, what validation occurs, whether it is destructive, or what side effects result. This is minimal for a state-changing 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?

The description is a single sentence with no filler, begins with the core operation, and packs the key distinguishing information into a compact list. 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 tool with 13 parameters, no annotations, and no parameter descriptions, this definition is incomplete. It does not explain update behavior, field meanings, valid memory_type values beyond the list, or how the optional fields interact. The output schema covers return values, but the input usage context remains largely lacking.

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 for the 13 undocumented parameters. It does add meaning for memory_type by listing the six allowed categories, but it leaves subject, key, value, scope, tags, details, sensitivity, confidence, validity windows, and numeric fields unexplained. This is insufficient given the low schema 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 clear action ('Add or update') and resource ('long-term personal assistant memory'), and it enumerates the allowed memory types. It does not explicitly differentiate this from sibling tools like memory_add or memory_personal_derive, but the word 'personal' plus the memory-type list provides reasonable orientation.

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 no guidance on when to use this tool versus alternatives such as memory_add, memory_personal_derive, memory_personal_resolve, or memory_update. It also provides no exclusions or selection conditions, so an agent must infer when this specific tool is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but does not disclose whether this creates, updates, or overwrites a memory, what 'linking back' entails, whether the episode must already exist, or any side effects or permission requirements.

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, tightly written sentence with no filler. It places the core action and primary object up front, making the tool's purpose immediately understandable despite the lack of supporting detail.

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 10 parameters, 5 required, zero schema descriptions, and no annotations, the description is far too sparse for an agent to reliably invoke the tool. It omits parameter semantics, usage context, and behavioral side effects, leaving the agent to guess at critical inputs and behavior.

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 does not explain any of the 10 parameters. Required fields like episode_id, memory_type, subject, key, and value are left entirely to the agent to infer from their names, without any additional context about their meaning or relationship to the derivation process.

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 ('Derive'), a clear resource ('a long-term personal memory'), and the source ('an existing Episode'), plus the linking behavior. This distinguishes it from sibling tools like memory_personal_add because it targets derivation from an episode rather than direct memory creation.

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 'from an existing Episode' implies the tool should be used when an episode already exists and needs to be converted into a long-term personal memory. However, it provides no explicit when-to-use or when-not-to-use guidance and does not name alternatives such as memory_personal_add or memory_add.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a listing operation and that filtering is optional, but it does not disclose ordering, pagination semantics behind the limit parameter, what values the six memory types take, or behavior on invalid input. 'List' is the only implicit safety signal.

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

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

A single sentence that front-loads the core action and scope with no filler. It could be improved by replacing the opaque 'six-model memory type' phrasing, but structurally it is tight and efficient.

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

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

The output schema exists, so return values are covered elsewhere, but an agent wanting to filter must know the six memory type values, which appear nowhere. Subject is undefined, limit's behavioral meaning is unstated, and sibling routing is absent. An unfiltered call works since all parameters are optional, but the documented filter path is effectively unusable.

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 for all three parameters. It only addresses memory_type, and only vaguely ('optionally filtered by the six-model memory type') without enumerating the six values. The limit and subject parameters receive zero meaning anywhere, leaving subject entirely undefined.

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 ('List personal assistant memories') and the 'personal' qualifier distinguishes it from the sibling memory_list. The filter capability is also mentioned. However, 'the six-model memory type' is unexplained jargon that an agent cannot resolve without external knowledge, and the description doesn't explicitly contrast it with memory_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?

No guidance is given on when to use this tool versus the 39 siblings, particularly closely related ones like memory_list, memory_search, memory_recall, or memory_personal_review. The 'personal' qualifier is the only implicit differentiator, and no exclusions or alternatives are named.

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 of behavioral disclosure. It goes beyond a simple mutation verb by explicitly stating that one winner is confirmed or merged and that other memories are marked stale, wrong, or scoped with audit links. It does not mention reversibility or consequences for existing links, but the core side effects are clearly disclosed.

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

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

The description is a single dense sentence with no filler. The action and resource are front-loaded, and every clause adds meaningful operational detail, making it both concise and efficiently structured.

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

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

This is a 7-parameter mutation tool with no annotations and no schema-level parameter descriptions. A single sentence is not enough to cover the operational nuances like how merging works, what values loser_status accepts, or how valid_until interacts with conflict resolution. The output schema exists but does not fill the semantic gaps in the parameters.

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

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

Schema description coverage is 0%, so the description must compensate, but it only conceptually maps to winner_id and loser_ids/loser_status. It does not explain the meaning or role of reason, scope, merged_value, or valid_until, leaving an agent unable to determine how to populate those fields correctly.

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 ('Resolve'), names the resource ('personal-memory conflict'), and explains the expected outcome: confirming or merging a winner and marking other memories stale, wrong, or scoped with audit links. It stops short of explicitly contrasting with sibling tools, but the 'personal-memory conflict' framing is specific enough to distinguish it from generic memory update/correct tools.

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

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

The description clearly implies this tool should be used to resolve personal-memory conflicts, but it never explicitly states when to use it versus alternatives like memory_conflicts or memory_personal_review. There is no when-not-to-use guidance, though the intended scenario is reasonably inferable.

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 must carry the behavioral disclosure burden. The wording 'Return ... dashboard' and 'review' imply a read-only, non-mutating operation, and the listed outputs suggest no side effects, but the description never explicitly states that it does not modify memory or whether any auth/rate constraints apply.

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 filler. Every phrase contributes: the output type, audience, and the four dashboard components are all stated efficiently.

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 output schema covers return shape, but the definition lacks parameter semantics and usage context. For a tool with no annotations and 0% schema coverage on parameters, the description is not enough to invoke it correctly with meaningful arguments.

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%, yet the description does not mention either parameter (limit or subject). The agent gets no help understanding how limit controls the dashboard or what values subject can take, making this a serious 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?

The description states a clear verb and resource: 'Return a user-facing personal memory review dashboard' with expected contents (counts, recent memories, conflicts, consolidation candidates). It does not explicitly compare against sibling tools such as memory_review_digest or memory_personal_list, so it falls just short of full 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?

No guidance is given on when to choose this tool over the many overlapping siblings (memory_review_digest, memory_review_inbox, memory_conflicts, memory_stats). There are no usage conditions, exclusions, or alternatives, so an agent must infer the appropriate context.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does disclose one meaningful behavior: 'Aliases resolve to the canonical entity first.' However, it does not mention other behavioral aspects like potential errors, whether results are ordered, or whether indirect/derived facts are included. For a simple read-only operation, the disclosed behavior is useful but limited.

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 short sentences with no filler. The primary purpose is front-loaded, and the alias-resolution behavior earns its place as additional useful detail. Every word contributes meaning.

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 simple one-parameter interface and the presence of an output schema, the description is reasonably complete. It states the core purpose and a key behavioral nuance. It could be more complete by clarifying entity identifier format, but the output schema likely covers return-value expectations, so the description suffices for a straightforward lookup tool.

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%, so the description must compensate for the bare 'entity' string parameter. The description adds that the parameter refers to an entity and that aliases are resolved to the canonical entity, which is genuinely helpful. However, it does not specify the accepted identifier format (e.g., canonical name, ID, natural language) or provide an example, leaving ambiguity.

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: 'Get all facts about an entity.' This clearly identifies a read-only lookup operation for a single entity, distinct from sibling tools like memory_list, memory_search, and memory_recall. The added note about alias resolution further clarifies the tool's unique behavior.

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 does not explain when to use memory_probe versus the many sibling tools such as memory_recall, memory_search, or memory_inspect. It implies usage by describing the operation, but it provides no explicit context, prerequisites, or exclusion guidance to help an agent decide among 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It does reveal a non-obvious two-stage behavior: primary CP Memory lookup followed by an auxiliary Codex memory lookup contingent on hit quality. It does not, however, clarify whether the operation is read-only, what 'hit quality' means, or how failures are handled.

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 dense sentence with no filler, and the core purpose is front-loaded. It earns its place by conveying the primary lookup order and the fallback condition, though it is terse to the point of omitting useful detail.

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?

While an output schema exists and reduces the need to describe return values, the tool has four parameters with no schema descriptions and sits among more than forty related tools. The description does not explain parameter usage, hit-quality thresholds, or how this recall entry relates to specific sibling tools like memory_search, making it incomplete for reliable agent selection.

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 for the four undocumented parameters. It only loosely implies allow_auxiliary via 'auxiliary background', and provides essentially no explanation of query, intent, or limit semantics. This leaves the agent dependent on parameter names and defaults alone.

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

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

The description identifies a concrete operation: a memory-first recall entry that consults the CP Memory main database. It is clear about the resource and action, but the phrase 'any memory-related issue' is broad and does not differentiate this tool from memory_search, memory_probe, or memory_inspect among the 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 gives a clear usage directive: for memory-related issues, check CP Memory first, then optionally consult auxiliary memory based on hit quality. However, it does not state when not to use this tool or mention any sibling alternatives, leaving the agent to infer the boundary between memory_recall and the many other memory_* 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?

With no annotations, the description carries the full burden and explicitly reveals a destructive action with its side effects: deletion includes metadata, payload, and graph links. It stops short of stating irreversibility or permission requirements, but delete semantics are clear and there is no contradiction.

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

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

A single, front-loaded sentence that names the operation and its useful scope. Every word earns its place; no filler or repetition.

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

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

For a tool with one required parameter and an output schema, the description covers the key behavioral details an agent needs: what is deleted and what is affected. It could mention finding the ID or that deletion is permanent, but the description is reasonably complete given the simplicity of the tool.

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 only property is an undocumented id string, so the description adds meaning by clarifying that the id identifies the fact to be removed. However, it does not explain how to obtain the ID, what format it uses, or what happens to dependent facts, leaving some ambiguity for a low-coverage 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 action (delete), a specific resource (fact), and how the operation affects related data (metadata, payload, and graph links). This clearly distinguishes it from mutation siblings like memory_update or memory_link_add, which operate on different resources.

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 wording makes it clear the tool is for deleting a fact once its ID is known, but it offers no explicit guidance about when not to use it or which alternative to choose, such as memory_update for edits or memory_list to find IDs. Usage is inferred 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It says the tool 'builds' a compact restored context, but does not disclose whether this is a read-only aggregation, whether it writes or mutates memory, whether it is idempotent, or what side effects might occur. This is a meaningful gap for a memory-related 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?

The description is one tight sentence, front-loads the main action ('Build a compact restored context'), and avoids filler. It is appropriately concise, though the terseness contributes to the lack of behavioral and parameter detail.

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 optional parameters and an output schema, the description covers the core purpose and when to use it. However, with no annotations, no schema descriptions, and no explanation of how the two parameters influence the restored context, the description leaves meaningful invocation details unstated. 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 0%, and the description does not explain the meaning or usage of 'prompt' or 'max_chars'. 'max_chars' is somewhat inferable from its name and default, and 'compact' hints at limiting output, but the description adds no explicit parameter semantics to compensate for the missing schema descriptions.

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 ('Build'), names a specific deliverable ('compact restored context'), and states concrete scenarios ('startup, history recovery, or project continuation'). It does not explicitly contrast with siblings like memory_recall or memory_search, so it falls short of full differentiation, but the purpose is specific enough for an agent to recognize when this tool is relevant.

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

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

The description gives clear contexts for use: startup, history recovery, or project continuation. It does not mention alternatives or exclusion conditions, but the stated scenarios provide enough situational guidance to make the intended usage reasonably clear.

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 behavioral burden and does add one important guarantee: it never physically deletes memory. However, it does not describe the side effects of the individual actions (e.g., whether confirm/wrong/stale update status or persist), reversibility, or any requirements beyond id/action.

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 tight sentences, with the action list front-loaded and the safety guarantee following. Every sentence carries distinct information and there is 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?

The description covers the core operation and a key safety property, and an output schema exists so return values are not a gap. However, the weak input schema and absent annotations leave scope/reason semantics and alternative-tool routing underexplained, so an agent may still need to infer important details.

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 for the input schema's missing parameter documentation. It adds meaning for action by listing its allowed values, but scope and reason are left undefined, and the relationship between the 'scoped' action and the scope parameter is only implicit.

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 ('Apply') and resource ('memory review action'), then enumerates the exact accepted actions, making the tool's function unambiguous. This differentiates it from review-related siblings such as memory_review_inbox and memory_review_digest, which list/digest rather than apply.

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 action list and 'review action' phrasing imply this is for acting on memory-review decisions, but the description never explicitly says when to use it instead of related tools like memory_correct or memory_remove. The 'never physically deletes memory' sentence provides a useful exclusion, though no alternative tool is named.

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 discloses the output format (Markdown) and the major content categories. It does not explicitly confirm that the tool is read-only, but 'Return a ... digest' strongly implies a non-mutating operation, which is reasonable disclosure for this kind of 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?

The description is a single, front-loaded sentence with no filler. It packs the output format and all major digest components efficiently, and every word contributes to understanding the tool.

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

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

The high-level purpose is clear and an output schema exists, so return-value details are not required. However, the two optional parameters are undocumented in both schema and description, and with dozens of sibling memory tools, some routing guidance would improve completeness.

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 'limit' or 'subject' parameters. While the names and defaults suggest an optional count and a scope, the description does not clarify how 'subject' filters the digest or exactly what 'limit' limits, leaving meaning mostly to inference.

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: 'Return a Markdown memory review digest'. It then enumerates the digest's components, which clearly distinguishes it from single-purpose siblings like memory_list or memory_conflicts.

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 does not state when to use this tool versus alternatives such as memory_review_inbox, memory_health, or memory_conflicts. The need for a combined digest is implied by the name and content, but no explicit when-to-use or when-not-to-use guidance is provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool 'previews items only and never deletes memory,' which is a strong, useful guarantee about side effects. It does not cover authorization, rate limits, or what 'actionable' entails, but the core preview-only behavior is clearly disclosed.

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

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

The description is two concise sentences with no filler. It front-loads the main purpose and immediately follows with the key safety qualifier. 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 description covers the essential operation and non-destructive nature, and an output schema exists for return values. However, it does not clarify the parameter semantics or differentiate this tool from the many review-related siblings. For a tool with two undocumented optional parameters and a large sibling list, this is adequate but not fully 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 0%, and the description provides no explanation of the 'limit' or 'subject' parameters. The schema only supplies defaults (5 and 'user'), not meaning. The agent must guess what 'subject' refers to and how limit behaves, so the description adds no value here.

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 and resource: 'Show a small actionable inbox for pending memory review.' This is specific enough to communicate the core function, and the 'previews items only' phrase further clarifies its non-destructive role. It does not explicitly name or contrast sibling tools, but the purpose is not ambiguous.

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

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

The description implies this tool is for viewing pending memory review items, and 'previews items only' suggests it is not for applying changes. However, it gives no explicit when-to-use guidance, exclusions, or reference to alternatives like memory_review_apply or memory_review_digest. Usage context is present but mostly 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?

With no annotations, the description carries the burden of behavioral disclosure. The word 'Return' and the informational nature of the content indicate this is a read-only introspection call, and the FTS availability note adds useful runtime context. It does not explicitly state that there are no side effects or mention potential error conditions, but for a zero-argument schema utility this is a reasonable baseline.

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 sentence with no filler, the main action is front-loaded, and the extra detail about FTS availability is a distinct piece of useful information. Every part of the 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 zero-parameter introspection tool with an output schema available, the description is nearly complete: it states both what is returned and a non-obvious detail (FTS availability). It could be slightly richer by clarifying that this is the standard entry point for schema questions or by expanding 'CP Memory,' but nothing critical is missing for correct invocation.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter meaning left for the description to add. This matches the baseline for tools with no 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 uses a specific verb ('Return') and a specific resource ('CP Memory schema explanations'), and adds a distinct secondary output ('whether FTS is available'). This makes it clearly distinguishable from siblings like memory_explain or memory_inspect, which focus on individual memory entries rather than the overall 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 when to use the tool: when an agent needs schema explanations or needs to know whether FTS is available. However, it gives no explicit guidance about when not to use it and does not mention alternatives among the many memory_* sibling tools, so the usage context is only implicit.

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

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

With no annotations, the description carries the full behavioral burden and does disclose meaningful traits: FTS usage 'when available' (implying a fallback path) and the OR/AND matching behaviors. This goes beyond what the schema shows. It does not, however, disclose the scope of the search, fallback behavior when FTS is unavailable, or result ordering.

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 entire description is a single efficient sentence with the verb and resource front-loaded and no filler. Every phrase — FTS, OR default, strict AND — adds information. It is appropriately sized for readability, though it is arguably under-sized given the number of undocumented parameters and siblings.

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 4 parameters with 0% schema coverage, no annotations, and a large sibling set containing several similar retrieval tools, the description is not complete enough for correct selection and invocation. An agent cannot tell when to prefer memory_search over memory_recall or memory_probe, nor what category filtering or limit behavior entails. The presence of an output schema helps, but the selection and parameter gaps remain.

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, but it only partially does. It clarifies the mode parameter (OR default vs strict AND matching) and implicitly covers query, yet it says nothing about the limit or category parameters, and it never spells out the accepted mode values. For a tool with 4 parameters fully undocumented in the schema, this is insufficient.

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 ('Search memories') and adds distinctive technical details: FTS-based matching, OR ranking by default, and strict AND as an alternative. This is clearly more than a tautology and gives the agent a concrete sense of the operation. However, it stops short of explicitly differentiating from retrieval siblings like memory_recall and memory_probe.

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 is given on when to choose memory_search over the numerous retrieval-adjacent siblings (memory_recall, memory_probe, memory_list, memory_inspect). The description explains matching semantics but never states a use case, exclusion, or condition that would route an agent to this tool versus an alternative.

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?

There are no annotations, and the description only says 'Get memory statistics,' which implies a read operation but provides no details on whether the computation is expensive, whether results are cached, or what specific statistical measures are returned. The description adds little beyond the tool name and does not carry the behavioral disclosure 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?

The description is a single, front-loaded sentence with no filler. Every word contributes to specifying the verb, resource, and scope, making it easy to parse quickly.

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

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

For a zero-parameter tool with an output schema, the description is largely complete: it states the resource and the categories covered. However, it lacks any contextual hint about how this differs from the memory_health or memory_list tools, leaving a small but real completeness gap.

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 baseline is 4. The description adds value by enumerating the data categories covered by the statistics, which helps an agent understand the scope of the result even though no arguments are needed.

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 ('Get') and identifies the resource ('memory statistics') with an explicit category list: facts, payloads, decisions, workflows, aliases, and relations. It is clear what the tool does, though it does not explicitly distinguish itself from memory_health or the various memory_list 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 is provided about when to use this tool versus alternatives such as memory_health or memory_list. An agent must infer that this is a roll-up statistics tool rather than a subscription or health check, which leaves usage context unclear.

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 of disclosing behavior, but it only states the action. It does not explain side effects, persistence, idempotency, or what happens to the current task state after completion.

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, direct sentence with no filler or redundancy. It is appropriately sized for a simple one-parameter tool and front-loads the main action.

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

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

The phrase 'current task' is undefined, and the description does not explain how the task was selected or what completing it entails. Although an output schema exists, the behavioral and contextual gaps leave the agent under-informed.

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 explain the 'result' parameter, but it merely calls it a 'result summary,' adding little beyond the parameter name. It does not clarify optionality, expected format, or whether an empty summary is acceptable.

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: 'Mark the current task as complete with a result summary.' It clearly identifies the operation, though it does not explicitly contrast with sibling tools like memory_task_set or memory_task_get.

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 alternatives, nor any mention of prerequisites such as how 'current task' is established. The agent must infer usage entirely from the tool name and short 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 burden. 'Get' implies a read-only operation, but the description does not disclose edge cases like what happens when no active task exists, whether the task is user-scoped or global, or any side effects. This is a minimal but adequate disclosure for a simple getter.

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 concise single sentence that fully captures the operation without extraneous words. It is front-loaded with the verb and resource, making it 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?

For a no-parameter getter with an output schema present, the description is mostly sufficient. It identifies the resource and action, and the output schema can cover return details. A minor gap is not explaining what 'active task' means in the broader task lifecycle, but this is inferable from sibling tool names.

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 there is nothing for the description to explain beyond the already-empty schema. The baseline for 0 params is 4, and the description appropriately lacks parameter-specific commentary.

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 ('Get') and resource ('current active task'), making it clear this is a retrieval operation. It is implicitly distinct from sibling tools like memory_task_set and memory_task_done, though it does not explicitly contrast itself 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 description provides no guidance on when to use this tool versus alternatives such as memory_task_set, memory_task_done, or other memory tools. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.

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 of behavioral disclosure. It implies mutation ('Set') but does not state whether this replaces an existing active task, persists across sessions, or has side effects, leaving important behavior unspecified.

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 redundancy. It is appropriately short, though it leans toward under-specification rather than genuine completeness.

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 state-changing tool with no annotations, low schema coverage, and no usage guidance, the description is too sparse. It omits the effect on the prior active task, the meaning of the optional description parameter, and the relationship to sibling task tools.

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 does not explain what task_name or description mean or how they relate to setting the active task. The parameter names are somewhat self-explanatory, but the description adds little semantic value beyond the raw 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 clear verb ('Set') and resource ('current active task'), making the tool's basic function understandable. It is distinguishable from siblings like memory_task_get and memory_task_done, though it does not explicitly differentiate itself.

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 is provided about when to use this tool versus alternatives such as memory_task_done or memory_task_get. There is no mention of prerequisites, sequencing, or context that would help an agent decide to call it.

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

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

With no annotations, the description carries the full burden but only states the surface action. It doesn't disclose what 'accessed' changes (timestamp? ranking?), whether the operation is idempotent, whether it affects recall ordering, or what happens when both filters are empty — whether an empty query matches everything, which could be a broad side effect.

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 single sentence is compact and front-loads the verb, which is structurally efficient. However, it errs on the side of under-specification rather than deliberate pruning — key behavioral and parameter details are absent.

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?

Although the output schema covers return values, this is a state-mutating tool with no annotations and zero parameter documentation. The matching semantics, default behavior with empty filters, and side effects on memory state are all under-specified, making it incomplete for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, but it only clarifies that 'ids' is an optional filter. The 'query' parameter is undefined in both schema and description — what it matches against, its format, and the interaction when both params are empty defaults are left 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 uses a specific verb ('Mark') and resource ('memories') and conveys a distinct operation: updating access state. The 'touch' semantics differentiate it from memory_update (content edits), memory_search, and memory_remove, though it doesn't explicitly name any 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?

No guidance is given on when to use this tool versus alternatives like memory_recall, memory_probe, or memory_update. There are no conditions, exclusions, or references to sibling tools, leaving the selection decision entirely to the 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies mutation ('Update') and implies the fact must already exist, but does not disclose whether updates are partial or full replacements, how missing ids are handled, or any side effects or return behavior. This is minimal disclosure.

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

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

The description is a single, focused sentence that front-loads the action ('Update') and resource ('existing fact'). Every word earns its place, and there is no redundant information.

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 six parameters, no annotations, and no usage guidance, the description is too thin. It lacks instructions on how to construct the update, what happens if the id does not exist, and how this tool relates to the many sibling tools. Although an output schema exists, it does not compensate for missing behavioral and selective guidance.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions value, confidence, category, and 'content payload', which roughly maps to the value, confidence, category, and content parameters. However, it omits required id and content_type, does not explain parameter formats or relationships, and adds little beyond what the property names already imply.

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

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

The description clearly states the verb 'Update' and the resource 'an existing fact', and enumerates the aspects that can be updated (value, confidence, category, content payload). It differentiates from memory_add by emphasizing 'existing', but does not explicitly name or contrast sibling tools, so it falls short of full 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?

There is no guidance on when to use this tool versus alternatives like memory_correct, memory_add, or memory_remove. The description only states what the tool does, not when it is the right choice. It provides no exclusions or scenario-based guidance, leaving the agent to infer usage.

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

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

No annotations are present, so the description must carry behavioral information. 'Get a saved workflow' signals a non-mutating retrieval of an already persisted workflow, but the description does not mention not-found behavior or confirm the absence of side effects.

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 six-word sentence is front-loaded with the resource and lookup key, with no filler or repeated schema content.

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 retrieval with an output schema already available, the description covers the essential call intent. Missing details like exact return shape and error behavior are either covered by the output schema or non-critical for a simple getter.

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%, so the description is the only place linking the lone 'name' parameter to its role. 'by name' identifies it as the workflow lookup key, but adds no constraints such as exact match or required format.

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 the verb 'Get', the resource type 'saved workflow', and the lookup mechanism 'by name'. This is precise enough to distinguish the tool from memory_workflow_list and memory_workflow_save.

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 phrasing 'by name' provides a clear retrieval context: use it when a specific saved workflow is needed. It does not explicitly name alternatives or exclusions, so it stops short of 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?

With no annotations, the description itself must establish safety and behavior. 'List' conveys a read-only enumeration with no obvious destructive effect, but the description does not disclose the category-filter behavior or state that calling it has no side effects. This is minimal but not misleading.

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 sentence is front-loaded and contains no filler, which is efficient. It is slightly too terse to cover the optional category behavior, but the wording itself is appropriately concise.

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 core purpose is clear and an output schema exists, so return-value details are not required. The main gap is that the optional category parameter's filtering behavior is entirely absent from the description, leaving an agent to guess.

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

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

The schema has 0% description coverage and the description never mentions the category parameter. The property name and default are self-explanatory only to a degree, but the description does not say that category filters the returned workflows, so it does not compensate for the missing schema descriptions.

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 ('List') and resource ('saved workflows'), so an agent can tell this is the enumeration tool and not memory_workflow_save or memory_workflow_get. It lacks an explicit distinguishing note about scope or siblings, so it stops short of the top score.

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 intended use is implied by the verb and noun: an agent should call this when it wants to enumerate saved workflows. However, the description gives no explicit guidance on when to prefer this over memory_workflow_get or how the optional category affects the call.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does not state whether saving overwrites an existing workflow, whether a workflow with the same name is rejected, what side effects occur, or what the response contains. The vague 'Save' verb implies a write operation but lacks necessary detail.

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

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

The description is a single, tightly worded sentence with no filler or repetition. It is front-loaded with the action and object, but it is arguably too sparse to serve as a fully self-contained tool guide.

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 absence of annotations and 0% schema description coverage, the description is incomplete. An agent cannot confidently determine how to format 'steps', whether saving replaces existing data, or when this tool should be chosen over other memory-saving tools. The output schema exists, so return-value details are less critical, but the usage and behavioral gaps remain significant.

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 does not compensate by explaining the meaning or format of 'name', 'steps', or 'category'. The phrase 'reusable workflow or procedure' loosely implies that 'steps' contains procedural content, but the description does not clarify structure, allowed values, or how category is used.

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 ('Save') and target resource ('reusable workflow or procedure'), making the core purpose clear. It does not explicitly differentiate from sibling tools like memory_workflow_get or memory_workflow_list, but the save action is inherently distinct from retrieval operations.

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 no guidance on when to use this tool versus alternatives such as memory_add, memory_personal_add, or memory_workflow_list. There is no mention of prerequisites, recommended conditions, or situations where a different workflow-related tool 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.