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

Adds context that the candidate becomes 'sourced active long-term memory,' but does not disclose side effects, auth needs, or state changes beyond what annotations (only idempotentHint) provide.

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?

Single sentence, 12 words, front-loaded verb, no unnecessary 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?

Despite having an output schema, the description lacks explanation of prerequisites (e.g., candidate state), the meaning of 'sourced active long-term memory,' and return value 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%, and the description adds no explanation for projectId or candidateId beyond their 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?

Description clearly states 'Accept a reviewed candidate' with specific verb and resource, distinguishing it from sibling tools like memory_candidate_reject.

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?

Implies use after review, but no explicit guidance on when to use versus alternatives (e.g., reject) or prerequisites.

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

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

The description adds the important detail that the audit record is preserved, which goes beyond the annotations (idempotentHint=true, destructiveHint=true). However, it does not explain what 'reject' means in terms of state changes or side effects, and the destructiveHint might be unclear without further context.

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 11 words, efficiently communicating the core purpose and a key behavioral trait. No wasted words.

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

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

The tool is simple with only two required parameters and an output schema that likely covers return values. However, the lack of parameter descriptions and usage guidelines makes it incomplete for a fully informed invocation.

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

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

With 0% schema description coverage and no parameter details in the description, the agent has no semantic information about projectId or candidateId beyond their names and types. This is 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 clearly states the tool's action: 'Reject a reviewed memory candidate.' It also specifies the key behavioral nuance 'without deleting its audit record,' which distinguishes it from sibling tools like memory_candidate_accept.

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, nor does it mention prerequisites or the state in which the candidate must be before rejection. The phrase 'reviewed memory candidate' gives a slight hint but is insufficient.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating safe read operation. The description adds context about the candidate review process, which aligns with annotations and provides extra behavioral context.

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 unnecessary words. It efficiently conveys 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 description is adequate for a simple list operation given the annotations and output schema, but it lacks details on pagination (limit) and the meaning of 'sourced' or the status filter, leaving some gaps in 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 does not explain any parameters (limit, status, projectId). It only explains the overall purpose, missing the opportunity to clarify filter defaults or meaning of status 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 clearly states the verb 'List' and the specific resource 'sourced memory candidates that require explicit review before becoming long-term memory,' which distinguishes it from sibling tools like memory_list (general memories) and memory_candidate_accept/reject (actions on candidates).

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

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

The description implies usage for reviewing candidates before acceptance, but does not explicitly state when not to use or mention alternative tools beyond the sibling list.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable operation. The description adds no extra behavioral context (e.g., default status, pagination, performance). Adequate but minimal added value.

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?

Single sentence with no redundant words. Efficiently conveys the core 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?

Despite good annotations and an output schema, the description fails to mention all parameters (especially required projectId) or the default behavior (status defaults to 'active'). Leaves gaps for an agent to infer.

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

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

With 0% schema description coverage, the description should compensate but only mentions 'status' implicitly. It does not explain projectId (required) or limit (default 50, max 200). Minimal added meaning beyond 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 clearly states the action ('List'), resource ('project memories'), and filter ('by lifecycle status'). It distinguishes from sibling tools like user_memory_list (project vs user) and memory_candidates (specific status).

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

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

No guidance on when to use this tool versus alternatives such as memory_candidates or user_memory_list. No conditions, prerequisites, or exclusions are mentioned.

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

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

Beyond the annotation idempotentHint=false (indicating non-idempotent behavior), the description adds no behavioral traits. It does not mention side effects, authorization needs, or what happens on repeated calls, which is critical for a state-mutating 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 concise sentence, but it lacks structure (e.g., bullet points, parameter explanations). While it wastes no words, it also fails to provide essential information, making it minimally adequate in conciseness.

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

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

Given the tool's complexity (many required params, 0% schema coverage), the description is woefully incomplete. It does not explain what each parameter does, the return value (though output schema exists), or any constraints. An agent would struggle to use this 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?

With 0% schema description coverage and 11 parameters (5 required), the description fails to explain any parameter. It does not even hint at the roles of projectId, type, title, content, sourceKind, etc., making it nearly impossible for an agent to invoke 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 clearly states the action 'persist' and lists the types of memory items (fact, decision, etc.), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'memory_list' or 'memory_update_status', though the verb 'persist' implies 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?

