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 conveys that this is a destructive mutation on 'personal memory' scope and that an ID must first be discovered, but it never states permanence/irreversibility, whether confirmation is required, or what the deletion returns.

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?

Front-loaded with verb+resource, then a compact numbered condition list, then the prerequisite. Every sentence earns its place with 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?

For a single-parameter destructive tool with no output schema or annotations, the description covers purpose, triggers, and the ID-discovery prerequisite. It stops short of disclosing deletion permanence or confirmation behavior, a minor gap given the tool's simplicity.

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

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

Schema description coverage is 100% and the single 'id' parameter is fully documented as a UUID, so the schema does the heavy lifting. The description only adds that the ID must be sourced via get_context/list_contexts, which is workflow guidance rather than new parameter 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?

States a specific verb and resource ('Delete a personal memory entry by ID'), which cleanly distinguishes it from the read siblings get_context/list_contexts it references. An agent can tell what it does and what it targets without opening the schema.

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

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

Provides explicit triggering conditions ('User asks to forget something' / 'Entry is outdated/contradicted by newer info') and a mandated prerequisite workflow ('Always use get_context or list_contexts first to find the entry ID'). Routing to the ID-discovery tools is concrete and actionable.

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

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

With no annotations, the description carries the full burden and does disclosing meaningful behavior: it writes/replaces the PCM section of a file (a mutation of existing content) or returns text if no path is given. It lacks details on whether a missing file is created or what markers delimit the PCM section, which a full disclosure would include.

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

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

Two sentences, front-loaded with the primary action, and the conditional behavior follows immediately. Every clause carries information with no padding.

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

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

For a one-parameter tool with no output schema or annotations, the description covers both branches (write-to-file vs. return-text) and the replacement semantics. It stops short of defining what constitutes a 'PCM section' or file-creation behavior, which would make it fully self-contained.

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

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

Schema description coverage is 100%, so the single parameter is already documented, including the replace behavior. The description restates this semantics in a sentence but adds no format or path syntax detail beyond the schema, matching the baseline for high 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?

States a specific verb (Generate) and resource (PCM system prompt) and clarifies the optional side effect (saving to a file). It does not differentiate itself from siblings, but the sibling set (context CRUD, workflow tools) is unrelated enough that ambiguity is low.

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 explains the two operating modes selected by output_path (save vs. return text), which is conditional usage guidance. However, it never states when an agent should choose this tool over alternatives or what triggers prompt generation, so guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries full behavioral burden. It does disclose the return ordering (most recently updated) and contents, and gives proactive invocation rules. However it doesn't mention whether the search is case-sensitive, fuzzy, or what empty results look like – meaningful gaps for a search 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?

Front-loads purpose first, then returns, then proactive triggers and examples. Dense but every sentence adds actionable value; only the bilingual trigger list feels slightly overloaded.

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 1-parameter read/search tool with no output schema and no annotations, the description covers purpose, returns, and proactive invocation well. Missing only minor behavioral details (pagination, empty results) that an agent could discover at call time.

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 100% and the schema already explains the query searches across key, value, and tags. The description adds an extraction example ("单测" → search "测试") which is helpful but does not extend beyond the schema's own documented scope.

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

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

States a specific verb (Search) and resource (personal memory by keyword), plus the returned content (preferences, habits, facts sorted by recency). Clearly distinct from siblings like list_contexts or update_context.

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

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

Explicitly says when to auto-call (START of coding tasks, user mentions of code quality/style/review) and even provides bilingual trigger keywords with an extraction example. Far exceeds typical when-to-use 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 carries the behavioral burden, but it is a read-only, parameterless listing so there is little risk to disclose. It does add useful context about what is returned (preferences, habits, facts), though it says nothing about ordering, volume, or pagination.

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

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

Two short sentences, front-loaded with the core action and followed by what is returned. Nothing is padded, though the second sentence is arguably redundant with the first.

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 read tool with no output schema, the description gives enough to call it correctly and sketches the return contents. It could note ordering or result size, but nothing essential to invocation is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description introduces no parameter confusion and the empty schema makes semantics moot.

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 and resource ("List all entries in personal memory") and clarifies scope as the full personal memory store. It distinguishes itself implicitly from get_context (singular retrieval) but never names or contrasts with that sibling, so it falls short of a 5.

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

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

There is no explicit when-to-use guidance. The phrase "List all entries" weakly implies bulk retrieval versus the singular get_context, but the description never states when to choose this over get_context or the workflow_* siblings, leaving the agent to infer.

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

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

No annotations are provided, so the description carries the full behavioral burden and does so: it discloses upsert-by-key semantics, the destructive behavior of removing contradicted entries, cross-conversation persistence, auto-inference of category, and the encoding convention for tags. That covers mutation semantics and scope, which is more than structured fields supply here.

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

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

