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

With no annotations, the description fully carries the burden and delivers: it discloses idempotency behavior (identical re-approval returns the existing record; different values are refused), a matching precondition (name and number must match the brief), and the downstream enforcement role. This is materially more than the schema conveys.

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?

Four tight sentences, front-loaded with the action and gate semantics, ending with the next step. No redundancy, though the caveat about identical vs. different values could be slightly compressed.

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

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

For a 7-param mutation tool with no annotations and no output schema, the description covers action, precondition, idempotency, refusal behavior, and the follow-up tool. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so every one of the 7 parameters is already documented in the schema. The description reinforces the matching requirement for name/number but adds no syntax or format detail beyond it, so the baseline 3 is appropriate.

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

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

States a specific verb+resource ('A human records that InterLogue may contact exactly this person') and immediately frames it as the 'no-cold-outreach gate', which distinguishes it from siblings like discover_contacts or place_call. An agent can identify the tool without opening the schema.

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?

Explicitly states the dependency: 'run_interview refuses to proceed without a matching record' and closes with 'Next step: run_interview.' It gives both when-to-use (before interviewing) and the constraint that selects it (the gate).

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 full burden and does well: it discloses the side effect (saves the brief), the return shape (brief_id plus question plan), and the safety-relevant fact that no contact occurs. It omits auth/permission requirements and rate limits, so not a 5.

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 with 'Start here.' Every sentence earns its place: input categories, the angle's semantic constraint, the save/return behavior, the no-contact guarantee, and the next step. 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?

For a 10-parameter, no-output-schema, no-annotation tool, the description compensates well by describing the return value (brief_id, question plan) and the workflow position. It leaves the remaining lifecycle (what approve_contact then triggers) implicit, but that is the sibling's job.

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

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

Schema description coverage is 100%, so the baseline is 3. The description groups the inputs conceptually (subject, client, product, topic, angle) but adds little beyond what the schema already documents, including the angle semantics which the schema repeats verbatim.

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 (brief) and resource (InterLogue), enumerates the inputs it captures (subject, client, product, topic, angle), and marks itself as the entry point with 'Start here.' An agent can distinguish it from siblings like approve_contact or draft_piece without opening any schema.

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?

Explicitly tells the agent when to use it ('Start here'), what does not happen ('Nobody is contacted at this step'), and routes to the next tool ('Next step: approve_contact'). This is when/when-not/alternatives in miniature.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the validation rules (section order, verbatim timestamped quotes, no numbers outside quotes, no repeated frames), that a clean pass persists a draft for human review and returns a piece_id, and that a fail persists nothing and returns failing spans with the closest matching turn.

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-loads the core validation statement, then the two modes, then the pass/fail outcomes. Every sentence conveys a distinct behavioral fact with 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?

There is no output schema, so the description must explain return behavior; it does so for both paths (piece_id on pass, failing spans plus nearest turn on fail). Nothing an agent needs to call or interpret this tool is missing.

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

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

Schema coverage is 100%, and the parameter descriptions already explain the two invocation modes and the required markdown format. The description restates the piece_id vs. brief_id+markdown split without adding syntax or format detail beyond the schema, 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 and resource: validates that quoted spans resolve to a subject turn at the cited timestamp. This is clearly distinct from sibling generators like draft_piece and generate_piece, and the title reinforces the fact-check framing.

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 explicitly documents two invocation modes: 'With piece_id it re-checks a stored piece' and 'With brief_id and markdown it checks a host-written piece.' That gives clear context for selecting arguments, though it never names sibling alternatives or says when this check should be skipped.

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 present, the description carries the full burden and does disclose the critical behavior: discovery is unimplemented and will return nothing useful. It is honest about the no-op nature, though it does not say what the call returns or whether the required query matters.

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

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

Three short sentences, front-loaded with 'Cut-list stub' so the agent grasps the situation immediately. No filler; every clause conveys necessary information.

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

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

For a single-parameter stub with no output schema or annotations, the description supplies the one fact that matters: it will not work. The remaining gap is a concrete pointer to the alternative workflow, which would make it fully 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 coverage is 100% and the schema itself states the query is 'Ignored. Kept so the tool has a stable shape.' The description adds nothing about the parameter beyond what the schema already documents, so 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?

The description explicitly states the tool's real purpose: it is a 'cut-list stub' that 'will not find, suggest or look up anyone.' This is a specific and honest statement of scope that distinguishes it from action-oriented siblings like place_call, approve_contact, and run_interview, though the verb+resource framing is inverted (it says what it does NOT do).

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?

'Explains what to do instead' implies the tool is used as a redirect mechanism, giving implied usage. However, no alternative tool or action is named, so the agent is left to infer the actual path forward on its own.

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

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

With no annotations, the description carries the full burden and does well: it discloses that no audio is fetched or stored, that the timestamped transcript is the record, and that input is ignored. It does not discuss return format or edge cases, but the core stub behavior is transparent.

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

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

