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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool creates a timestamped snapshot and stores it in CAS, and it explains supported input types. It does not mention side effects on the draft/source, immutability, idempotency, or permission requirements, so there are clear gaps.

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

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

Two sentences, no filler, with the core action front-loaded and the supported input modes stated explicitly. Every sentence adds meaningful information.

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

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

The tool has six parameters, zero schema descriptions, and no annotations, yet the description leaves most parameter semantics unexplained. Output schema existence reduces the need to describe return values, but an agent still lacks essential guidance on how to fill parameters 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?

Schema description coverage is 0%, and the description does not explain the roles of target, message, mode, author, content, or is_pinned. The mention of disk files and virtual memories hints at how target/content might be used, but it is not enough to compensate for the complete lack of parameter documentation.

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

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

The description states a specific action: 'Crée un instantané horodaté d'un document dans le CAS', identifying both the resource (document) and storage context (Content-Addressable Storage). It also distinguishes this tool from sibling tools like list_commits, restore_commit, and prune_commits by emphasizing creation of a snapshot.

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

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

The description gives useful context about when to use the tool: it supports disk files and virtual memories/drafts without a file. However, it does not explicitly state when not to use it or point to an alternative among the sibling tools, leaving selection guidance only implied.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses output type, mode behavior, and a retention threshold. It does not disclose whether artifact generation writes state, requires specific repository context, or has side effects.

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

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

Two compact sentences with the main action front-loaded and no filler. Technical jargon ('chirurgicale', 'Antigravity') slightly reduces clarity but not 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 an 8-parameter, 1-required tool with no annotations and no parameter descriptions, the description covers only modes and output type. The output schema may cover return shape, but input semantics and intended invocation context remain largely 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% and the description only hints at the `mode` values ('paper'/'draft'); the required `target`, plus `content`, `brain_dir`, `to_commit_id`, `from_commit_id`, and `artifact_name`, are left undefined. This is insufficient for a tool with eight 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 opens with an active verb and concrete resource ('Génère la vue différentielle... AST') and names the produced artifact ('artéfact Markdown Antigravity'). It clearly separates this from sibling commit/list/prune tools, though it never explicitly contrasts with a sibling.

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

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

It distinguishes the paper and draft modes with their targets (LaTeX/Markdown with KaTeX vs tag audit/retention >=90%), giving mode-selection guidance. It does not state when to prefer this tool over sibling git-history tools or list prerequisites/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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals only that commits carry timestamp and author metadata; it does not state whether this is read-only, whether authentication or preconditions are required, how mode/target alter behavior, or what the listing returns. For a tool with zero annotation coverage, this is a significant 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 single sentence is well-formed and front-loads the core action, with no wasted words. However, for a three-parameter tool it is underspecified rather than efficiently concise; brevity here comes at the cost of missing necessary context.

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

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

The output schema covers the return format, but all three parameters are undocumented and there are no annotations to fill the gap. mode and target in particular are opaque, leaving an agent unable to invoke the tool meaningfully. Incomplete for a tool of this parameter count.

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 explains none of the three parameters (mode, limit, target). The schema only supplies defaults, not semantics, so the agent cannot determine what values to pass. With three undocumented parameters and no compensatory text, this is the weakest dimension.

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 commits) plus the storage context (CAS) and what metadata is returned (timestamp, author). It is distinguishable from restore_commit and prune_commits on name alone, though it never explicitly contrasts with commit_document or record_git_pull_event. Clear purpose, minor gap in sibling differentiation.

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

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

No guidance on when to use this tool versus the five siblings. There is no mention of when it applies, what scenario routes here, or any exclusions. The presence of siblings like get_diff_artifact and restore_commit makes this omission more consequential.

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

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

With no annotations, the description carries the full burden. It discloses the core destructive behavior (purge) and the conditional protection of pinned baselines, but it does not clarify the selection algorithm for enforcing max_size_mb (e.g., which snapshots are deleted if none are expired) or state that deletion is irreversible. This ambiguity is significant for a destructive 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 two sentences with no filler. It front-loads the core purpose and then adds a precise condition, making every word count.

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

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

