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

No annotations are provided, so the description carries the full behavioral burden. The name 'checkpoint' is ambiguous about read vs. write, and the description says nothing about side effects, persistence, permissions, or whether calling it mutates state. It does not resolve the ambiguity.

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 short, front-loaded fragment with no wasted words, but it is under-specified rather than genuinely concise, leaving core questions (verb, side effects, scoping) unanswered.

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

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

With no annotations, no output schema, and only partial parameter coverage, the description should do more work. It hints at returned fields but omits the operation type, scoping behavior, and any behavioral constraints, leaving the definition inadequate for a 2-param resumable-state 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?

Two parameters at 50% schema coverage: 'project' is documented in-schema but 'task' is not. The description never mentions either input, instead listing returned content (criteria, reports, budget), so it adds no meaning about how task/project scope the result.

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

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

The description names the resource (current task state) and enumerates its contents (criteria, latest reports, budget), so an agent can infer it returns resumable state. However, there is no clear verb (get? write? update?) and nothing distinguishes it from siblings like 'report' or 'remember', which could also surface 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?

The only usage signal is the phrase 'for resuming', which hints at a scenario but never states when to prefer this over 'report', 'search', or 'remember'. No exclusions, prerequisites, or alternatives 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?

No annotations are provided, so the description carries the full burden. It discloses that tests are listed and executed against current code, but says nothing about permissions, side effects, reversibility, or what happens when tests fail.

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, with the primary listing purpose front-loaded. The second sentence is slightly telegraphic but still earns its place by explaining the run_template placeholder.

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

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

With no annotations, no output schema, an ambiguous tool name, and incomplete parameter documentation, the description is too thin. It does not explain return values, output shape, or how the listed tests relate to the subsequent run.

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 low at 33%, so the description must compensate. It adds useful meaning for run_template by noting it contains a {files} placeholder, but it leaves cwd undocumented and adds little for project beyond the schema's own 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 uses specific verbs ('List', 'run') on a clear resource ('pre-existing tests' / 'original tests') and explains the run_template mechanism. It does not differentiate this tool from siblings like search or run, so it falls short of a 5.

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

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

It implies the context of rewritten or deleted lines, but never states when to choose guard over search, run, report, or checkpoint. No prerequisites, exclusions, or alternative conditions 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?

With no annotations, the description carries the full burden, and it does add one meaningful behavioral fact: the entry is stored "unverified" and framed as a proposal, so the agent knows this is a tentative write rather than an authoritative one. It still omits permission requirements, whether repeated calls deduplicate, and what the stored result looks like.

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

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

A single front-loaded sentence with no filler; the key constraint (not visible in code / unverified) arrives immediately. It is efficient, though one more clause on what belongs in title vs content would not have hurt.

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 write tool with no annotations and no output schema, the description does convey the essential behavioral point (unverified proposal). It falls short on parameter meaning, which matters given three required fields and near-zero schema coverage.

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 20% (just the project field), and the description explains none of the five parameters. Title, content, source and domain — three of which are required — have no semantics in either the description or the schema, so an agent must guess what belongs in each.

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 pairs a specific verb ("Propose") with a concrete resource ("a project lesson") and adds a scope qualifier ("not visible in the code"), so an agent can tell broadly what the tool captures. It does not, however, differentiate itself from any of the terse siblings (report, checkpoint, guard), which are plausible places to record information.

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?

"not visible in the code" implies a usage condition for what belongs here, which is a reasonable implied trigger. But there is no explicit guidance on when to prefer this over siblings like report or checkpoint, and no stated 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?

With no annotations, the description carries the full burden and it does disclose one genuinely non-schema behavioral rule: rewritten pre-existing tests require test_changes entries formatted 'PATH: why'. Beyond that it is silent on whether calling this terminates the session, whether repeated calls are allowed, or what side effects occur.

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

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

Two tight sentences with no filler, and the primary directive is front-loaded ahead of the special-case rule. Minor ambiguity in 'changed files' (which does not map cleanly to a parameter name) is the only cost.

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?

There is no output schema, so the description could explain what reporting produces, but it does not. For a 6-parameter terminal tool with 17% schema coverage, leaving artifacts and the project scope largely unexplained is a meaningful gap.

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

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

Schema coverage is only 17% (just 'project'), so the description must compensate. It names status, summary, and evidence, and clarifies the test_changes format, but it never explains 'artifacts' or disambiguates 'changed files' from the artifacts/test_changes parameters, leaving key parameters undocumented.

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

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

