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. 'Add' implies a mutation, but it says nothing about permissions, whether an existing entry is overwritten or rejected, whether the campaign/slug must already exist, or what a successful call returns. For a write tool with zero annotation coverage this is a real 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?

A single tight sentence with the action front-loaded and no filler. It is appropriately sized for the message, though it is arguably too short to count as strongly structured.

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 mutation with no annotations and no output schema, the description should at minimum flag required inputs (campaign, slug, when), the duplicate-handling behavior, and that it operates within a campaign context. None of that is present.

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% across all 8 parameters, including the enum of interview types and the datetime format example, so the schema does the documentation work. The description adds no parameter meaning beyond it, which places this at the baseline.

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 ('Add a new interview entry') qualified by scope ('for an application'). That is enough to distinguish it from read-side siblings like list_interviews or read_prep, and from mark_interview, though it never names those siblings 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 when-to-use guidance and no mention of alternatives. The toolset contains list_interviews and mark_interview, and nothing here tells an agent which one applies when it wants to record vs. view vs. update interview state.

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, yet it only states what is aggregated. It does not disclose whether this is a read-only operation, how costly scanning all retro files is, or what form the aggregated result takes. Only the bare 'aggregate' semantics are inferable.

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 action and scope come first. It is efficient, though the extreme brevity leaves little room for the context the tool otherwise lacks.

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?

Parameters are fully documented by the schema and there is no output schema to explain, so the remaining need is behavioral context. For a tool that scans every retro file in a campaign, the description says nothing about result shape, ordering, or cost, leaving a modest but real 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 description coverage is 100%, so the schema already documents campaign, targetRole, and includeAbandoned. The description reiterates the campaign scoping but adds no semantics for the role filter or abandoned-inclusion behavior. Baseline 3 applies when the schema does the heavy lifting.

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 a specific verb (aggregate), the derived resource (weak topics), and the source scope (all application retro files for a campaign). This distinguishes it from read_retro and append_retro, which operate on a single retro, without explicitly naming them.

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 guidance on when to use this tool versus read_retro or post_mortem, no stated prerequisites, and no exclusions. The scope phrase implies batch use but the agent must infer when aggregation is appropriate.

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 the key side effect (an append to qa.md, implying non-destructive but cumulative writes). However it says nothing about permissions, whether answering invokes an LLM, cost/latency, or how the append behaves on repeat 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?

A single front-loaded sentence with the action, target, and destination artifact; nothing wasted and nothing buried.

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 mutating tool with neither annotations nor an output schema, the description covers purpose and the write side effect but omits the LLM-driven nature, save/skip semantics, and any error or auth conditions. Adequate minimum, with clear 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 description coverage is 100%, so all six parameters including steer, noSave, and imagePath are already documented in the schema. The description adds no syntax or format meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (answer) plus resource (question for an application) and names the artifact it writes (qa.md), which distinguishes it from the read_qa sibling. It falls short of 5 only because it never explicitly names that alternative.

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 statement of when to use this over read_qa, no prerequisites (e.g. whether an application or campaign must exist first), and no guidance on the steer/imagePath inputs. Usage is only implied by the verb.

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

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

With no annotations, the description carries the full behavioral burden. It signals an additive write but omits the consequential noCarryOver behavior that discards prior weak topics/notes, says nothing about whether a retro is created when absent, and gives no permission or rate-limit 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?

A single tight sentence with no filler, and the verb and target resource are front-loaded. It is efficient, though arguably under-specified rather than optimally concise.

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 seven-parameter mutation tool with no annotations and no output schema, one sentence is thin. Key behaviors an agent needs before calling it — the destructive noCarryOver flag, campaign/slug requirements, and whether it creates or only appends — are absent.

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 schema already documents all seven parameters including their types and meanings. The description surfaces only two of them (weak topics, notes) and adds no syntax, format, or interaction detail beyond the schema, which is the expected baseline here.

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 ('Append') and resource ('retro') plus the content being added (weak topics and notes). It does not, however, differentiate itself from close siblings like read_retro or aggregate_retros, so the agent must infer the distinction.

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 no explicit when-to-use guidance, no prerequisites, and no reference to an alternative tool. The word 'existing' faintly implies a retro must already exist, but nothing tells the agent when appending is preferable to read_retro or aggregate_retros.

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 does not disclose that generation is an LLM call, that the result is saved to file by default (implied only by the noSave parameter), any cost/latency, or auth requirements. For a generation tool 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?

A single front-loaded sentence with no waste. It is efficient, though arguably minimal enough that it sacrifices useful detail for brevity.

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 a generation behavior that persists output by default, the description is too thin. It omits side effects (file save), input format expectations, and what the generated result looks like.

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 slug, steer, noSave, and campaign are already documented. The description adds no additional meaning about any of them; baseline 3 applies.

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

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

