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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds that the bubble is anchored either to a component or to a board position, which is useful, but it says nothing about persistence, whether annotations are additive, or who sees them during the interview.

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, front-loaded with the action and anchoring modes, with the use-case hint trailing. No filler, though the quoted probe example is more flavor than 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 4-parameter, non-destructive create tool with no output schema, the description covers the core anchoring model an agent needs. Remaining gaps (return value, whether target is required alongside or instead of x/y) are minor but real.

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

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

Schema coverage is only 25% (only 'target' is documented), so the description must compensate. It does clarify the key semantic point that a comment points either at a component (by id or label) or at a position, implying target vs. x/y usage, but it leaves x/y coordinate semantics and the 1-400 char text constraint unexplained.

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 ('Pin an interviewer comment bubble on the board') with the anchoring modes spelled out. It implicitly distinguishes itself from highlight/draw_on_board by being a comment bubble, but never names those siblings to make the distinction 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?

The clause 'Great for "what if this fails?" style probes' gives a use-case flavor, but there is no explicit guidance on when to pin a comment versus using highlight or draw_on_board, and no stated preconditions.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful scope information — only *your* pinned comments are affected — but says nothing about irreversibility, confirmation, or what happens to ids that don't 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?

One short sentence with the operation and its two modes front-loaded; there is no filler and nothing to trim.

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 destructive tool with no output schema, the description plus annotations cover the basics. It still omits the source/format of ids and any warning about the bulk-delete case, which are the two things an agent is most likely to get wrong here.

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

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

Schema coverage is 0% and the single `ids` parameter has no schema description, so the description must compensate. It does convey the key semantic (omitting ids removes all comments, otherwise only the listed ones), but never explains the expected id format or where ids can be obtained (e.g., from a board or annotate response).

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 ("Remove") and a specific resource ("your pinned comments"), and the parenthetical confirms scope. It doesn't differentiate itself from the sibling `annotate`, and it silently switches terminology across name (annotations), title (interviewer comments) and description (pinned comments), which leaves minor ambiguity about whether these are the same objects.

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 only explains the two invocation modes (all vs. specific ids); it never says when to use this tool versus alternatives such as `annotate`, and gives no prerequisites or caution about clearing everything. Any routing decision is left to inference.

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

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

Annotations already declare this is a non-read-only, non-destructive, closed-world mutation, so the description does not need to restate safety. It usefully adds that content is drawn in a sketchy style and attributed to the interviewer, and that layout is automatic, but it does not describe mutation side effects, validation, or return behavior.

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 front-loaded with the core action and usage warning, then moves into necessary component-kind enumeration and layout/reference details. The long kind list earns its place because the schema has no enums, though the paragraph is dense.

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 four-array mutation tool with no output schema, the description leaves important gaps. It does not explain notes and zones structures in enough detail, does not clarify return behavior or validation, and does not distinguish this tool from annotate/highlight.

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

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

Schema description coverage is 0%, so the description must carry meaning for four nested array parameters. It does a good job listing component kinds and explaining that connections reference components by ref/label/id, and that positions are optional, but it barely explains notes fields, zone containment, or connection options like dashed and bidirectional.

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

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

The description clearly states the action and resource: adding components, connections, sticky notes, and zones to the board. It distinguishes the output style as sketchy and interviewer-authored, though it does not explicitly differentiate this tool from siblings like annotate or highlight.

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 one clear usage rule: use sparingly because the candidate should drive. However, it does not explain when to use draw_on_board versus annotate, highlight, or clear_annotations, nor does it provide explicit when-not 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?

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows this mutates local state non-destructively. The description adds that it closes the session and renders a feedback card, which is useful context, but it does not say whether closing is reversible, what happens to the session transcript, or what validation failures look like.

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

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

Two short sentences, front-loaded with the core action. The second sentence is largely redundant with the schema's min/max and could be cut, but there is no padding or bloat beyond that.

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

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

This is a nested-object, 5-parameter mutating tool with no output schema, so it needs more than two sentences. It conveys the user-visible outcome (a feedback card appears) but says nothing about the narrative fields the caller must supply (strengths, improvements, summary format) beyond the schema's own hints.

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?

Coverage is 60%, and the only parameter-related sentence, 'Scores are 1-5,' merely restates the schema's minimum/maximum constraints. The description adds nothing about the required summary, strengths, or improvements arrays (both capped at 6 items with no schema descriptions), leaving real gaps for the caller.

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: 'Close the session and show a feedback card on the board.' An agent can distinguish this terminal action from start_interview or say without opening the schema. It does not explicitly name a sibling or exclusions, so it stops short of 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?

Usage is only implied – 'Close the session' suggests it is the final step of an interview flow, but there is no explicit when/when-not guidance, no mention of prerequisites (e.g., an active interview must exist), and no reference to alternatives like set_phase.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the returned field set (including dashed=async connection semantics) and the stateful delta behavior ('changed since you last looked'), neither of which appears in the annotations or schema. It does not mention verbosity trade-offs of include_json, which the schema covers separately.

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

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

