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

Annotations already declare the safety profile (not read-only, non-destructive, non-idempotent), and the description adds genuinely useful behavior beyond them: activation is scoped to one project per MCP process, a verified baseline is created as a side effect, and auto-checkpoints may begin. It stops short of saying what happens if a different project is already active or how an existing baseline is treated.

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

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

Two tight sentences, front-loaded with the core action and its effects, followed by a single conditional tip. No filler, nothing repeated from the schema or annotations.

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

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

An output schema exists so return values need not be described, and annotations cover safety, but with half the parameters undocumented and no statement of lifecycle preconditions or interaction with sibling snapshot tools, the definition is only minimally sufficient for an 8-parameter mutation tool.

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

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

Schema description coverage is only 38% (3 of 8 parameters), so the description must compensate and largely does not. It clarifies the intent of storageRoot and alludes to autoCheckpoint ('optionally start automatic checkpoints'), but debounceMs, maxBackups, excludeNames, reconciliationIntervalMs, and projectName are never explained in either the schema or the description.

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 gives a specific verb+resource ('Activate one project for this MCP process') and enumerates the concrete side effects: creating a verified baseline and optionally starting automatic checkpoints. It implicitly contrasts with deactivate_project by naming the opposite lifecycle action, though it never explicitly names that sibling.

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

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

It offers one actionable hint ('Use storageRoot to keep all backup data outside a protected project') but does not state when to call this versus create_project_snapshot or deactivate_project, nor what prerequisites (an active project, a protected project) must hold. Usage is implied by the lifecycle framing rather than stated.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is established. The description adds valuable context beyond annotations: the backup is 'independently restorable' and 'SHA-256-verified,' and that 'unchanged files may be deduplicated in storage.' This clarifies reliability and storage behavior. It doesn't contradict 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?

Two concise sentences, front-loading the core purpose and then adding behavioral context. No wasted words; every sentence earns its place.

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

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

The tool has hidden complexity (4 parameters, no required fields, a nested-free schema, and an output schema that likely details the backup metadata). The description covers purpose and some behavioral traits but omits parameter usage and does not mention the output schema's role. Given the sibling context, it could better guide the agent on when to call this versus others. 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 four parameters and only 25% schema description coverage (only skipIfUnchanged has a description), the description does not compensate for the missing parameter documentation. It does not explain what 'name', 'tags', or 'prompt' mean or how they affect the snapshot, nor does it clarify the default behavior of skipIfUnchanged beyond what the schema already says. Baseline 3 for low coverage when no additional meaning is provided.

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

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

States a specific verb (create), resource (project snapshot/backup), and distinguishes this tool from siblings by emphasizing 'independently restorable' and 'SHA-256-verified' – qualities not implied by verify_project_snapshot or list_project_snapshots. The description clearly signals it is a mutating creation operation and not a read or verification tool.

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

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

The description implies usage ('create a backup of the active project') but provides no explicit when-to-use vs when-not-to-use guidance. It does not explain which sibling tools to prefer (e.g., list_project_snapshots to inspect existing backups first) or when a snapshot is unnecessary. For a tool with eight siblings, this is a missed opportunity to route the agent.

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

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

With annotations already declaring non-readOnly, non-destructive, idempotent behavior, the description adds meaningful side-effect context: a final checkpoint is created by default, automatic monitoring stops, and the active project is cleared. It does not contradict any annotation and goes beyond what the annotations 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?

A single compact sentence lists the three key effects without filler. The default behavior is front-loaded, and every clause earns its place.

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

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

Given the rich annotations, a complete output schema, and full parameter schema coverage, the description supplies enough behavioral context for a safe deactivation call. It is only missing explicit lifecycle usage guidance, which is a minor gap rather than a functional omission.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's phrase 'Create a final checkpoint by default' mirrors the createFinalCheckpoint parameter default already documented in the schema, adding little semantic detail beyond the property name and schema description.

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

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

The description states specific effects: creating a final checkpoint, stopping automatic monitoring, and clearing the process-local active project. It identifies the resource (active project) and distinguishes the tool as the deactivation counterpart to activate_project, though it never names the sibling explicitly.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as activate_project or delete_project_snapshot. The agent must infer the lifecycle context from the tool name and sibling list alone.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds value beyond that by disclosing the approval prerequisite and the double-confirmation mechanism via confirmSnapshotId, which the agent cannot infer from annotations alone.

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

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

Two tight sentences with zero filler. The action is front-loaded, followed immediately by the safety 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?

For a destructive two-param tool with an output schema (return values not needed), the description covers the action, the approval gate, and the confirmation requirement. Complete enough to invoke safely, though it could note that the deletion is irreversible/not undoable and options for recovery.

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 schema itself only says both params are UUIDs. The description partially compensates by explaining that confirmSnapshotId must repeat the exact snapshotId, but it leaves the snapshotId parameter and the confirm-matching semantics under-specified.

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

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

States a specific verb and resource ('Permanently delete one backup'), making the destructive action unambiguous and distinct from siblings like create_project_snapshot or restore_project_snapshot. It does not explicitly name a sibling, but the delete semantics are unique enough to 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?

Gives a clear pre-condition ('Call only after explicit user approval'), which is strong when-to-use guidance for a destructive tool. It stops short of pointing to alternatives (e.g., deactivate_project for a reversible action), so it's a 4 rather than a 5.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that the report covers storage, integrity evidence, pending changes, and checkpoint health, which is useful content, but it discloses no further behavioral traits such as cost, freshness, or scope of the reporting.

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 compact sentence with no filler, and the scope of the report is front-loaded immediately after the verb. Every word contributes to describing the returned 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?