No guidance is provided on when to use this tool versus alternatives (e.g., memory_list, memory_update_status). There are no exclusions, prerequisites, or context cues to help an agent decide.

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

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

Annotations indicate idempotentHint: true and destructiveHint: true, which are consistent with the description. However, the description does not elaborate on side effects, such as whether setting 'deleted' actually removes the memory or what 'destructive' entails.

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 extraneous words. It efficiently conveys the core function.

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

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

Despite having an output schema, the description does not cover return values. It also lacks information about valid status transitions or prerequisites (e.g., memory must exist). Given the tool's complexity (3 required params, enum), more context is needed for correct usage.

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 3 parameters with 0% description coverage. The description only mentions the 'status' parameter implicitly by listing example values. It does not explain 'projectId' or 'memoryId', leaving the agent to infer their meaning from 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 clearly states the action (move a memory) and the resource (lifecycle status), with examples of statuses. However, it does not differentiate this tool from sibling tools like memory_candidate_accept or memory_candidate_reject, which also change memory status.

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 on when to use this tool versus siblings. For instance, it does not explain that this tool can set any status, while others are specialized for accept/reject actions.

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

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

The description adds value beyond the idempotentHint annotation by specifying what is retained during archiving. This informs the agent about side effects (no data loss).

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?

Single sentence, 13 words, no extraneous information. Efficiently conveys the core purpose and key behavioral trait.

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?

Covers purpose and retention, but lacks mention of reversibility (e.g., via project_unarchive) or any confirmation of success. The output schema might fill gaps, but it is not provided.

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

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

Schema description coverage is 0%, and the description does not elaborate on the projectId parameter. While the parameter name is self-explanatory, the description should confirm that projectId is the identifier of the project to archive.

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 action ('Archive a project') and specifies what is retained ('database, memories, tasks, and audit history'), distinguishing it from destructive siblings like project_delete.

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

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

No guidance on when to use this tool versus alternatives such as project_delete or project_backup. The agent must infer usage from the tool name and sibling 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?

Annotations only provide openWorldHint=true and idempotentHint=false; the description adds behavioral context like 'consistent' and 'online' backup, and the constraint that destination must be new and absolute. No contradiction with annotations.

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

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

A single sentence that is front-loaded with the key action and resource. Every word adds value with no redundancy.

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

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

Output schema exists so return values are not expected in description. However, important details like consistency guarantees, online behavior (e.g., locking), and prerequisites (project must exist) are missing. Given backup complexity, description is adequate but not rich.

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?

Description adds meaning for destination (new, absolute) but not for projectId. With 0% schema coverage, the description partially compensates but leaves a gap for projectId parameter semantics.

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

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

The description clearly states the verb ("Create"), the resource ("online SQLite backup"), and specific scope ("consistent", "new absolute destination path"). It distinguishes from siblings like project_backup_encrypted and project_restore.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., project_backup_encrypted) or when not to use it. The context provides no exclusions or prerequisites.

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

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

Annotations provide openWorldHint=true and idempotentHint=false, indicating mutation and potential side effects. The description adds algorithm info (AES-256-GCM) and passphrase source, but does not disclose behavior on conflict, overwrite, or state changes. With annotations present, the additional context is moderate.

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?

Single sentence of 12 words, front-loaded with key action and encryption details. No redundancy or fluff.

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

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

For a 3-param tool with security implications, the description lacks prerequisites (e.g., env variable must exist, project must be accessible), return value description (despite output schema existing), and error conditions. Incomplete for safe and correct usage.

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 has 0% description coverage, so description must compensate. It clarifies 'passphraseEnv' as a named environment variable but does not explain 'projectId' or 'destination'. Partial value added.

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 action: create an encrypted project backup using AES-256-GCM with a passphrase from an environment variable. It distinguishes from sibling tools like 'project_backup' (presumably unencrypted) and 'project_restore_encrypted'.

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

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

