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 blocking nature (up to maxWaitSec), the result states (answered with decision/text/choice shape, timeout, no-baseline), the no-email-resend semantics on retry, and a server-side rejection of secrets/PII. It even flags the client timeout prerequisite, which is exactly the operational context an agent needs before calling.

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?

Despite the tool's complexity, the text is front-loaded with the purpose and then the flow, statuses, and constraints in tightly packed sentences. It is dense but each clause carries information (workflow, statuses, retry, safety, timeout), with little wasted prose.

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 9-parameter blocking decision workflow with no output schema, the description covers the flow, the three result statuses, retry behavior, and safety constraints, which is nearly everything an agent needs. It lists 'no-baseline' as a status without explaining what it means, a small residual gap.

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

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

Schema coverage is 100%, so the schema already documents each parameter (baseline 3). The description adds cross-parameter behavior the schema cannot express: giving only 'issue' without 'question' triggers a re-wait, and 'issue' alone is the timeout re-call form. This meaningfully exceeds the schema's per-field documentation.

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

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

The description states a specific verb+resource ('대표에게 결정 하나 묻고 답 받기') and lays out the full flow (create issue/comment → email → wait → parse reply → update baseline), so an agent understands exactly what it does. It does not explicitly name sibling tools like wyea_create_issue or wyea_wait to route against them, 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?

'결정이 필요할 때' gives a clear triggering condition, and the description explains the timeout re-call path ('wyea_ask({issue}) 만 그대로 다시 호출, 메일 재발송 없음') and the question-less re-wait case. It never explicitly contrasts itself with the sibling issue/comment/wait tools, so alternatives remain 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?

Beyond the readOnlyHint annotation, the description discloses genuinely useful behavioral traits: the operation is non-blocking, it is single-shot ('한 번'), it compares against a 'seen' baseline, and it returns baseline:false when no baseline exists. It does not state whether the call itself advances/consumes the baseline, which is a notable gap for a stateful check.

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

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

Two compact sentences with the non-blocking constraint front-loaded, and the fallback return case stated second. No filler, though the sentence density around the 'seen' baseline could be slightly clearer.

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 carries the return-contract burden, and it only partially does so (it names baseline:false but not the normal result shape). It also omits whether the baseline is updated on a successful check. Adequate but with clear gaps for a stateful polling tool.

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

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

Schema description coverage is 100% for the single 'issue' parameter, so the schema already carries the parameter meaning. The description introduces the '기준(seen)' baseline concept, but 'seen' is not an input parameter, so it does not deepen parameter semantics; 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 (확인/check) and resource (새 댓글·수정된 댓글, new/edited comments) and adds a key scope qualifier: it does not wait (기다리지 않고). This implicitly distinguishes it from the blocking sibling wyea_wait, but no sibling is named explicitly, so differentiation is inferred rather than stated.

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 phrase '기다리지 않고' (without waiting) implies the use case is a non-blocking poll as opposed to a waiting tool, and it covers the no-baseline case. However it never explicitly states when to choose this over wyea_wait or wyea_snapshot, leaving the routing guidance 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 burden. It conveys the consequential nature of the action and the authorization precondition, but says nothing about required permissions, whether the close is reversible/reopenable, or whether the comment is posted before the state change.

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: the action and the optional comment come first, then the usage constraint. No filler 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?

There is no output schema and no annotations, so the description must stand alone. The usage precondition is covered well, but side effects, permission needs, and failure behavior for this state-changing operation are left unaddressed.

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% for both parameters, so the schema already documents 'issue' (GitHub issue number) and 'comment' (optional closing comment). The description only restates the optionality of the comment and adds no format or range 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 and resource ('이슈를 닫습니다' - close the issue) plus the optional closing comment. It is distinguishable from read-oriented siblings like wyea_status or wyea_check, though it never names any sibling such as wyea_comment, which also writes to an issue.

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, prescriptive precondition: use only when the representative (대표) directed the close, or once the request is fully handled. That is a clear when-to-use rule rather than an implied one.

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 the server rejects personal data/secrets, and that posted comments are recorded in the 'own' status file so they will not resurface as new comments via wyea_wait/wyea_check. It omits auth/permission requirements and rate limits, leaving a small 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?