For a 3-parameter tool with an output schema, the description covers the main function and parameter roles adequately. However, the underspecified size-overshoot deletion behavior leaves an agent unable to fully predict consequences, and the presence of an output schema does not compensate for that behavioral gap. Overall, the description is usable but not fully complete for a destructive operation.

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

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

Schema description coverage is 0%, yet the description gives functional meaning to all three parameters: ttl_days relates to TTL-based expiry, max_size_mb to the size cap, and keep_baselines to the protection of pinned baselines. It stops short of explicitly defining TTL in days or the exact behavior when keep_baselines=false, but it provides enough context for an agent to understand parameter roles.

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

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

The description states a specific verb ('Purge') and resource ('les snapshots expirés') with distinct mechanisms (TTL and max_size_mb). It also mentions conditional protection of pinned baselines, clearly differentiating it from sibling tools like list_commits or restore_commit.

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 cleanup tasks (pruning expired snapshots and enforcing size limits), but it does not explicitly state when to use this tool vs. alternatives or any exclusions. An agent must infer the intended context from the purpose rather than receiving direct guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the core actions (pull, detect conflicts, record snapshot) and implies mutability via 'Synchronise', but does not detail side effects, permissions, conflict resolution behavior (only detection), or the nature of the CAS snapshot. It omits important context like what happens on conflict or whether local changes are preserved (though autostash is mentioned, it's not elaborated).

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 front-loads the primary action (sync via git pull) and then adds details (conflict detection and snapshot recording). It is concise and to the point, though the French wording is dense and could benefit from breaking into two sentences for clarity. It earns high marks for brevity and front-loading.

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

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

This is a mutating operation (git pull) with potential side effects, and no annotations are present to cover safety or behavior. The description is brief and does not explain error handling, return values, or what happens when conflicts occur. An output schema exists, which could cover return values, but the description itself does not address completeness for an agent deciding to invoke it safely. Given the complexity and side effects, it 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?

Schema description coverage is 0%, so the description must explain the parameters. It mentions '--autostash' in the command but does not clarify that this maps to the autostash boolean parameter. The repo_path parameter is not described at all. The description fails to compensate for the schema's lack of documentation, leaving agents without sufficient understanding of what each parameter does.

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 purpose: it synchronizes a Git repository via git pull --rebase, detects conflicts, and records a timestamped CAS snapshot. This specific verb+resource combination distinguishes it from siblings like commit_document (commit), get_diff_artifact (diff), restore_commit (restore), list_commits (list), and prune_commits (prune). The action is unambiguous.

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 (when you need to pull and record a snapshot) but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or conditions under which another sibling might be preferred. It relies on the obvious distinction from siblings, but lacks explicit routing 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that dry_run=True previews without modifying the disk, which is useful, but it does not disclose what happens when dry_run=False (e.g., whether it overwrites the current document, whether it is destructive, whether it requires specific permissions). For a restore operation that likely mutates state, this is a significant 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 very short and front-loaded with the main action. The dry_run clarification is useful and placed second. However, it is so brief that it misses important behavioral details, so it is not maximally effective.

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 3 parameters, no annotations, and an output schema, the description should explain the restore behavior, the meaning of target, and the effect of dry_run=False. It only covers dry_run. The output schema exists but the description does not mention what the restore result looks like. This is incomplete for a mutation-capable 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 0%, so the description must compensate for the schema's lack of parameter documentation. The description only explains dry_run's behavior; it does not explain commit_id format, target's purpose, or how they interact. With 3 parameters and zero schema descriptions, this is insufficient.

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

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

The description states a specific verb ('restore') and resource ('a document from its commit ID in the CAS'), which clearly identifies the tool's core function. It does not explicitly differentiate from siblings like get_diff_artifact or list_commits, but the restore action is distinct enough that an agent can infer its purpose.

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: restoring a document from a commit ID, with dry_run for previewing. It does not explicitly state when to use this tool versus alternatives like get_diff_artifact or prune_commits, nor does it mention any prerequisites or side effects. The dry_run hint provides some guidance but not full routing.

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