Specific verb ('Generate') plus resource ('tailored cover letter') plus scope ('for an application'). It does not explicitly distinguish itself from the sibling read_cover_letter, but the generate-vs-read contrast is inferable from the verb.

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 pointer to alternatives such as read_cover_letter for retrieving an existing letter. The agent must infer the operating context entirely.

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 usefully discloses the scope of checks performed, but says nothing about whether it mutates anything, requires specific access, or what the result looks like. The check enumeration is real value; the safety/mutation profile is absent.

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 parenthetical sentence that front-loads the verb and resource and packs the detail into a compact list. Nothing is wasted and nothing is buried.

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 two-parameter diagnostic tool with no annotations and no output schema, the description covers purpose but not behavior — no indication of whether it is read-only, whether it can auto-fix, or how to act on results. Adequate minimum, but incomplete for an unannotated 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 coverage is 100%, so both parameters are already documented in the schema. The description's phrase 'campaign or application' loosely mirrors the campaign/slug split, adding only marginal meaning beyond the structured fields. Baseline 3 applies when the schema does the heavy lifting.

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 ('diagnose') and two concrete resources (campaign or application) and enumerates the problem classes it detects (missing files, invalid frontmatter, toolhash mismatches). It is clearly distinguishable from data-reading siblings, though it never explicitly contrasts itself with 'repair', which is the natural fix-counterpart.

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?

Usage is implied by the name and the enumerated issue types — you run it when you suspect something is broken — but there is no explicit when-to-use statement, no mention of when to use 'repair' instead, and no prerequisites. An agent can infer intent but is not guided.

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 does not disclose whether this is a read-only scrape (network fetch, possible failures/timeouts), whether results are persisted under the required 'campaign', or what the caller gets back beyond the vague phrase 'structured job description'.

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 sentence with the verb and resource front-loaded and no filler. It is efficient, though its brevity is also the source of the missing usage 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?

For a 3-parameter tool with no annotations and no output schema, the description leaves too much uncovered: which of url/text is expected, that neither is schema-required while campaign is, and what 'structured' means in terms of returned fields.

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 schema already documents url, text, and campaign. The description only echoes the url/text duality and adds no format, precedence, or campaign semantics beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb (extract) and resource (structured job description) plus the two accepted input sources (URL or raw text). It does not differentiate from any sibling, but the siblings listed are in an unrelated domain so the purpose is still 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?

No when-to-use guidance, no prerequisites, and no instruction on whether to supply url, text, or both. The description mentions two input modes but never states the selection rule or what happens if both are passed or neither is passed.

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 exist, so the description carries the full burden. It adds one genuinely useful behavioral fact — that secrets are redacted in the output — but omits whether this is a read-only operation, whether permissions are required, or how redaction affects the returned config.

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

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

Front-loaded verb+resource with no wasted words; the redaction caveat is placed in parentheses as a secondary detail. It is efficient, though brevity here shades into under-specification.

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 no annotations, no output schema, and two confusable siblings, this description is too thin: it neither explains the returned configuration shape nor routes the agent away from read_campaign_config/list_campaigns.

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?

One parameter with 100% schema coverage, and the schema already supplies the name plus an example ("default"). The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

States a specific verb (get) and resource (campaign configuration), so the basic purpose is clear. However, siblings include both read_campaign_config and list_campaigns, and the description makes no attempt to distinguish this tool from them — an agent cannot tell which of the three to pick.

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 exclusions, and no pointer to the obvious alternatives (read_campaign_config, list_campaigns). The agent must infer usage entirely from the name.

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 does not state whether the path is absolute or relative, whether it validates that the campaign exists, what happens with an unknown campaign name, or whether it creates the directory. For a resolver with zero annotation coverage this is a notable 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?

One short, front-loaded sentence with no waste. It is appropriately sized, though it is a fragment that could state one more useful fact instead of stopping.

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?

A simple one-parameter tool with full schema coverage and no output schema, so not much explanation is needed. Still, with no annotations the description should say what the return value is (a path string) and how errors are handled, which it omits.

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

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