The description gives a specific action ('Finish the task') plus the content to supply (status, summary, changed files, evidence), so the agent knows this is the terminal reporting step. It is clear on its own, but it never names or contrasts itself against plausible alternatives like checkpoint, remember, or guard, which are the tools it could be confused with.

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?

'Finish the task' implies this is called at the end, which is useful implied timing. However, there is no explicit statement of when-not to use it (e.g., vs. checkpoint for intermediate progress) and no named alternative, so the routing is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return shape (exit code, failing tests, first failure, log path with full log on disk), the meaning of full=true, synchronous waiting behavior, and the refusal-stop-and-report failure protocol. It omits permission/auth needs, the nature of the 'task budget', and any side-effect profile for arbitrary commands.

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?

Terse, front-loaded, and free of filler; the core action and its return contract come first, then the full flag and the refusal protocol. The telegraphic phrasing ('a refusal means: stop and report') is efficient but slightly compressed.

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 6-parameter command-execution tool with no annotations and no output schema, the description covers return values and control flow but leaves the command contract, timeout behavior, and budget semantics unexplained. Adequate but with clear gaps given the tool's complexity.

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%: cwd, project, and override are documented in-schema, while command, full, and timeout are bare types. The description partially compensates by explaining full=true ('complete check') but adds nothing for command or timeout, leaving half the surface undocumented.

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

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

States a specific verb and resource: 'Run a test/check command in the project', which is a clear, concrete action. It does not explicitly name a sibling to contrast against, but none of the siblings (start, report, search, remember, checkpoint, guard) overlap with test execution, so an agent can still place it.

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 operational guidance ('Wait for the result; a refusal means: stop and report') and context ('under the task budget'), which implies when this tool is appropriate. However, it never states when to use it versus alternatives or when not to run it, leaving usage inference to the reader.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely useful behavior: verified lessons/facts are returned in full while code is returned only as file pointers. That is real result-shaping context. It says nothing, however, about ranking, limits, permissions, or what happens on an empty match.

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

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

A single front-loaded sentence with no padding; the scope and result shape come first. It is slightly compressed to the point of being cryptic ('code as file pointers' takes a moment to parse), but nothing is wasted.

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

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

For a 4-parameter tool with no annotations, no output schema, and 25% parameter coverage, this description is too thin. It partially covers return semantics but omits parameter meaning and usage context that the agent needs to invoke it 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 only 25% (just the project root), so the description should compensate for query, limit, and domain — and it does not. None of those three parameters are explained anywhere, leaving their semantics (e.g. limit default, domain values) undocumented.

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

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

States a specific verb (Search) and resource (project memory) and even characterizes the result shape: verified lessons/facts in full, code as file pointers. It is clearly distinguishable from siblings like remember/checkpoint/guard, which are write-oriented, though the name 'search' alone would be ambiguous without the description.

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, no prerequisites, and no mention of alternatives. The agent is not told when to search memory versus using remember, checkpoint, or report, nor what a good query looks like.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose real behavior beyond the name: it snapshots pre-existing tests and returns memory pointers/lessons plus a run budget, which hints at session lifecycle and side effects. It stops short of stating whether state is persisted, what preconditions must hold, or what happens if called twice.

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 lead with the action and add only operational facts, with no filler. The phrase "memory pointers/lessons" is slightly opaque and mildly compressed, keeping it just below a 5.

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 10 parameters, only 50% schema coverage, no annotations, and no output schema, the description should do more. It never explains the required goal/acceptance contract or what the returned "run budget" means, leaving an agent to infer how to shape the call at the start of every task session.

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 baseline case. "Run budget" loosely maps to max_runs/max_after_green/max_fail_streak, but the description leaves title, goal, acceptance, domain, allow_paths, and query unexplained and adds no syntax or format detail beyond the schema. Adequate but not compensating 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?

The description states a concrete verb+resource ("Start a coding task") and adds the mechanics: snapshotting pre-existing tests, returning memory pointers/lessons, and a run budget. It is clear what the tool does, though it never names a sibling such as run or checkpoint, so differentiation relies on inference from "Call once per 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?

"Call once per task" gives a usage constraint that implicitly separates it from the per-run sibling 'run', which is useful. However, there is no explicit when-not guidance, no stated prerequisites (e.g. that project root is only needed once per session), and no routing advice toward report, checkpoint, or guard.

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