Front-loads the purpose, then layers triggers, upsert rules, and conventions in a compact, scannable block. It is dense but nearly every clause carries an actionable rule; the long trigger list is justified by its role in proactive invocation, though it is the densest part.

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

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

With no annotations and no output schema, the description supplies the semantics an agent needs: persistence scope, upsert/dedupe workflow, and how to populate optional fields. It stops short of describing what a successful write returns or how to recover from a failed upsert, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is already 100%, so the baseline is 3; the description adds value by specifying the bilingual tag convention ("food"+"食物") and reinforcing that category should be inferred from content, going beyond the schema's own wording. It does not, however, add format or length guidance for key/value.

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+resource ('save user preferences, habits, and facts') and frames the tool as a personal memory system, which cleanly separates it from the sibling read/list/delete tools (get_context, list_contexts, delete_context). An agent can identify the operation without opening the schema.

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

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

Explicitly instructs when to call (PROACTIVE auto-call when the user reveals personal info), lists concrete EN and ZH trigger phrases, and prescribes prerequisites: check existing entries first, and delete contradicted entries before updating. This is when/when-not plus sequencing, not vague 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 carries the full behavioral burden. It implies a mutation (marking as done) but says nothing about idempotency, whether the change is reversible, permissions required, or side effects on related items — all material 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?

Three short sentences, front-loaded with the action, then the trigger, then the prerequisite — no filler. It could be tightened marginally but every sentence carries 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?

For a one-parameter mutation with no output schema and no annotations, the description covers the action, when to use it, and how to obtain the ID. It omits reversibility, permission requirements, and whether any result is returned, leaving meaningful gaps for a write operation.

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

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

Schema description coverage is 100% and the single 'id' parameter is already documented as the UUID of the entry. The description only adds that the ID should be sourced from workflow_list, which is modest but real added value; baseline 3 is appropriate.

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

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

States a specific verb and resource ('Mark a workflow entry as done'), so an agent immediately knows this is a state-transition operation on a workflow entry. It is distinguishable from workflow_list and workflow_log by naming the 'done' outcome, though it does not explicitly contrast itself with those siblings.

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

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

Gives an explicit trigger condition ('when a task is completed or a tracked item is resolved') and a concrete prerequisite ('Use workflow_list first to find the entry ID'). It lacks a when-not clause or mention of an alternative tool for reopening/undoing, but the 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 full behavioral burden. It usefully discloses the default filter (status='active') and that results are scoped to the current git project, which is real behavioral context. However, it says nothing about return shape, ordering, pagination/limits, or read-only nature beyond the implied 'List', leaving meaningful gaps for an unannotated 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?

Two sentences, purpose front-loaded before the PROACTIVE guidance, with no redundant filler. Slightly verbose in the 'understand what tasks...' elaboration, but it still earns its place by motivating the proactive call.

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-required-parameter read tool, the definition covers scope, filtering, default status, and invocation timing. The main omission is what a returned entry looks like, which matters somewhat given there is no output schema.

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

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

Schema description coverage is 100% and both parameters are enum-constrained with their descriptions and the 'active' default documented in the schema. The description's 'filtered by type and/or status (defaults to active)' restates rather than extends the schema, so the baseline 3 applies.

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 and resource ('List workflow entries') and pins the scope to 'the current git project', plus the filter semantics. It is clear what the tool does, but it never names or distinguishes itself from siblings like workflow_log, workflow_done, or list_contexts, so sibling differentiation is left to inference.

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 PROACTIVE sentence gives explicit, actionable context: call at the start of every conversation to load project context. That is a strong when-to-use signal, but no when-not-to-use or alternative routing (e.g., vs. get_context/list_contexts) is offered.

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 does so well: it discloses upsert-on-same-title-and-type semantics, git-project data scoping, and auto-sync to CLAUDE.md. These are non-obvious side effects an agent must know before invoking.

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 PROACTIVE mandate is front-loaded, followed by a clean core-question test and a type-by-type breakdown. Length is justified by the need to drive unsolicited invocation, and no sentence is redundant with the schema besides minor restatement.

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

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

For a 4-param mutation tool with no output schema and no annotations, the description covers purpose, triggers, exclusions, parameter meaning, upsert behavior, and storage/sync scope. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description goes further by explaining what each enum value means in practice and when each applies, plus confirming title acts as the upsert key. Some of this is redundant with the schema, keeping it just under a 5.

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+resource ('Log a project workflow entry') and immediately scopes it with the three entry types, so an agent can tell it apart from workflow_list and workflow_done (read/complete siblings) without opening the schema.

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

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

Explicit when-to-call triggers, per-type logging criteria, and negative cases ('Do NOT log trivial single-step changes', 'Do NOT log obvious defaults', 'Do NOT log general programming knowledge'). It even supplies a decision heuristic ('Would this be useful in a FUTURE conversation?'), leaving nothing to inference.

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