Three short sentences, front-loaded with the essential stub status. Every sentence adds useful information without waste.

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

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

For a stub tool with no annotations and no output schema, the description is nearly sufficient: it explains the no-op behavior and that the transcript is the record. It could more explicitly describe the shape of the returned answer, but the agent has enough to call it correctly.

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

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

Schema description coverage is 100% and already says transcript_id is ignored. The description adds that any transcript_id gets the same answer, which is marginally useful, but otherwise the schema does the heavy lifting. 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?

The description clearly states this is a cut-list stub, not a real download, and explains that no audio is fetched or stored. That distinguishes it from a functional download, though it does not explicitly contrast it with the sibling fetch_transcript tool.

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

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

The description gives no when-to-use guidance or alternatives. It only notes that any transcript_id returns the same answer, which is behavioral context rather than routing guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses the publication gate ('nothing is published until the check passes') and the hard constraint that every quoted span be verbatim from a subject turn and carry its (MM:SS). It stops short of stating access/permission requirements or whether the packet is cached/regenerated.

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?

Four sentences, front-loaded with what is returned, then the authoring rules. Dense but each sentence earns its place; the return-content list is long but necessary given there is no output schema.

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?

No output schema exists, so describing the returned packet is essential, and the description does so thoroughly while also covering the citation format and the check_citations gate. An agent has everything needed to invoke it and act on the result.

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 there is only one parameter, so the schema already defines brief_id's meaning and the precondition that run_interview stored a transcript. The description adds no further semantics about brief_id, 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 states a specific retrieval action and enumerates the exact payload (brief/angle, question plan, writing contract, ranked verbatim quote candidates with timestamps, full timestamped transcript). It also implicitly distinguishes itself from siblings like generate_piece and fetch_transcript by clarifying that the host writes the story, not the tool.

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

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

It gives a clear workflow: write the story first, then pull quotes in markdown, then submit to check_citations, with the rule that nothing is published until the check passes. It names a downstream sibling and its ordering but never states when NOT to use this tool (e.g., versus fetch_transcript) or any prerequisites beyond the transcript existing.

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

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