Four short sentences, front-loaded with the core action (post a report comment), followed by content rules and behavioral caveats. Efficient, though the middle content rules could be trimmed.

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 comment tool with no output schema and no annotations, the description covers side effects, validation behavior, and interaction with sibling tools, which is enough for an agent to call it correctly. Minor omissions are permission requirements and confirmation of success behavior.

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 two parameters (issue number, markdown body) are already documented in the schema. The description's content guidance (commit hash, files, deployment result) loosely informs what the body should contain but adds no format or constraint semantics 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 a specific verb and resource ('작업 결과·진행 보고를 이슈 댓글로 남깁니다' – leave work/progress reports as an issue comment), which is far more specific than the title alone. It does not explicitly name sibling tools as alternatives (e.g. wyea_create_issue vs wyea_comment), but the resource-action pair 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?

It gives clear positive usage context (post work results/progress) and content rules (keep it short with commit hash, changed files, deployment verification). It does not say when NOT to use this tool or point to a sibling alternative, so it stops short of the top score.

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 does well: it discloses that the issue lands in a private repo, that a representative is assigned, that an Apps Script mail is fired exactly once and its result returned, and it warns that mail.ok is not proof of inbox delivery. It omits permission/auth requirements and failure behavior, which keeps it 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?

Every sentence earns its place: purpose and assignment first, then body-content rules, then mail side effect, then the no-notify instruction, then the title prefix rule, then the mail.ok caveat. No filler and the most important constraint 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 mutation tool with no annotations and no output schema, the description is unusually complete: it explains the created artifact, the automatic mail step, the returned mail result, and the mail.ok semantics. Only auth/permission preconditions and error handling are missing, which is a minor gap given the rest.

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 meaning beyond the schema: the body must avoid PII and secrets, must state situation/decision/options/status, and the title must begin with the AUTH:LLM(Modelname-thinkinglevel) prefix reflecting real model and reasoning level. These are usage constraints the schema only partially encodes.

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 (create an intervention-request issue in a private repo) plus the side effect of assigning the representative as assignee. It also explicitly distinguishes itself from the sibling wyea_notify by telling the agent not to chain that call.

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 clear conditional guidance: use this tool and do NOT additionally call wyea_notify, since the mail is already triggered once here. It also prescribes what belongs in the body. It does not, however, contrast itself with other siblings such as wyea_ask or wyea_check, so the when-to-use picture is only partly complete.

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 that the server prepends '[WYEA 작업] ' to the subject, appends the issue URL and a 'reply as comment' sentence to the body, preserves the existing seen baseline (creating it if absent), and prescribes error handling (do not retry when mail.ok is false). It does not state authentication requirements or rate limits, so it falls 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 compact sentences with no filler; the optionality and the core action are front-loaded, followed by the server-side transformations and the failure-handling rule. Slightly dense but every sentence earns its place.

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 mutation tool with no annotations and no output schema, the description covers the side effects (comment, seen baseline, email) and the one failure signal it references (mail.ok). It is nearly complete, though it could clarify what the tool returns on success beyond the mail.ok flag.

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 four parameters in detail (length limits, exclusiveMinimum, server-appended text). The description adds only marginal framing (comment optionality, seen baseline), consistent with 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?