One sentence, front-loaded with the deliverable and then a tight parenthetical enumeration of exactly what the structure contains. No filler, no repetition of the title.

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 carry the return shape — and it does, enumerating the top-level sections and key fields. The remaining gap is that 'what changed since you last looked' is undefined (delta against which baseline, and what happens on the first call), which matters for a stateful read.

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 parameter include_json is documented in the schema as 'Also return raw element JSON (verbose)'. The description adds nothing about it, so this sits at the baseline 3 — the schema does all the work.

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

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

The description names the resource (the board) and specifies the shape of the returned structure — components with type/label/id/position/zone, connections with direction and dashed=async, zones, notes, strokes, plus a delta. That is far more specific than the title 'Read the board'. It stops short of explicitly contrasting with get_board_image, which is the obvious sibling, so it doesn't fully earn 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?

Usage is only implied: 'what changed since you last looked' hints this is the tool to re-poll board state, but there is no explicit when-to-use, no exclusions, and get_board_image is never named as the alternative for a visual read. The agent must infer the routing from the sibling's 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the useful facts that the payload is an image in the candidate's own view. It does not say whether the image is a current snapshot, its size, or whether repeated calls re-render, which are minor remaining gaps.

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

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

Two short sentences: the first defines the artifact, the second defines when to reach for it. Nothing redundant, and the key scoping fact (whole board, candidate's perspective) is front-loaded.

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 zero-argument tool with no output schema, the description adequately conveys the return medium and content. Only freshness/staleness of the snapshot is unaddressed, which is a small but real gap given the tool returns a visual state.

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

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

The tool takes zero parameters, so there is nothing the description needs to disambiguate; baseline applies. No parameter-related claims are made or needed.

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 exactly what is returned: a PNG image of the whole board as the candidate sees it, including handwriting, sketches and layout. This clearly separates it from the text-oriented get_board sibling without opening either 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 two explicit triggers — get_board reports freehand strokes, or visual context is needed — and names the sibling it complements. An agent can decide between the text and image views from the description alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds scope detail (chat and voice, current session, 'Full' implying completeness) but says nothing about return shape, ordering, or truncation behavior.

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, front-loaded, with no redundant wording. Every word carries information about content type, modality, and 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 no-parameter read tool with no output schema, the description is nearly sufficient: it states what is returned and its scope. It could say a bit more about the return structure (e.g., message list vs. flat text), 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?

The tool takes zero parameters, so the baseline is 4. There is no parameter meaning the description could add or omit.

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

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

The description names the resource and its scope precisely: a full chat/voice transcript of the current session. It lacks a verb and does not explicitly differentiate itself from siblings like get_board or say, but the resource is distinct enough that an agent can pick it out.

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 call this versus alternatives such as get_board or the conversation tools. The only implied cue is the word 'current session', which mildly bounds usage but does not state conditions or exclusions.

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

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

Annotations already cover idempotency, non-destructiveness, and that this is not a plain read. The description adds genuine behavioral context: the effect lands on the candidate's board (a side effect on another user's view) and can optionally move their viewport. However, it says nothing about persistence — whether the glow is momentary, tied to 'seconds', or how to remove it — which matters for a tool that mutates a shared surface.

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 core effect and followed by the optional viewport behavior. 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?

No output schema and only three parameters, but the description leaves out the duration semantics of 'seconds' and whether the glow persists after the call, so an agent cannot fully predict the tool's effect on the candidate's board.

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

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

Schema coverage is only 33%: only 'targets' is documented ('Element ids or labels'). The description explains 'focus' implicitly via 'scroll/zoom their view to them', but 'seconds' (1-20) is never mentioned in either the schema or the description, so its meaning — presumably highlight duration — is left entirely to inference.

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 — making components glow on the candidate's board — with a concrete example use case. An agent can tell this is a presentational 'point at' action, distinct from siblings like annotate or draw_on_board, though it never names those alternatives.

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 parenthetical '(e.g. while asking about them)' implies when to use it, but no explicit when-not, no prerequisites, and no comparison to draw_on_board / annotate / open_board. The agent must infer the boundary between highlighting and drawing.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and the description adds the key real-world effect: a browser window is opened on the user's machine (a side effect on the user's environment, consistent with readOnlyHint=false) and a URL is returned. Auth requirements and failure modes are unstated, but the core behavior is disclosed.

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

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

One sentence, front-loaded with the action and ending with the return value. 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 zero-parameter tool with no output schema, the description covers the action, the side effect, and the return value (URL). Missing only marginal detail such as behavior when no board exists or whether the browser must be available, which slightly limits completeness.

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, which is the correct baseline of 4; there is nothing to disambiguate and the description doesn't waste words on inputs.

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?