With no annotations, the description carries the full burden and does so: it discloses the blocking wait (up to ~3 minutes per call), the retry/idempotency pattern, the mutation (transcript stored against the brief), and a consent-validation side effect (AI disclosure, permission to record, subject's yes). These are exactly the behaviors an agent needs to plan around, none of which appear 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?

Front-loaded with the step position and the core action, then the operational loop, then the handoff. Nearly every sentence earns its place, though the normalize/consent-check detail is slightly more than needed to select and invoke the tool.

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

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

No output schema exists, so the description must explain return values, and it does: the two terminal answers (STILL IN PROGRESS vs TRANSCRIPT STORED) are named verbatim. Combined with the wait semantics and next-step routing, an agent has everything required to call it correctly and repeatedly.

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 schema itself richly documents brief_id and wait_secs, so the baseline is 3. The description adds real meaning on top: 'up to about three minutes per call' and 'a ten-minute interview needs about four calls' directly explain the wait_secs default of 170 and its retry economics, which is more than the schema's terse note provides.

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 (fetch transcript) plus the full pipeline: waits for the call to end, pulls from ElevenLabs, normalizes to timestamped turns, runs a consent check, stores against the brief. It also positions itself in the workflow ('step 2 of the phone path') and names the predecessor (place_call, via brief_id) and successor (draft_piece), so it is unmistakable against siblings.

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?

Explicit when-to-call and when-to-call-again: if the answer is STILL IN PROGRESS, call it again as many times as needed until TRANSCRIPT STORED, with a concrete expectation ('a ten-minute interview needs about four calls'). It also hands off the next step ('Then: draft_piece'), so the agent knows both the loop condition and the exit path.

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 load and delivers: deterministic assembly, verbatim quote spans with transcript timestamps, save-only-if-citation-check-passes, transcript never edited to fit a piece, and idempotent regeneration. These are exactly the behavioral traits an agent needs before invoking it.

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-loads the crucial routing word FALLBACK in caps, then layers usage, mechanics, and next step in four tight sentences. Slightly dense but every sentence carries distinct information; 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?

Covers purpose, routing, output ordering, citation gating, and follow-up tool despite having no annotations or output schema. An agent has everything needed to decide whether and how to call 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?

Only one parameter (brief_id) and schema description coverage is 100%, so the schema already documents it. The description adds only the implication that the brief's transcript is what gets written up; it adds no syntax or selection nuance beyond the schema. 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?

Explicitly names itself as the FALLBACK writer for deterministic assembly of the case study from the saved transcript, and states the output order (story, quotes, per-question answers). This makes it clearly distinguishable from the sibling draft_piece, which is the host-written path.

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

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

Gives an explicit when-to-use condition (only when no host is writing, e.g. `npm run spine`) and a when-not/preferred-alternative (inside Claude, use draft_piece then check_citations). It even names the next step, check_citations.

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 delivers: it is a real outbound call, it is refused without approval, the agent self-identifies as AI and seeks recording consent, it returns immediately rather than blocking, and it lists the required environment variables.

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?

Dense but efficient: each sentence adds distinct information (purpose, gate, call semantics, return, env requirements) with 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?

For a side-effecting tool with no output schema and no annotations, the description covers safety gating, return value, follow-up tool, and runtime prerequisites — everything an agent needs before invoking 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 coverage is 100%, so both parameters are already fully documented, including confirm_dial's const:true and the approval linkage on brief_id. The description adds no syntax or format detail 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?

States a specific verb and resource ('places one real outbound call to the brief's subject') plus the delivery mechanism (ElevenLabs over Twilio), and its 'step 1 of 2' framing lets an agent separate it from fetch_transcript and run_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?

Gives a clear precondition for use (human approval on file for the exact person and number) and routes the agent onward to fetch_transcript to await the result. It does not, however, contrast this phone path against any purely text path or explain when to prefer the 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses that only one genre exists, that the genre argument is meaningless, and that output is identical for any input. It omits nothing critical for a no-op stub, though it doesn't say whether the call succeeds or errors.

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 short sentences, front-loaded with the key fact ('Cut-list stub') so the agent learns the tool is non-functional immediately. No filler, though 'cut-list' is internal jargon that carries little meaning to an outside caller.

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 stub with one ignored parameter, no output schema and no annotations, the description covers what an agent needs: it is a stub, input is irrelevant, and the real question source is brief. Return-value detail is unnecessary since output is constant.

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 itself already states the 'genre' param is ignored and exists only for shape stability. The description's 'any genre passed here gets the same answer' reinforces that but adds no new semantic 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?

The description states plainly that this is a cut-list stub, identifies the single supported genre (customer case study), and says where the real questions come from (the brief tool). An agent knows this tool returns a fixed answer rather than genre-specific templates, though the name 'question_templates' implies a generality the description correctly denies.

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 points at the 'brief tool's angle-driven plan' as the real source of questions, which nudges the agent toward brief, but it never explicitly says 'use brief instead of this tool.' Usage is implied rather than prescribed, and there is no statement of when this tool should ever be called (if 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 burden and does so: it discloses the approval gate and its refusal behavior, the AI-disclosure and recording-permission checks performed at the top of the call, that the transcript is saved, that transcripts are append-only, and that no phone call is placed. These are exactly the mutation/authorization semantics an agent needs before invoking.

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 with the core action, then the refusal gate, then side effects, then the next step. Every sentence adds a distinct fact; there is no filler or repetition.

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

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

For a tool with no annotations and no output schema, the description covers preconditions, side effects, persistence semantics, and the follow-up tool. It stops short of describing what the call returns (e.g. confirmation shape or transcript handle), which is the only remaining 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%, and the schema already documents fixture/turns mutual exclusivity and that brief_id must have a matching approve_contact record. The description restates the fixture-or-turns choice and the approval gate without adding new syntax or format 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+resource ("Runs the interview step of the spine on text") and immediately narrows the input modes to a named fixture transcript or inline turns. It also distinguishes itself from place_call by declaring "No phone call is placed in this build," so an agent can tell it apart from the dialing sibling without opening a schema.

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

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

Gives a hard precondition (refuses unless a human approval for this brief's exact person and number is on file) and names the next step (generate_piece), which is strong routing guidance. It does not explicitly say when to prefer this over place_call or fetch_transcript, so it falls just short of full when/when-not/alternatives coverage.

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 imply a read-only inspection operation by saying it 'reports which ... exist'. However, it never explicitly states it is non-mutating, nor does it describe auth requirements, rate limits, or what the response payload looks like beyond 'names the next 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 sentences, both earning their place: the first states the behavior, the second supplies the pipeline context that makes the artifact list interpretable. The core behavior is front-loaded 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 one-parameter read tool with no output schema and no annotations, the description supplies the key missing context: the pipeline spine and the promise that the next tool is named. That largely compensates for the absence of a return schema, though a hint about the shape of the status report itself is still 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?

There is a single parameter, brief_id, and schema description coverage is 100%, so the schema already documents it fully. The description adds no format, source, or constraint information beyond what the schema provides, which makes 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 and resource: it reports which artifacts (brief, human approval, transcript, generated pieces) exist for a given brief_id. It also enumerates the pipeline spine, which implicitly positions it against the sibling workflow tools. It stops short of naming a specific sibling it is not, 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?

The spine ordering ('brief -> approve_contact -> run_interview -> generate_piece -> check_citations') gives clear context for when an agent should consult this tool: to determine where in the pipeline a brief currently sits. It also states the tool names the next tool to call, which is actionable guidance. No explicit when-not or exclusion conditions are given.

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