The description names a concrete set of actions (leave an optional comment, preserve/create the 'seen' baseline, send a MailApp notification email) which is far more specific than the name alone. It stops short of differentiating itself from close siblings like wyea_comment or wyea_ask, which the agent must disambiguate unaided.

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 '(선택)' marks the comment as optional and the schema note says to use the comment field when the request should also be logged on the issue, but there is no tool-level when-to-use guidance or comparison to the sibling tools (wyea_comment, wyea_ask, wyea_status). The agent gets no explicit condition selecting this tool over the alternatives.

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 mutation (writing the seen baseline) and the exact state-file path/format (stateDir/issue-<number>.json, matching Codex Wyea-Workflow.ps1). It does not cover permissions, behavior if the issue is missing, or the return value.

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 compact sentences, front-loading the core action before usage and file details. Each sentence roughly earns its place, though the parenthetical about the file format is the least essential.

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 tool the description covers purpose, usage, and the side effect of writing a state file. With no annotations and no output schema, it should say more about return values and failure/permission behavior, so it is adequate but not 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%, so the single 'issue' parameter is already documented, making 3 the baseline. The description adds only a small corroboration by showing the issue number maps into the state-file filename ('issue-<번호>').

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+resource: saving the current full set of comments as the '(seen)' baseline. It clearly conveys what the tool does, but it never names or contrasts itself with siblings like wyea_check or wyea_wait, so an 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?

It gives two usage situations ('after reading and reflecting on new comments' or 'when waiting without mail'), which is implied-but-real guidance. However, it does not explicitly name alternatives or state when NOT to use this versus wyea_check/wyea_wait, leaving the routing decision partly 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?

readOnlyHint=true already signals a safe read; the description adds a meaningful behavioral guarantee on top of it ('비밀값은 절대 반환하지 않습니다') that an agent needs in order to trust handling the output. It does not describe latency, retries, or failure modes beyond the ready flag, keeping it off 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 tight sentences, front-loaded with what is checked, then the invocation timing, then the handling rule. Every sentence carries information, though the opening list is dense and could be trimmed slightly.

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 and no params, the description does helpful work by surfacing the 'ready'/'problems' fields an agent will encounter and stating the safety property of the response. It is close to complete, missing only return-shape detail that a schema would otherwise supply.

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 of 4 applies; there is no parameter surface for the description to clarify or obscure.

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 (사전 점검 / check) and enumerates exactly what is inspected: settings, secret files, gh auth, repo privacy, webapp response, and the status file. It positions itself as the pre-flight step, but it never explicitly distinguishes itself from the similarly named sibling wyea_check, so it falls short of a 5.

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

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

It gives an explicit trigger ('작업 시작 전에 먼저 호출하세요') and a concrete follow-up rule for the failure case ('ready:false 면 problems 를 대표에게 보고하고 멈춥니다'). That is strong when-to-use guidance, though no sibling alternative or when-not condition is named.

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?

Annotation only declares readOnlyHint=true, and the description adds substantial behavior beyond that: own comments are excluded, the baseline is deliberately NOT advanced, timeout returns timeout:true, and the client timeout prerequisite is spelled out. That is exactly the kind of operational context an agent cannot get from the annotation.

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 dense paragraph that front-loads the core behavior (polls until new comments) then layers timeout, baseline, and client-timeout caveats. Every clause carries information, though it is on the long side and would benefit from separation into distinct sentences.

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 carry return semantics, and it does: it names the changed array fields (author, body, URL, decision) and the timeout:true shape. Combined with the polling prerequisites, nothing an agent needs to call this 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 coverage is 100% and already documents the three params and their defaults, so baseline is 3. The description adds behavioral meaning: intervalSec governs the polling cadence and maxWaitSec governs when the timeout return fires, which the schema alone does not convey.

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: it polls and waits for new or modified comments after the 'seen' baseline. It also carves out scope that separates it from siblings (excludes the tool's own comments, and explicitly names wyea_snapshot as the baseline updater). An agent can distinguish this from wyea_check/wyea_status without opening schemas.

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 clear operating guidance: call again on timeout:true, update the baseline via wyea_snapshot after processing, and ensure the client MCP timeout exceeds maxWaitSec. It does not explicitly say when NOT to use this versus plain wyea_check, but the polling/wait semantics are unambiguous.

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