A specific verb (open) and resource (sketch board) with a clear effect: launch it in the user's browser and return the URL. That implicitly separates it from get_board/get_board_image, which fetch board data rather than opening a UI, though no sibling is named 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?

The description never states when to use this instead of get_board or get_board_image, nor any precondition (e.g., board must exist, user must have a session). The choice among the three board-related siblings is left entirely 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?

Annotations only tell the agent this is a non-read-only, non-destructive, closed-world call. The description adds genuinely useful behavior: the message is both displayed and read aloud, and it must be short and markdown-free. It does not mention the optional `speak` toggle or delivery failure modes, keeping it just short of 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?

Three short sentences: purpose first, then effect, then authoring constraint. Every sentence carries actionable information; nothing to trim.

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 and a simple two-parameter tool, so the description covers most of what is needed. The one gap is the `speak` flag, which silently alters the spoken side effect described as unconditional.

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?

`text` has no schema description and the description only indirectly constrains it ('short and conversational (no markdown)'), which is real guidance. However, the `speak` parameter is never referenced in the description despite shaping the primary side effect, so half the parameters remain under-explained.

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 ('Send a message to the candidate') plus the two observable effects: it lands in the board chat and is spoken aloud. No sibling tool does anything similar, so an agent can route to 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?

Usage is implied by 'candidate' and 'board chat' — this is an in-interview communication tool — but there is no explicit when-to-use or when-not (e.g., don't use it to answer board-level questions, or whether it can be called outside an active interview). Adequate but leaves routing 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?

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in the annotations: the change is candidate-visible on a tracker, i.e. it has a UI side effect. It omits ordering prerequisites and whether advancing a phase affects scoring or the transcript.

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 naming the effect first, then the allowed values. The inline label repetition ('wrap-up (Wrap-up)') is slightly redundant but costs little.

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-required-param mutation on a well-annotated tool with no output schema, the description covers purpose, target state and allowed values. Nothing an agent needs in order 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 0%, so the description must carry the load, and it does partially by expanding enum tokens into human labels ('api' -> 'API & Data', 'high-level' -> 'High-level'). However, the mapping is terse and adds little beyond the enum values themselves, and nothing is said about whether the phase must progress in order or can jump backward.

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 ('the phase tracker the candidate sees'), and enumerates the six phase values, so the effect is unmistakable. It does not explicitly contrast itself with start_interview or end_interview, which are the obvious adjacent lifecycle 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?

Usage is only implied: an agent can infer this is called mid-interview to advance the candidate-visible phase, but the description never says when to call it, whether it must follow start_interview, or what to do instead if the interview has not started.

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?

Adds real side-effect disclosure the annotations cannot convey: the board is opened and the opening message is spoken aloud to the candidate, so the agent knows an audio/observable action occurs. The destructiveHint=true flag is not explained though — the description never says what starting a session destroys or overwrites (e.g. an in-progress session).

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 sentence, front-loaded with the action and then the concrete effects, with zero filler. The parenthetical about audio delivery earns its place by flagging a non-obvious side effect.

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 setup tool with an output-schema-free contract and annotations covering safety, the description covers the composite actions well. It omits what happens if a session is already running and whether the tool returns a session identifier or blocks awaiting the candidate, which are gaps but not crippling ones.

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 83%, so the schema already documents nearly every parameter, including examples for title, problem, and opening_message. The description only loosely maps its phrases to parameters ("problem statement", "timer") and adds no format or default detail 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?

Specific verb + resource ("Start a new interview session on the board") followed by an enumeration of exactly what it creates: problem statement, timer, phase, opened board, and opening message. This clearly separates it from siblings like open_board, set_phase, and say, which each do only one of these steps.

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 framing "Start a new interview session" plus the fact that it rolls board-open + phase/timer setup + opening line into one call implicitly tells the agent to use this instead of chaining those siblings individually. However, it never states when-not to use it (e.g. resuming an existing session) or names an alternative explicitly.

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

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

Annotations already mark it readOnly and closed-world, and the description adds important behavioral context: it blocks, waits for speech or board settling, and returns conversation, board changes, and timing. It does not describe cancellation, failure modes, or rate-limit behavior, so a 4 is appropriate.

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 sentences, front-loaded with the blocking condition and return values, then the loop instruction. Every sentence contributes directly to correct invocation.

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 output schema, the description usefully explains what is returned and how to use the tool in a loop. It is nearly complete for a blocking wait tool, though it could say more about what happens on timeout or errors.

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 timeout_seconds parameter already documents its default and maximum. The description only references the timeout conceptually and does not add parameter-specific meaning 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 specific blocking-wait behavior and enumerates the three conditions it waits on: candidate speech, board change settling, or timeout. It also states what is returned, making it clearly distinct from sibling tools like get_board, get_transcript, and say.

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 explicitly instructs the agent to call this in a loop between replies, which is strong usage context. It does not name alternatives or exclusions, such as when to prefer get_transcript or get_board instead, so it stops short of a 5.

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