With no parameters, a coverage-complete schema, an output schema, and annotations that already carry the read-only/idempotent profile, the description covers what is needed to call the tool correctly. It is only slightly thin on routing guidance relative to its many siblings.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. Schema coverage is also 100%.

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 gives a specific verb ('Report') and enumerates the four data categories returned (active-project storage, integrity evidence, pending changes, automatic-checkpoint health). This tells an agent what the call yields, though it never uses the word 'backup' or explicitly contrasts itself with the snapshot siblings, so differentiation is left implicit.

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

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

There is no statement of when to call this versus the snapshot/restore siblings (verify_project_snapshot, list_project_snapshots, etc.), nor any prerequisites or exclusions. The agent must infer usage purely from the topic wording.

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, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is fully covered. The description adds only the sort order ('newest first'), and its remaining content (hashes, triggers, sizes, change counts) is return-value detail with no behavioral disclosure. Adequate but thin 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?

One sentence, front-loaded with the verb and resource, with the ordering constraint placed early. No filler and nothing redundant in phrasing.

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

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

An output schema exists, so enumerating returned fields is largely redundant, while genuinely missing details (default/limit semantics, pagination, whether results span one project or all) go unaddressed. Complete enough to invoke, but not to invoke confidently.

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 single parameter (limit) has 0% schema description coverage, so the description carries the burden of explaining it — and it says nothing about limit, its 1-500 range, a default value, or pagination behavior. The field list it does give maps to return values, not to the exposed parameter.

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

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

States a specific verb and resource ('List verified backups') and adds ordering ('newest first'), which tells an agent this is a read-listing operation rather than a single-snapshot fetch like verify_project_snapshot. It narrows to 'verified' backups, giving partial differentiation, but never names a sibling or clarifies scope (all projects vs. one).

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 when-to-use guidance is given. With siblings like get_backup_status and verify_project_snapshot in the toolset, the description never says when an agent should list snapshots instead of checking status or verifying a single snapshot; the 'verified' qualifier is the only implicit routing hint.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, giving the safety profile. The description adds valuable non-structured behavior: it returns a short-lived token that must be surfaced to the user before confirmation, which materially affects how the agent should sequence calls.

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

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

Two tight sentences, front-loaded with the core action and followed by the operational instruction. 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?

Covers the workflow step and the token handoff, and an output schema exists for return values. The main gap is not naming the sibling restore tool as the next step, but the description is otherwise sufficient for correct invocation.

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

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

Schema coverage is 50%, so one of the two parameters (mode) is already documented with a default in the schema. The description adds no detail about snapshotId or the mode enum values, but with an output schema present and partial schema coverage, baseline 3 is appropriate.

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

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

States a specific verb+resource ('verify a backup and calculate the restore change set'), which is more precise than the vague title. It does not explicitly name how it differs from siblings like restore_project_snapshot or verify_project_snapshot, leaving that routing to inference.

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

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

Gives clear workflow context ('present the preview to the user before requesting confirmation'), which tells the agent this is a pre-step to an actual restore. It doesn't explicitly name restore_project_snapshot as the follow-up tool, so the alternative is implied rather than stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description adds substantial extra context: the required unexpired confirmation token, the mandatory pre-restore safety backup, and the automatic rollback guarantee. These are real behavioral guarantees an agent cannot infer from the schema or 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?

Three tight sentences, front-loaded with the destructive nature and followed by the required inputs and built-in safeguards. No filler and nothing repeated from structured fields.

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 destructive, non-idempotent mutation with an output schema, the description covers what the agent needs: danger level, the mandatory prerequisite token, and the safety-backup/rollback behavior. Nothing essential to a correct call is missing.

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

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

Schema coverage is 50%: the schema documents confirmationToken's origin but leaves snapshotId undocumented. The description adds useful semantics for the token (must be matching and unexpired) but says nothing about snapshotId, so it only partly compensates for the coverage gap.

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

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

States a specific verb (apply) and scope (a previously previewed restore), making it clearly distinct from the sibling preview_project_restore and the snapshot lifecycle tools. It does not name the preview sibling explicitly, but 'previously previewed restore' effectively ties it to that step.

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?

Establishes the sequencing prerequisite (a prior preview producing a confirmation token) and the validity condition (token must be unexpired and matching). It does not explicitly tell the agent to call preview_project_restore first, but the reference is unambiguous enough to route 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description usefully adds the mechanics: re-hashing plus validation of entry types, paths, modes, and manifest integrity. However, it says nothing about behavior on a mismatch (does it throw, return a flag, or fail silently), which is the most important trait for a verification 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?

A single tight sentence with the operation front-loaded and no filler. It is efficient, though it packs four validated attributes into one clause without prioritizing them.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. Still, for a verification tool the description omits failure semantics and any prerequisite context, leaving a real gap for correct invocation interpretation.

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 a single parameter at 0% schema description coverage, the description must carry the meaning. "The selected backup" only loosely ties snapshotId to the target and adds no format, selection, or validity semantics beyond the schema's uuid type.

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 gives a specific verb pair ("re-hash" and "validate") against a specific resource ("the selected backup"), so the agent knows it is an integrity-check operation rather than a read, restore, or delete. It does not explicitly differentiate itself from the closest sibling, get_backup_status, which also touches snapshot state.

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

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

There is no when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The agent can infer the tool is for verifying integrity, but nothing tells it when to prefer this over get_backup_status or preview_project_restore.

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