Schema description coverage is 100%, and the schema documents the single required campaign parameter with an example. Baseline for a fully documented single-parameter schema is a 4; the description adds nothing beyond the schema but does not need to.

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 (resolve) and resource (campaign root directory path), which is clearer than the bare name get_root. Siblings like get_campaign and read_campaign_config are related but the description's focus on a filesystem path rather than campaign metadata or config distinguishes it reasonably well.

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 call this versus get_campaign, read_campaign_config, or list_campaigns. The agent must infer that this returns a path for filesystem operations rather than campaign data.

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 and no output schema, the description carries the full behavioral burden. It does usefully disclose the shape of the result (which aggregate dimensions are returned), which compensates somewhat for the missing output schema, but it says nothing about whether the operation is read-only, requires permissions, or is scoped to a specific campaign.

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 leads with the verb and then lists outputs. Every clause earns its place and nothing is redundant.

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 read-only aggregate tool with fully documented parameters but no output schema, enumerating the computed dimensions is exactly what an agent needs to know the return shape. The only gap is the absence of any routing guidance versus sibling listing/retrieval tools.

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% with all four parameters documented (since, campaign, targetRole, employmentType) including an enum. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb (Compute) and resource (campaign statistics) and then enumerates the exact breakdowns produced: status, role, site, employment type, funnel, interview entries, and this-month delta. No sibling tool (get_campaign, list_campaigns, read_campaign_config) does aggregation, so the agent can distinguish it immediately.

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 says what is computed but never states when to reach for this tool rather than get_campaign, list_applications, or aggregate_retros, nor does it mention any prerequisites. There is no when-to-use or when-not-to-use guidance at all.

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

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

With no annotations, the description carries the full behavioral burden. It says nothing about what initializing actually does (side effects, directory/file creation), what happens if the campaign already exists, or whether it overwrites existing config. For a creation operation this is a meaningful 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?

A single compact sentence with the action front-loaded and no wasted words. It is efficient, though it underspecifies rather than over-explains.

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 creation tool with no annotations and no output schema, the description omits prerequisites, side effects, and conflict/overwrite behavior. An agent can guess the inputs but not the consequences of calling it.

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 schema already documents cvPath, campaign, githubUser, and linkedinUrl. The description echoes three of those four (CV, GitHub, LinkedIn) and omits 'campaign', adding essentially no meaning beyond the schema — the baseline of 3 applies.

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

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

States a specific verb and resource ('Initialize a new campaign'), which separates it from siblings like remove_campaign and rename_campaign. It does not explicitly name which sibling it supersedes or how it relates to list_campaigns/get_campaign, so it stops short of full 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?

The description gives no when-to-use guidance: no mention that this is the first step before other campaign tools, no preconditions, and no named alternatives. The only usage cue is the list of optional inputs, which is weak.

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 implies a copy (source preserved, KB mutated) and names accepted formats, but says nothing about duplicate handling, overwrite behavior, permissions, or whether ingestion is synchronous.

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 zero filler that conveys verb, resource, formats, and destination.

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 simple two-parameter ingest tool with no output schema and no annotations, the description covers the basics. However, it omits the when-to-use distinction from kb_update and the behavior on re-ingesting existing documents, which matter 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 description coverage is 100% and both parameters are documented there, so baseline is 3. The description adds the accepted file formats (PDF, DOCX, MD, TXT), a small amount of meaning beyond the schema's 'file or folder paths'.

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 (copy) and resource (knowledge-base docs) plus the destination (campaign) and supported file types. It is clear what the tool does, though it does not distinguish itself from the sibling kb_update.

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 versus kb_update, nor on prerequisites such as whether paths must exist or the campaign must already be initialized. The agent must infer usage from the name 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?

No annotations are provided, so the description carries the full burden. 'Re-sync' implies a mutation that could overwrite or disturb the existing knowledge base, but the description never says what gets replaced, whether the operation is idempotent, what permissions/failed-init state it requires, or how long it runs.

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 resource front-loaded and zero filler. It is efficient, though the brevity borders on under-specification rather than true 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 mutation-style tool with no annotations and no output schema, the description is too thin: it does not explain the effect on existing data, the init dependency, or the outcome. An agent could invoke it correctly but cannot predict consequences.

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

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

Schema coverage is 100% and the single 'campaign' parameter is documented with an example ('default') in the schema itself. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

States a specific verb ('re-sync') and resource ('the knowledge base') and scopes it to sources recorded at init, which distinguishes it from the sibling kb_add (additive) reasonably well. However, 're-sync' is left undefined, so the agent must infer what the operation actually changes.

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 comparison to the obvious alternative kb_add. The phrase 'recorded at init' implies a dependency on init but never states it as a condition for calling this tool.

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 never states ordering, pagination, result limits, or whether an empty filter set returns all applications, and it does not disclose that the required campaign scopes the result set. Only the read-only nature is inferable from 'List'.

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 names the operation first and the filter dimensions after. It is efficient, though the terse phrasing leaves no room for the behavioral context the rest of the definition lacks.

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

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