The description implies usage for encrypted backups but does not explicitly guide when to use this tool versus alternatives like 'project_backup' or mention prerequisites (e.g., project existence, env variable set). No 'when not to use' or comparison to 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?

Annotations already declare readOnlyHint and idempotentHint, so the description does not need to repeat that. It adds useful context about the sources of data (active memories, task checkpoints, indexed sources), which goes beyond annotations. No contradictions.

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 states the core function concisely. Every word contributes meaning, with no fluff 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?

The description covers the tool's high-level purpose but lacks detail on how context is assembled, how parameters influence behavior, or what the output schema contains. Since an output schema exists, return values are covered externally, but parameter semantics remain vague, making the description minimally adequate.

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%, but the description provides no explanation of the parameters (projectId, task, budgetTokens). The agent must infer semantics from parameter names and schema constraints (e.g., min/max for budgetTokens), which is insufficient for precise invocation.

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-resource combination ('Assemble task-focused project context') and enumerates the sources (active memories, task checkpoints, indexed sources), clearly distinguishing it from siblings like memory_list (just lists memories) or project_health (checks health).

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

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

No explicit statement on when to use this tool versus alternatives. While the name and description imply it is for gathering comprehensive context, there is no direct guidance on exclusions or when a more specific sibling (e.g., memory_list) should be preferred.

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

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

Annotations already indicate destructiveHint=true. The description adds context about safety checks and exact-ID confirmation, which are not in annotations. It does not contradict annotations.

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

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

The description is a single concise sentence that front-loads the purpose and key safety feature. Every word is necessary; no waste.

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 purpose and safety, but omits important context: only archived projects can be processed, and no guidance on when to use preview vs purge. Output schema exists, so return values are covered externally.

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 description alludes to 'exact-ID confirmation' (confirmProjectId) and 'preview or permanently purge' (purge), but does not mention backupDestination. With 0% schema coverage, partial explanation of the 4 parameters leaves gaps.

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 (preview/purge) and resource (archived project). It specifies the exact-ID confirmation requirement, distinguishing it from siblings like project_archive or project_restore, though it could explicitly differentiate usage for archived vs non-archived projects.

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

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

The description implies usage for deleting archived projects with safety checks, but does not give explicit when-to-use vs when-not-to-use guidance or mention alternatives. The distinction between preview and purge is implied but not explained.

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

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

The idempotentHint annotation indicates a read-only action, and the description lists checks, which aligns with a diagnostic tool. However, the 'repair' parameter suggests possible modification, but its behavior is not explained, leaving a transparency gap.

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

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

The description is a single efficient sentence that lists the checked items without redundancy. It could be slightly expanded for clarity but is not overly verbose.

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

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

Given the tool has two parameters (one required and one with behavioral implications), missing parameter semantics and usage guidance make the description incomplete. The output schema exists but does not compensate for the lack of parameter 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?

The description provides no information about the two parameters ('projectId' and 'repair'), despite having 0% schema coverage. The agent receives no cues about their purpose or acceptable values beyond the schema itself.

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 'Check' and lists distinct resources (integrity, indexes, source, memory, candidates), making the purpose clear. However, it does not differentiate from the sibling tool 'project_health', which may perform similar checks.

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 on when to use this tool versus alternatives (e.g., when to prefer 'project_doctor' over 'project_health'), nor are there any exclusions or prerequisites mentioned.

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

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

Annotations provide openWorldHint and idempotentHint. The description adds the output format (JSONL) but does not disclose side effects, resource consumption, or the number of files created. It adds some context beyond annotations but not enough.

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?

Single sentence, no redundancy, efficient. Every word contributes to the 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?

Given the simple schema and that an output schema exists, the description covers the exported resources and format. Minor gaps: no mention of whether multiple files or a single file, or any size constraints.

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 description must compensate. It does not describe the parameters (projectId, outputDirectory) beyond their names. Although the names are self-explanatory, the description adds no additional 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 clearly states the tool exports project memories, candidates, tasks, symbols, relations, and a manifest as JSONL files. It uses a specific verb and resource, and distinguishes itself from siblings like project_backup and project_archive.

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

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