With no annotations and no output schema, the description is the only place behavioral context could live, yet it omits pagination, ordering, default result scope, and the significance of the required campaign parameter. For a six-parameter list tool this is notably thin.

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

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

Schema coverage is 100%, so the enum values, tag AND-combination, and case-insensitive filter behavior are already documented in the schema. The description's filter list largely restates the schema and adds no syntax or format detail beyond it, which matches the baseline 3.

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 clear verb+resource ('List applications') and enumerates the filter dimensions, so the agent knows this is a filtered read of applications rather than interviews or campaigns. It does not explicitly differentiate itself from siblings like show_application or list_interviews, but the resource 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?

No guidance on when to use this versus show_application, list_interviews, or get_stats, and no prerequisites (such as the required campaign being in scope) are mentioned. The enumerated filters imply a search use case, but nothing tells the agent when this is the right choice.

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

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

With no annotations, the description carries the full behavioral burden. 'List all ... under the data root' implies complete enumeration with no filtering and a read-only nature, and the zero-parameter schema is consistent with that, but nothing is said about ordering, pagination, or return shape.

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 scope phrase 'under the data root' earns its place by bounding the enumeration.

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 trivial no-arg list tool with no output schema and no annotations, the description is adequate but leaves the return contents (what a campaign record looks like) and any ordering/pagination unspecified.

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 the baseline is 4 and there is nothing parameter-side for the description to compensate for.

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 ('List') and resource ('campaigns') plus scope ('all... under the data root'). It is distinguishable from siblings like list_applications or list_interviews by resource, though it does not explicitly contrast itself with get_campaign or read_campaign_config.

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 versus get_campaign (single campaign), read_campaign_config, or the other list_* tools. The agent must infer that this is the enumeration entry point from the name 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?

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only operation but says nothing about pagination, result ordering, empty-state behavior, or whether interviews from all campaigns are included.

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 dense sentence with the resource and scope front-loaded. Nothing is wasted or repeated.

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?

Adequate for a simple two-parameter read tool with a fully documented schema. However, with no output schema and no annotations, it should at least hint at what is returned or how results are ordered.

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 both required parameters (slug, campaign) are already documented in the schema with examples. The description adds no scoping detail beyond what the schema provides, making the baseline 3 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?

Clear verb (list) plus resource (interviews) scoped to an application. An agent can distinguish it from add_interview and mark_interview, though the description never names those siblings to make the routing explicit.

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 such as add_interview or mark_interview. The context of use is only implied by the verb '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?

With no annotations, the description carries the full behavioral burden, yet only implies a mutation. It says nothing about whether status transitions are validated, whether notes replace or append, whether the operation is reversible, or what permissions/state are needed. The enumeration of valid statuses lives only in the schema.

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 zero filler. It is efficient, though the brevity borders on under-specification rather than genuine 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 5-parameter mutation tool with no annotations and no output schema, the description omits the notes parameter entirely, never explains the required campaign/slug/index coordinate system, and gives no return-value expectations. It is too thin for 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 description coverage is 100%, so all five parameters (including the enum for status and 0-based index) are already documented in the schema. The description adds no syntax, format, or interaction detail beyond that, so the baseline of 3 applies.

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

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

The description gives a specific verb ('change') and resource ('status of an existing interview'), which cleanly separates it from add_interview, list_interviews, and read_* siblings. It stops short of explicitly naming which sibling to prefer, but the purpose 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?

There is no guidance on when to use this tool versus add_interview or list_interviews, no mention of prerequisites, and no indication of what 'existing' requires (campaign/slug/index must already resolve). The agent must infer all routing from the name 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?

With no annotations, the description carries the full burden. It usefully discloses the output contract ('human-readable markdown table, not JSON'), which is real behavioral value since there is no output schema. However, it does not state that the tool is read-only/side-effect free, nor whether it requires an initialized project — both meaningful for an unannotated tool.

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

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

Two tight sentences with the purpose front-loaded and the return-format caveat second. Every clause earns its place; there is no filler.

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

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

Given zero parameters and no output schema, the description covers the essentials, including the non-JSON return shape that an agent would otherwise have to discover empirically. It could be more complete by noting the tool is read-only and any project-context prerequisite.

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 and the schema has no properties, so there is nothing to disambiguate; the baseline of 4 applies. No parameter meaning is missing.

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 ('Show file ownership rules') and unpacks the ambiguous term 'ownership' with a parenthetical about which files the tool writes vs. which the user can edit. It is distinguishable from the read_*/list_* siblings, but it never names a related tool (e.g., read_config, get_root) to sharpen the boundary, so it stops short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance anywhere in the description; no trigger condition, prerequisite, or alternative tool is mentioned. For a zero-parameter informational tool this is less damaging, but the agent is left to infer that this is the diagnostic command to run when unsure about write access.

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 says it generates a plan but does not state whether this is a read or write operation, whether it creates or modifies records, what permissions are required, or what side effects occur. The single verb 'Generate' gives minimal 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, front-loaded sentence with no wasted words. It immediately states the action and output, making it easy to scan and parse.

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 six parameters, no output schema, and no annotations, the description is too thin. It does not explain what a 'post-mortem learning plan' contains, how parameters like steer, weakTopics, or status affect the output, or when this tool should be chosen over related retros tools. The schema covers parameter descriptions, but the definition lacks sufficient context 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 description coverage is 100%, so all six parameters are already documented in the schema. The description adds no meaning beyond the schema, only saying the plan is 'for an application', which loosely relates to the slug parameter. Baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource: 'Generate a post-mortem learning plan for an application'. It clearly tells the agent what the tool produces. However, it does not distinguish the tool from similar siblings such as aggregate_retros, append_retro, or prepare, leaving the agent to infer the boundary.

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 offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, timing, or exclusions, and it does not reference any sibling tool. The agent is given only the bare purpose.

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 trait: that steer/days are inert when topics is supplied. It still omits whether generation overwrites an existing plan, permission/prerequisite needs, and any side effects on stored state.

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 no filler; the core capability is stated first and the mode-specific caveat second.

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 5-parameter, 2-required mutation tool with no annotations and no output schema, the description covers modes but leaves the campaign/slug requirements and the resulting artifact unexplained, so it is only 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 coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining that topics triggers an append mode which renders steer and days ineffective, clarifying parameter interaction beyond the schema's per-field docs.

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: generating or appending topics to a pre-interview prep plan, which clearly distinguishes it from the read-side sibling read_prep. It does not name or contrast any sibling explicitly, so it stops 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 describes two operational modes (generate a fresh plan vs. append topics) and notes steer/days are ignored in append mode. However, it never says when an agent should choose generate versus append, nor how it relates to read_prep or list_interviews, leaving the usage decision implicit.

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 adds the useful detail that output is redacted, but it does not clarify read-only safety, authorization requirements, or whether any 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though the parenthetical redaction note carries most of its added value.

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 simple one-parameter read tool with no output schema, the description is minimally adequate. It leaves open what the campaign configuration contains, how redaction affects fields, and whether authorization is required.

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

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

Schema coverage is 100%, and the single campaign parameter is fully documented in the input schema. The description adds no parameter-level detail beyond what the schema already provides, which is the expected baseline.

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 and resource: read campaign configuration. It clearly distinguishes the campaign-level config from a generic config read, but it does not explicitly differentiate itself from siblings such as read_config or get_campaign.

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 guidance on when to use this tool versus read_config, get_campaign, or list_campaigns. The intended usage is only implied by the tool name and description.

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 does disclose a meaningful trait — "secrets redacted" — which tells the agent the return is sanitized, but it says nothing about permissions, scope resolution, or failure behavior for a config read.

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 sentence with no wasted words; the redaction caveat is parenthetical and secondary.

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 read with no output schema and no annotations, the description covers the essentials and adds the redaction detail. It is nearly complete, though scope/auth context would round it out.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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 (Read) and resource (global configuration). The qualifier "global" usefully distinguishes it from the sibling read_campaign_config, which is campaign-scoped, though the description does not explicitly name 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?

Usage is only implied: the agent can infer this is the read counterpart to update_config, and that it targets global rather than campaign scope. There is no explicit when-to-use/when-not guidance or named alternative.

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. 'Read' implies a non-mutating lookup, but the description says nothing about behavior when no letter exists, auth/scoping needs, or output shape.

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. 'existing saved' is mildly redundant but does not waste meaningful space.

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 simple two-parameter read tool with no output schema, the description is adequate but incomplete: it never mentions the error case (no saved letter) or whether it returns the letter body verbatim.

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% with both `campaign` and `slug` documented, so the baseline is 3. The description adds no parameter-level detail 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?

States a specific verb (read), resource (cover letter), and scope (an existing saved one for an application), which separates it from the sibling `cover_letter` (generation) and other `read_*` tools. It is clear without naming a specific sibling alternative.

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?