No guidance on when to use this tool vs alternatives (e.g., project_backup) or any prerequisites. The description implies usage but lacks explicit context 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. Description repeats 'Report' which is consistent but adds no extra behavioral context (e.g., auth needs, performance).

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?

Single sentence, front-loaded with verb and object, no redundant words. Efficiently communicates scope.

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 low parameter count and an output schema present, description sufficiently covers the tool's output. Missing only a brief note on interpretation of 'health'.

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%. The single parameter projectId has minLength 1 but description only says 'for a project', adding no format, constraints, or examples beyond 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?

Description clearly states the verb 'Report' and specific health aspects (source, chunk, memory, task, index-run) for a project. It uniquely distinguishes from sibling tools like project_context or project_index.

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

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

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, exclusions, or when not to use 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?

Annotations provide idempotentHint: true, and description says 'incrementally', which aligns. No contradictions, but lacks details on side effects or what 'allowed' means.

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?

Single sentence, no wasted words, clear and front-loaded.

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?

Has output schema, but minimal behavioral context. Lacks explanation of 'incrementally', 'allowed', and return behavior. Adequate but with gaps.

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

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

Schema coverage is 0% and description does not explain projectId beyond 'for a project'. No format, source, or usage specifics.

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 action (index), scope (incremental, allowed files), and target (project). It distinguishes from siblings like project_search or project_export.

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

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

No guidance on when to use this tool vs alternatives, prerequisites, or when not to use. Siblings listed but no differentiation.

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

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

Annotations already declare readOnlyHint and idempotentHint true. The description adds the behavioral nuance that projects are 'already registered', implying a stable list, but does not conflict with annotations. No additional traits like rate limits or access needs are 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 extremely short (one sentence) and to the point. It communicates the core purpose without extra words, which earns a high score for conciseness, though it might sacrifice 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 the complexity (only 1 parameter, output schema exists), the description is too minimal. It lacks any context about filtering, ordering, or what 'already registered' means, and does not compensate for the 0% parameter schema coverage. The output schema's existence reduces the need for return value docs, but the description still misses key usage 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?

With 0% schema description coverage, the description fails to explain the single parameter 'includeArchived' or its default value. The tool name and description give no hint about this parameter, leaving the agent to infer its meaning from the schema only.

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

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

The description clearly states the tool lists projects that are already registered in persistent storage. The verb 'List' and resource 'projects' are specific, and it distinguishes from sibling tools like 'project_search' by implying a simpler retrieval of all registered projects.

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 on when to use this tool versus alternatives like 'project_search' or filtered views. There are no indications of prerequisites, exclusions, or context for optimal 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?

The annotations already declare idempotentHint=true, and the description reinforces safe behavior by mentioning 'reopen'. It adds the important constraint of 'absolute root path', which is beyond annotations.

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

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

A single, front-loaded sentence of 9 words with no wasted information. Every word is necessary and directly contributes to understanding.

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

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

Given the tool's simplicity and presence of an output schema, the description adequately covers the core action and parameter meaning, though it could briefly note the return value or state implications.

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

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

With 0% schema description coverage, the description compensates by explaining the 'root' parameter as an absolute path, adding crucial meaning beyond the schema's basic type and minLength.

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 action 'register or reopen' on a 'project' using its 'absolute root path', which is specific and distinguishes it from sibling tools like project_list or project_delete.

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

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

The description implies usage for opening existing projects by path but provides no explicit guidance on when to use versus alternatives, nor any exclusion 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?

The description adds the behavioral detail 'without moving project files,' which is not in annotations. Annotations include idempotentHint and openWorldHint, which are consistent with an update operation. However, the description does not disclose potential side effects, permission requirements, or what happens to the old root.

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 that gets to the point with no fluff. It is front-loaded with the action. However, it omits parameter descriptions, which would improve usefulness without sacrificing conciseness.

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

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

With 2 simple parameters and an output schema, this tool does not demand extensive context. However, the description lacks any mention of return value, prerequisites, or validation rules. It is minimally complete but leaves the agent guessing about parameter 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 coverage is 0%, so description must compensate, but it does not describe parameters. 'projectId' is self-explanatory, but 'newRoot' is ambiguous (path? identifier?). The agent is left without guidance on format or meaning beyond parameter 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 specifies a clear action: 'Update a registered project to an authorized existing root without moving project files.' It uses a specific verb+resource ('Update a registered project') and adds a key behavioral constraint ('without moving project files'), distinguishing it from update tools that might move files.

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

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