'existing saved' implies the letter must already have been created, hinting that `cover_letter` is the tool that produces it. However, no explicit when-to-use/when-not or prerequisite is stated, so usage is 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 the full behavioral burden. It does not disclose important traits such as what happens when no filters are supplied, whether reading the entire log could be large or slow, where the log file comes from, or whether permissions are required.

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 with no filler. It states the action, resource, and optional filters immediately, making it easy for an agent to parse.

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 simple read tool with all parameters documented in the schema, the description is minimally adequate. However, with no annotations and no output schema, it should clarify default behavior and output format more explicitly, especially since omitting tail may return the entire log.

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 schema already documents tail, level, and json fully. The description lists the parameter names and adds a small amount of context, but it misleadingly groups JSON format under 'filtering' and does not add syntax or default-value details 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 gives a clear verb and resource: 'Read the log file'. It also names the supported filters, so an agent can understand the basic operation. However, it does not distinguish this tool from nearby read_* siblings such as read_config or read_retro beyond the resource name.

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?

Usage is implied by 'Read the log file with optional filtering', but there is no explicit when-to-use guidance, no prerequisites, and no statement about when another sibling might be preferred. The optional filters provide some context but not real selection 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?

No annotations are provided, so the description carries the full behavioral burden. 'Read' implies a safe non-mutating operation, but the description says nothing about what happens if no prep plan exists, whether it requires the campaign to match, or what the response contains.

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 verb and resource front-loaded and no redundancy. It is efficient, though it leaves obvious questions (existence, return shape) unanswered rather than being maximally informative for its length.

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 a simple two-parameter read with fully documented params and no output schema, so the description is roughly adequate. However, with no annotations and no output schema, it should still say what the read yields or how it fails when no plan exists.

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% (both 'slug' and 'campaign' are documented with descriptions and examples), so the schema already does the parameter work. The description adds no format, scoping, or default-value detail beyond it, making the baseline 3 correct.

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 ('Read') and a specific resource ('pre-interview prep plan for an application'), which is far more informative than the sibling naming pattern alone. It does not explicitly contrast itself with 'prepare' or 'read_cover_letter', but the resource noun makes the target 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?

No guidance on when to use this versus 'prepare' (which plausibly generates the plan) or the other read_* tools. The word 'existing' hints that it only works on a plan that already exists, but this constraint is never stated as a condition.

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 exist, so the description carries the full behavioral burden. The verb 'Read' does communicate a non-mutating operation, which is meaningful, but the description says nothing about behavior when the campaign does not exist, permissions, or what the profile contains. For a simple one-parameter read this is adequate but thin.

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 sentence with the scope constraint placed immediately after the action. No filler, 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 one-parameter read tool, the description covers the action and resource but does not describe what the returned profile contains or how a missing campaign is handled, and there is no output schema to fill that gap. Minimum viable rather than 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 100% and the single 'campaign' parameter already includes a type and an example ('default') in the schema. The description adds only the framing that campaign scopes the profile lookup, so 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 (read) and resource (candidate profile) scoped to a campaign, which cleanly separates it from the sibling update_profile. It does not explicitly contrast itself with other read siblings like read_campaign_config or read_cover_letter, 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?

The description gives no when-to-use or when-not-to-use guidance and names no alternatives. An agent must infer from the name alone that this is the read counterpart to update_profile, and nothing tells it how this differs from other read tools in 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?

With no annotations provided, the description carries the full behavioral burden but discloses little. "Read existing" implies a non-destructive operation, but nothing is said about permissions, pagination, empty-result behavior, or the relationship between campaign and slug.

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 efficient sentence with the resource front-loaded and no wasted words. It is terse to the point of being thin, but structurally sound.

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 simple two-parameter read tool with no output schema, the description is minimally adequate but omits key context: whether both campaign and slug are mandatory in practice, and what the returned Q&A entries look like.

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 both parameters (slug, campaign) are already documented in the schema. The description adds no syntax, format, or default-value detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a clear verb+resource ("Read existing Q&A entries") scoped to "an application", which distinguishes it from mutating siblings like answer_question. However it does not explicitly differentiate itself from related read tools such as read_cover_letter or read_retro.

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 guidance on when to use this tool versus alternatives like answer_question, nor any stated prerequisites. The read intent is only implied by the verb.

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 implies a safe read but says nothing about what happens if no retro exists, permission requirements, or what is returned — significant gaps for a tool whose entire job is retrieval.

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 resource and scope front-loaded; nothing is wasted, though it is arguably too terse given the missing behavioral 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?

For a parameter-light read tool with full schema coverage this is minimally adequate, but with no annotations and no output schema the description could still say what a retro contains or when one is available. It is complete enough to invoke but not to anticipate 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?

Schema description coverage is 100%, so both parameters (slug, campaign) are already documented in the schema. The description's 'for an application' only loosely echoes the slug parameter and adds no format or constraint detail, so baseline 3 is correct.

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 (read) and resource (retro/learning plan) scoped to an application, so the agent knows what it does. However, it does not distinguish itself from close siblings like append_retro or aggregate_retros, and the 'retro/learning plan' phrasing leaves the resource name slightly ambiguous.

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 such as aggregate_retros for summaries or append_retro for writes. The agent must infer the context entirely.

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 usefully discloses that removal is permanent and enumerates what gets cleaned (metadata, index, sidecars), but it says nothing about downstream effects on tracked applications/interviews or how the 'confirm' skip-prompt parameter interacts with the deletion flow.

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 the destructive verb and scope front-loaded. No filler, though it packs the cleanup list into one clause without room for the operational warnings an agent would want.

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 destructive tool with no annotations and no output schema, the description covers purpose and permanence but omits the confirmation-prompt behavior implied by 'confirm' and any indication of what a call returns or errors on.

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 schema already documents slug, campaign, and confirm. The description adds no parameter-level meaning beyond confirming the destructive nature, so the baseline of 3 applies.

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

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

Specifies verb (remove), resource (application folder), and scope (permanently, plus metadata/index/sidecars). It is clearly distinct from siblings like rename_application or remove_campaign, though it never names those alternatives 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 statement of when to use this versus alternatives such as remove_campaign, nor any prerequisites or warnings about the operation being irreversible beyond the word 'permanently'. Usage must be inferred entirely from the tool name.

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 the two most important traits: the operation is destructive and irreversible. However, it says nothing about the confirmation prompt behavior (relevant given the 'confirm' parameter), required permissions, or whether nested contents are also deleted.

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 zero filler; the destructive warning is placed prominently after the action. Nothing could be trimmed without losing meaning.

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-parameter mutation with no annotations and no output schema, the description covers the critical warning but omits confirmation-flow behavior and the scope of deletion (folder vs. contained data). Adequate but with clear gaps an agent would want resolved.

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 both parameters are documented in the schema, giving a baseline of 3. The description adds only that the target is a 'folder' and does not clarify the confirm-skip semantics beyond what the schema already states.

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 remove a campaign folder'), which is enough to distinguish it from read_campaign_config, get_campaign, and list_campaigns. It does not explicitly contrast itself with rename_campaign or remove_application, but the destructive remove 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?

No guidance on when this tool is appropriate versus siblings such as remove_application or rename_campaign, and no stated prerequisites or preconditions. The agent must infer that it is the campaign-deletion counterpart of the other campaign tools.

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 must carry the full behavioral burden. 'Rename' implies a mutation, but the description fails to disclose whether the rename is reversible, what happens to references, whether permissions are required, or any 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?

The description is a single, front-loaded phrase with no wasted words. However, for a mutation tool with no annotations, it is under-specified rather than optimally concise, so it falls short of a higher score.

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 a mutation tool with three required parameters, no annotations, and no output schema, the description should explain side effects, return behavior, or permission needs. It provides none of these, leaving the agent with insufficient context to invoke it 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?

Schema description coverage is 100%, so the schema already documents all three parameters (campaign, from, to). The description adds no parameter semantics beyond what the schema provides, making the baseline 3 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 states a specific verb (Rename) and resource (application folder), making the core action clear. It does not, however, distinguish this tool from siblings such as rename_campaign or remove_application, leaving the agent to infer scope from the tool name alone.

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 offers no guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. It simply restates the operation, leaving the agent with no routing 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation but says nothing about whether the folder is moved, whether related applications/interviews reference the old name, whether the operation is reversible, or what errors occur on name collision.

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 four-word phrase with zero padding and the verb front-loaded. It is efficient, though arguably under-specified rather than genuinely concise.

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 mutation tool with no annotations and no output schema, the description leaves key gaps: collision/error behavior, permission requirements, and whether renaming affects other artifacts that reference the campaign name.

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

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

Schema coverage is 100% and both 'from' and 'to' are documented as current/new campaign name, so the baseline of 3 applies. The description adds only the word 'folder', a marginal nuance 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?

Names a specific verb and resource ('Rename a campaign folder'), which is enough to distinguish it from most siblings like read_campaign_config or remove_campaign. It does not explicitly distinguish itself from rename_application, but the resource noun does most of that work.

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 or of what happens when the new name collides with an existing campaign. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full behavioral burden. It implies mutation via 'repair' and 'rebuild', but does not state whether the operation is destructive, reversible, requires elevated permissions, or how it affects existing data.

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 the action and affected artifacts front-loaded. It is telegraphic but contains no wasted words, though it could be slightly clearer about 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?

For a repair/mutation tool with no annotations and no output schema, the description is insufficient. It omits when to run the tool, safety and impact details, and what the result would be, leaving the agent with too little context beyond the schema.

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

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