No guidance on when to use this tool versus alternatives like project_update, project_doctor, or project_archive. The description does not mention prerequisites, limitations, or scenarios where this tool is preferred.

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

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

Annotations indicate openWorldHint=true and idempotentHint=false, which the description partially reinforces by mentioning replacement of archived projects. However, it omits details like state changes, confirmation requirements, or potential data loss.

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 that efficiently conveys two modes. However, breaking it into two sentences or using bullet points would improve clarity for an agent.

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 5 parameters, 0% schema coverage, and an output schema, the description is minimal. It lacks explanation of behavior, error conditions, return value shape, and parameter interdependencies, making it insufficient for reliable invocation.

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

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

With 0% schema coverage, the description must compensate but only hints at source, root, and confirmProjectId. It does not explicate the meaning of name, projectId, or confirmProjectId, leaving agents to guess how to construct requests.

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 it restores a validated project backup into a new root or replaces an archived project. It distinguishes itself from encrypted restoration (sibling tool) by not mentioning encryption, but could be more specific about what constitutes a validated backup.

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 outlines two use cases but provides no guidance on when not to use it or which sibling tool to choose instead. No prerequisites or conditions like backup validity are explained.

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

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

Annotations already indicate idempotentHint=false and openWorldHint=true. The description adds that it uses a passphrase from an env var, but does not elaborate on side effects or destructive potential beyond what annotations imply. Some additional context is provided but not extensive.

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 without wasted words. However, it sacrifices completeness for brevity, especially regarding parameters.

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

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