Schema description coverage is 100%, so both `slug` and `campaign` are already documented in the input schema. The description adds no additional parameter-level detail, making the baseline score of 3 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 action (repair) and names the artifacts affected: application toolhash sidecars, index, and counters. This is clearer than a tautology, but it does not differentiate itself from the sibling tool `doctor`, which may also diagnose or repair application 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?

Provides no guidance on when to use this tool versus alternatives such as `doctor`, `prepare`, or `init`. There are no prerequisites, no when-not-to-use exclusions, and no indication of what condition should trigger a repair.

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 disclosure burden. It does usefully disclose the return contents (metadata and job description files), which is genuine behavioral context, but says nothing about errors, missing-file behavior, or output format.

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 short sentence, front-loaded with the action and resource, followed by the returned artifacts. No filler or 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 two-parameter read tool with full schema coverage and no output schema, the description names what is returned (meta.md and jd.md), which is the key missing information an agent would otherwise lack. Minor gaps around error/missing-application behavior 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?

Schema description coverage is 100%, so both 'campaign' and 'slug' are already documented in the schema. The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 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 (show) and resource (a single application), and even names the two artifacts returned (meta.md metadata, jd.md job description). It implicitly distinguishes itself from the list_applications sibling via 'single', though it does not name the alternative 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 or when-not-to-use guidance. The phrase 'a single application' hints at the contrast with list_applications, but no alternative is named and no prerequisite is stated, leaving usage 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?

No annotations are provided, so the description carries the full behavioral burden. It implies read-write behavior via 'create' and 'update' but says nothing about permissions, merge/overwrite semantics, side effects, or what happens to existing fields.

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 zero waste. It immediately conveys the resource and the two modes without filler.

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

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

For an 11-parameter mutating tool with no annotations and no output schema, the description is too thin. It does not explain update semantics, return behavior, or how the various optional fields interact with the two modes.

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 schema already documents all 11 parameters. The description only reinforces the create-vs-update mode split, which the schema parameter descriptions already convey, so it adds little beyond the structured data.

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 a specific resource (job application) and clarifies the two operating modes: create from URL and update by slug. This is more precise than the bare tool name, though it does not explicitly distinguish itself from siblings such as show_application or add_interview.

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 usage by mapping modes to parameters ('create from URL or update by slug'), which gives an agent a reasonable signal. However, it names no alternatives and gives no explicit when-not-to-use or prerequisite 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?

No annotations are provided, so the description carries the full behavioral burden for a mutation tool, and it delivers almost nothing: it doesn't state whether the patch is merged or replaces values, whether omitted keys are preserved, what permissions are required, whether the change is reversible, or what a bad key does. The only merge semantics ('Partial config patch to merge') come from the schema, not the description.

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; it is efficiently structured. It is arguably too sparse, but sparseness is captured under contextual completeness rather than 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 no-annotation mutation tool with a free-form nested patch object and no output schema, the definition omits critical context: what global settings exist, how the merge behaves, and what happens on invalid keys. An agent has essentially no basis for constructing a correct patch.

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

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

Schema description coverage is 100%, and the patch parameter is documented in the schema as a partial config patch to merge, so the baseline is 3. The description adds no syntax, key names, or value-shape detail beyond the schema, which matters given the nested object with unrestricted additionalProperties.

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 ('Update') and resource ('global configuration settings'), with 'global' implicitly distinguishing it from the sibling read_config and read_campaign_config. It does not name a sibling explicitly, so it stops short of a 5.

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

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

There is no guidance on when to use this versus read_config or read_campaign_config, no prerequisites, and no note on when a config change is appropriate. Usage is only inferable from the verb.

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. 'Overwrite' usefully discloses that the file is fully replaced rather than appended, which is meaningful for a mutation tool. However it omits permissions, reversibility, and behavior when the campaign does not exist.

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 names the action, target, and payload with zero filler.

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

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

For a two-parameter mutation with no annotations and no output schema, the description covers what changes but not error cases or authorization. Adequate but leaves gaps an agent might need.

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

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

Schema coverage is 100%, so both parameters are already documented as campaign name and new markdown content. The description adds only that the content replaces the existing profile, matching the baseline 3 when the schema does the heavy lifting.

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 (overwrite) and resource (campaign profile.md) with the content type (markdown), which separates it from siblings like read_profile and update_config. It doesn't explicitly name an alternative, but the resource 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?

No guidance on when to use this over siblings such as update_config or append_retro, and no prerequisites or exclusions. The overwrite framing implies a full-replace intent, but the agent must infer that.

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