Despite having an output schema, the description does not cover several parameters or provide usage context for them. For a tool with 6 parameters and complex restore operation, the description is 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 coverage is 0%, so the description should explain parameters. It only explains source and passphraseEnv, but there are 6 parameters total (name, root, projectId, confirmProjectId missing). This leaves significant 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 clearly states it decrypts and restores an encrypted project backup using a passphrase from an environment variable. This distinguishes it from sibling tools like project_restore (non-encrypted) and project_backup_encrypted (encrypted backup 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 description implies use when restoring an encrypted backup with a passphrase in an env var. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an 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?

Annotations already declare readOnlyHint and idempotentHint. The description adds value by revealing the use of FTS5 and the scope (indexed content and active memories), going beyond annotations without contradicting them.

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

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

The description is a single, efficient sentence that front-loads the purpose and resource. Every word earns its place with no redundancy.

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

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

For a tool with three parameters, an output schema, and rich sibling context, the description is too sparse. It lacks parameter explanations, usage context, and examples, making it incomplete for effective agent invocation.

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

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

With 0% schema coverage, the description carries the burden but fails to explain the three parameters (projectId, query, limit). It only implies search criteria without mapping to 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 clearly states the tool searches 'indexed project content and active long-term memories with FTS5'. It uses a specific verb ('Search') and identifies the resource, distinguishing it from siblings like memory_list or project_list.

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

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

The description provides no guidance on when to use this tool versus alternatives. Siblings include many project and memory tools, but no exclusions or context are given, 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?

Annotations already provide idempotentHint=true, so the description adds little behavioral context. It does not mention side effects, permissions, or what happens if the project is already active. However, it does not contradict annotations.

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

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

The description is a single, well-structured sentence that immediately conveys the tool's purpose. Every word is meaningful and there is no extraneous 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?

Given the tool's simplicity (one parameter), the description provides the core purpose. However, it lacks details about parameter semantics and usage context. The presence of an output schema partially compensates, but overall the description could be more 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%, meaning the schema does not describe parameter meaning. The description only indirectly refers to 'project' but does not explain the projectId parameter's format, source, or constraints. This leaves the agent with insufficient guidance.

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 action 'Return an archived project' and the resource 'project', and specifies the outcome 'to the default active project list'. It effectively distinguishes from sibling tools like project_archive (the inverse) and project_delete (destructive).

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

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

The description implies usage for unarchiving projects but does not explicitly state when to use this tool over alternatives, nor does it provide any exclusions or prerequisites. The context from siblings suggests it's the opposite of project_archive, but no explicit 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?

The description adds the constraint about root path, which is helpful, but does not elaborate on other behavioral traits (e.g., permissions, side effects). The idempotentHint annotation already covers idempotency, so the description adds marginal value.

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 maximally concise with no fluff, front-loading the key action and constraint.

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

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

Given the tool's simplicity (2 params, idempotent, output schema exists), the description is nearly complete, though it could mention what the update returns.

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

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

Schema coverage is 0%, and the description only mentions 'mutable project metadata' without explaining that 'name' is the updatable field or clarifying the role of 'projectId'.

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 resource 'mutable project metadata', and explicitly excludes changing root path, distinguishing it from tools like project_relocate.

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

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

The description implies usage context by stating what is not changed (root path), but does not explicitly name alternative tools or provide when-to-use/when-not-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?

Annotations already provide readOnlyHint and idempotentHint, indicating safe, side-effect-free operation. The description adds useful context about 'process-lifetime' and 'latest index status', enhancing transparency beyond annotations.

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

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

A single, front-loaded sentence that conveys all necessary information without any extraneous words. Every part is earned.

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 parameterless tool with an output schema, the description is complete. It states the action and scope, and the output schema handles return values.

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?

There are no parameters, so schema coverage is 100%. The description correctly implies no input is needed, aligning with the empty schema. Baseline for 0 params is 4.

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

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

The description uses a specific verb 'List' and names the resource 'process-lifetime project watchers' and includes 'latest index status'. It clearly distinguishes from sibling tools like project_watch_start and project_watch_stop.

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 use for viewing current watchers and their status, and sibling names clarify when to use start/stop alternatives. However, no explicit when-to-use or when-not-to-use is 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?

Description adds significant context beyond annotations: debounced, process-lifetime, incremental indexing, and no candidate acceptance. Annotations only provide idempotentHint.

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?

Single dense sentence, but no wasted words. Could be more structured but remains 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?

Description is brief; lacks explanation of watcher lifecycle or output schema purpose. Output schema exists but not referenced. Adequate but 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?

With 0% schema description coverage, the description must compensate, but it only vaguely alludes to debouncing without detailing projectId or initialIndex.

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 action (start) and resource (debounced process-lifetime watcher), distinguishing it from siblings like 'project_watch_stop' and 'project_watch_list'.

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

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

The description implies when to use (to start indexing changes) and mentions 'without accepting candidates', but lacks explicit when-not-to-use or direct 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?

The description adds minimal behavioral context beyond the annotation (idempotentHint: false). It does not disclose side effects, error conditions, or whether stopping is reversible, which is important for a non-idempotent 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 one short sentence with no redundant information, but it could be slightly expanded for better context without losing conciseness.

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

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

Given the tool is a mutation with an output schema (not shown), the description lacks completeness. It does not explain return values, post-conditions, or error scenarios, leaving the agent underinformed.

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

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

With 0% schema description coverage and only one parameter (projectId), the description does not add meaning beyond the schema. The parameter name is self-explanatory, so a score of 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?

The description clearly states the action ('Stop') and the resource ('process-lifetime project watcher'), and it distinguishes from sibling tools like project_watch_start and project_watch_list.

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

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

The description implies usage (stopping a watcher started by project_watch_start) but provides no explicit guidance on when to use vs alternatives, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's addition of 'Check whether...storage has been configured' adds minimal behavioral context beyond confirming safety. It does not describe side effects or other traits, but it's consistent with annotations.

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

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

The description is a single, concise sentence of 8 words. It is front-loaded with the verb 'Check' and contains no unnecessary words, earning its place 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?

Given the simplicity of the tool (no parameters, output schema exists), the description adequately states the tool's purpose. It doesn't explain return values, but that is covered by the output schema. The meaning of 'configured' could be slightly vague, but it's sufficient.

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?

There are zero parameters, so the baseline is 4. The description does not need to add parameter details. It correctly matches the input schema 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 'Check' and a clear resource 'persistent Project Context storage'. It clearly states the tool's function without ambiguity. Among siblings like 'project_health' which checks overall project health, this tool is distinct in focusing on storage configuration.

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 when to check storage vs. other project status tools like 'project_health' or 'memory_candidates'. No exclusions or context for usage are given.

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

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

Annotations indicate idempotency. The description lists what is saved, which is useful, but it does not disclose any other behavioral aspects such as whether existing data is overwritten or merged, or any rate limits.

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 efficiently states the tool's action and data scope with no extraneous 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?

Despite having 9 parameters, the description does not explain the purpose of required parameters ('projectId', 'taskId'), how the checkpoint relates to other task operations, or what the output schema contains. The tool's complexity demands more 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 coverage is 0%, so the description must compensate. It maps the listed fields (completed, next, changedFiles, etc.) to likely parameter names, but fails to mention the required parameters 'projectId' and 'taskId'. This adds some meaning but is incomplete.

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 'Save' and lists the types of data saved (completed work, next steps, etc.), clearly indicating the purpose. However, it does not explicitly distinguish from sibling tools like 'task_complete' which might also involve saving.

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 on when to use this tool versus alternatives like 'task_complete', 'task_start', or 'task_list'. The description lacks context on prerequisites or typical sequences.

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

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

Annotations provide idempotentHint=true, and the description adds the behavioral detail that the latest checkpoint is retained. However, it does not disclose any destructive actions (if any) or permission requirements. Beyond the annotation, the description adds modest value.

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 that conveys the core action and a key behavioral trait. No extraneous information, perfectly front-loaded.

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

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

Given the tool's simplicity (mark a task complete) and the presence of an output schema, the description is largely complete. However, the lack of parameter semantics and usage guidance is a minor shortfall for a tool with a sibling set that includes task lifecycle operations.

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 2 required string parameters (taskId, projectId) with 0% description coverage in the schema. The tool description does not add any meaning to these parameters—no format hints, no examples, no explanation of how to obtain them. This is a significant gap for a tool with no param descriptions 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 clearly states the action ('mark persistent task completed') and the key behavioral nuance ('retaining its latest checkpoint'). It distinctively separates from sibling tools like task_checkpoint (which likely only saves state) and task_start (which begins a task).

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 purpose implies usage for completing a task, but no explicit guidance is given on when to use versus alternatives like task_checkpoint or task_start. There are no exclusions or context about prerequisites (e.g., task must be started).

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds little behavioral context. It does not mention pagination behavior (limit parameter), ordering, or any effects of calling the tool. The description merely restates the purpose without deepening transparency.

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

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

The description is a single sentence with no wasted words. It is compact and efficient. However, it could be slightly expanded to cover parameter semantics without losing conciseness.

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

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

Given that the tool has 3 parameters (one required, two optional with defaults) and no parameter descriptions in the schema, the description is insufficient. The output schema exists, but the input semantics are under-explained. A more complete description would elaborate on the parameters and their effect on results.

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

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

With schema description coverage at 0%, the description must add meaning to parameters. It only hints at the 'status' filter ('by status') but fails to explain the 'limit' or 'projectId' parameters, their defaults, or constraints. This leaves the agent guessing about valid values and defaults.

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 action (List), resource (persistent tasks), and filter (by status). It distinguishes from sibling tools like task_complete or task_start by specifying listing functionality. However, it could be more precise by mentioning that it lists tasks for a specific project.

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

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

No guidance on when to use this tool versus alternatives such as task_complete, task_checkpoint, or project_list. The description does not specify that it is read-only, nor does it mention any prerequisites or context for use.

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?

Adds 'persistent cross-session' context beyond annotations, implying the task persists across sessions. However, it does not disclose side effects, prerequisites, or error conditions, and annotations only provide idempotentHint=false.

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, which is concise but lacks essential parameter information. It is appropriately short but under-specified for a tool with two required parameters.

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 the presence of an output schema, the description is too minimal. It does not explain what happens upon starting a task, return value expectations, or integration with sibling tools like task_checkpoint.

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% coverage in description, and the description provides no explanation for the two parameters (projectId, goal). The agent gets no guidance on parameter meaning or format beyond the schema.

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

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

The description uses specific verb 'Start' and resource 'persistent cross-session project task', clearly indicating the action. It distinguishes from sibling task tools like task_checkpoint and task_list, though it does not explicitly differentiate.

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

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

No guidance on when to use this tool versus alternatives such as task_checkpoint or project_open. Lacks any when-to-use or when-not-to-use information.

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

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

Annotations already declare 'readOnlyHint' and 'idempotentHint' as true, so the agent knows the tool is safe and idempotent. The description adds that it lists by status, but does not disclose pagination behavior, ordering, or what happens with the limit parameter. Since annotations cover the safety profile, a score of 3 is appropriate.

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

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

The description is a single, concise sentence that is front-loaded with the verb and resource. It is appropriately sized for a simple listing tool, but it could add more value without losing conciseness, such as noting the output schema or default behavior.

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 that an output schema exists (not shown but 'has output schema: true'), the description does not need to explain return values. However, it lacks information about pagination, default limit, status filtering behavior, and how it differs from 'memory_list'. It is minimally sufficient but not robust.

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 only hints at the 'status' parameter ('by lifecycle status') but does not explain the 'limit' parameter, default values, or the meaning of each status. This is insufficient for an agent to fully understand parameter usage.

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

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

The description clearly states the action ('List') and resource ('user-level memories') and a filtering dimension ('by lifecycle status'). However, it does not differentiate itself from sibling tools like 'memory_list' or 'user_memory_remember', which could cause confusion.

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

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

No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide context about prerequisites. Given the presence of several memory-related sibling tools, this omission is significant.

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

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

Annotations only include idempotentHint: false, and the description adds minimal behavioral context. 'Persist' implies a write operation, but there is no mention of side effects (e.g., overwriting, notifications), permissions needed, or whether the operation is reversible. No contradiction with annotations.

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

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

The description is a single sentence of 8 words, highly concise and front-loaded with the key action. However, it sacrifices completeness; a second sentence for usage guidance would improve it without losing conciseness.

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

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

For a tool with 10 parameters, 4 required, and a write mutation, this description is too sparse. It does not explain prerequisites, parameter constraints, or behavioral outcomes beyond persistence. The existence of an output schema reduces the need to explain return values, but other contextual 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?

With 10 parameters and 0% schema description coverage, the description does not explain parameter semantics beyond what the schema provides. The phrase 'explicit cross-project scope' hints at scopeLevel and scopeRef, but the agent gets no guidance on how to set values like confidence, sourceKind, or supersedesId.

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 ('persist') and resource ('user-level memory'), and adds 'reviewed' and 'explicit cross-project scope' to differentiate from siblings like memory_remember and user_memory_list. However, 'reviewed' is ambiguous and could be clarified to distinguish from candidate acceptance 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 implies usage for persisting reviewed user-level memories with cross-project scope, but it does not explicitly state when to use this tool over alternatives like memory_remember or user_memory_list, nor does it provide when-not-to-use or exclusion 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?

Annotations already provide idempotentHint and destructiveHint, indicating the tool can be safely repeated and may cause irreversible changes. The description adds minimal behavioral context beyond 'move', so it does not enhance transparency beyond the annotations.

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

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

The description is a single sentence, but it fails to earn its place by omitting critical parameter or usage details. While not verbose, it is under-informative for the complexity of 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?

Despite having an output schema, the description does not explain the lifecycle transitions or what each status entails. For a state-mutating tool with enum-based parameters, the description is insufficiently 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?

With 0% schema description coverage, the description should compensate by explaining parameters. It does not mention memoryId or the status enum values, leaving the meaning and usage of parameters entirely unspecified.

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 'Move' and the resource 'user-level memory', specifying the action of changing lifecycle status. The tool name itself distinguishes it from sibling 'memory_update_status' by including 'user', though the description does not explicitly differentiate from other memory lifecycle 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 on when to use this tool versus alternatives. The description does not mention prerequisites, outcomes, or contrast with siblings like 'memory_candidate_accept' or 'memory_candidate_reject', which likely handle specific status transitions.

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