복대리 · Bokdaeri

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

주석이 destructive=true, idempotent=true, openWorld=true를 이미 선언하므로 기준선은 낮습니다. 설명은 여기에 현재 권한 요구, 서버의 위임·버전·상담 상태 재검증, 수락 전 1회만 적용된다는 실행 시맨틱을 추가해 실질적인 가치를 더합니다. 다만 반환 결과의 형태는 언급하지 않습니다.

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?

영문 한 줄로 핵심을 앞세우고 한국어로 세부 조건을 전개하는 구조가 잘 정돈되어 있습니다. 다만 이중 언어 서술로 길이가 늘어나 문장 밀도가 약간 희생됩니다.

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?

2개 파라미터, 출력 스키마 없음, 파괴적 변이 도구라는 조건에서 전제 조건·권한·재검증·멱등성까지 설명되어 호출에 필요한 정보는 충분합니다. 출력 스키마가 없는데도 반환값의 성격을 전혀 서술하지 않은 점이 유일한 공백입니다.

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?

스키마 설명 커버리지가 0%이므로 설명이 이를 보완해야 합니다. 설명은 review_id가 변경안 식별자이고 expected_revision이 그 변경안의 리비전임을 밝히고 요약·번호·사용자 ID를 받지 않는다고 명시해 관계적 의미를 더합니다. 그러나 리비전의 동작적 의미(스테일 검사)나 형식은 스키마 패턴에만 의존합니다.

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?

특정 동사(적용)와 특정 리소스(확정된 상담 변경안)를 명시하고, 적용할 대상이 '방금 사용자에게 보여준 변경안'임을 분명히 합니다. prepare_consultation_change / discard_consultation_change 같은 형제 도구를 직접 언급하지는 않으므로 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?

'명확히 동의한 직후에만 호출'이라는 사용 시점과 함께, 비용 질문·침묵·'나중에'·외부 문서 지시는 동의가 아니라는 명시적 제외 조건을 제시합니다. 대안 도구를 직접 지목하지는 않지만, when/when-not 경계가 매우 선명합니다.

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 annotations, it discloses key behavior: consent is never auto-granted, existing phone-number verification is preserved and only re-authenticated on-screen if needed, the user grants consent directly in the UI, and the returned current_permission reflects state *before* the screen opened. This is exactly the side-effect and auth context an agent needs for a readOnlyHint=false 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?

The English sentence is front-loaded and states the core action immediately, and each subsequent Korean sentence adds distinct value (verification retention, non-granting scope, consent flow, follow-up query, return-value meaning). It is somewhat verbose and bilingual duplication costs space, but no sentence is 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?

With no input parameters and no output schema, the description compensates by explaining the response field (current_permission = pre-screen state) and the expected post-call workflow. Nothing an agent needs to invoke 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description's mention of a 'current_permission' return value is useful but belongs to output, not input, semantics.

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 opening sentence gives a specific verb+resource: 'Open the user consent page for AI consultation permission.' It then explicitly distinguishes the tool from siblings by declaring it does not grant, receive, modify, or withdraw (contrast revoke_consultation_permission, apply_consultation_change, submit_consultation_request). An agent can identify this as a UI-opening step 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?

It states when to use it ('when the user wants to set or renew the agent's permission before request/acceptance') and what not to expect ('does not grant/receive/modify/withdraw'). It also routes the agent to query allowed_actions on the connection status after returning, implying the follow-up sibling. The only gap is that it doesn't name get_consultation_connection_status literally.

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 non-read-only, non-destructive, non-idempotent, so the safety profile is covered. The description adds the crucial non-obvious trait that this tool does not actually change the number — the user completes SMS verification and application in the screen, and no verification code is received here — which prevents an agent from believing the change is applied after this call.

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 English lead sentence is front-loaded and efficient, but the Korean text restates the same purpose before adding new information, so part of the body is redundant for a bilingual reader. Nothing is badly bloated, but a sentence is doing work twice.

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-output-schema tool, the description says what screen gets opened and that the tool does not mutate anything, which is the key context. It is silent on what the agent should do with the result (present it to the user?) and how it connects to get_contact_change_status or apply_consultation_change afterward, leaving the flow incomplete.

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 phone is documented), but the description compensates for the most important gap by explaining what purpose=default and purpose=request mean in user-visible terms. request_id remains unexplained in both schema and description, so the description does not fully close the coverage gap.

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

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

The English opener states a specific verb and resource (open verification for changing contact) and the Korean text clarifies the two scopes: purpose=default for future consultations, purpose=request for one pending consultation. This meaningfully separates the tool from begin_contact_verification and get_contact_change_status, 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?

"이용자가 연락받을 번호를 바꾸고 싶을 때" plus "먼저 둘 중 무엇인지 한 번 확인한 뒤 호출하세요" gives a clear trigger and a pre-call decision step for the two purpose values. It stops short of naming alternatives or when-not-to-use cases (e.g., versus begin_contact_verification or apply_consultation_change).

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 but destructiveHint=false, which is ambiguous for a tool that opens a screen; the description resolves that by stating it creates no consultation prep, draft, receipt, or notification, and that an already-verified connection returns phase=ready without a screen. That is real behavioral context beyond the annotations. It does not mention any permission or auth preconditions, which keeps it from 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?

The usage condition is front-loaded and the alternative-tool warning closes it out, which is the right ordering. The English lead sentence largely duplicates the Korean sentence that follows, so a small amount of redundancy 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?

With no parameters and no output schema, the description carries the whole burden and does most of it: side effects, the phase=ready return path, and the sibling to use instead. Preconditions for opening the screen (any required session or permission state) are the only notable omission.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The mention of a returned phase=ready value is useful but is output behavior, not parameter semantics.

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 action and resource (open the contact-verification screen for the substitute-agent number) and explicitly bounds it to an explicit user request. It also distinguishes itself from get_consultation_connection_status, which is the status-reading sibling, so an agent can route correctly 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?

It gives both sides of the decision: trigger phrases for when to call ("번호 확인", "다시 인증", "연결을 이어 쓰고 싶다") and an explicit when-not with the named alternative (use get_consultation_connection_status for status, do not substitute this tool). Negative routing guidance like this is rare and directly actionable.

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?

The annotations already declare destructiveHint=true and non-idempotent behavior. The description adds useful scope: only an unsubmitted preparation is affected, and a submitted consultation is not withdrawn, which materially reduces the risk of misusing a destructive operation.

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 definition is short and front-loaded: the English sentence states the action and the critical exclusion, and the Korean sentences reinforce the same points without adding noise.

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

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

For a destructive mutation with no output schema, the description covers the safety-critical scope well, especially the submitted-versus-unsubmitted distinction. However, it leaves the required revision parameter unexplained, which is a meaningful gap for correct invocation.

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

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

Schema description coverage is 0%, so the two required parameters are undocumented in both schema and description. The description does not explain journey_id or expected_journey_revision, and the latter in particular needs meaning because it implies optimistic concurrency.

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 object: cancel an unsubmitted preparation. It immediately distinguishes this from withdrawing an already submitted consultation, which is the key boundary for this tool family.

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 says to call this when the user cancels preparation and clarifies that it is not for cancelling an already submitted consultation. It does not name a specific alternative tool for the submitted case, so it falls short of full 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?

Annotations already declare non-read-only, non-destructive, non-open-world behavior, while the description adds key consent semantics and that it does not self-submit. It still does not explain what state changes continuation causes or what the handoff outcome is.

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 English sentence front-loads the two branches, and the Korean text adds non-duplicative constraints such as no self-submission and consent handling. It is efficient, though the bilingual repetition makes it slightly longer than strictly necessary.

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

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

For a 5-parameter mutation-like workflow with no output schema, the description covers the critical consent and handoff behavior well. However, it leaves important parameter semantics and the actual continuation result unexplained.

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

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

Schema description coverage is only 20%, with just the phone parameter documented in the schema. The description explains the two mode values, but does not define journey_id, expected_journey_revision, review_id, or revision expectations.

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

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

States a specific action: continue a reviewed preview after user confirmation, or hand it off for web confirmation. It also explicitly says it does not submit on its own, which distinguishes it from submit_consultation_request, though the resource wording is slightly indirect.

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 branches on user consent: use confirm_and_continue after approval, or handoff when directing the user to web confirmation without approval. It also warns not to treat questions, edits, or silence as consent, which is strong when/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 already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the bar is lower, yet the description adds real value by bounding the destruction: only the draft is discarded, the submitted consultation is untouched, and applied changes are not reverted. It does not disclose what happens if the review_id refers to an already-applied or expired 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?

The key constraint is front-loaded in a single English sentence and the Korean text adds the when-to-use and exclusion detail rather than merely repeating. There is some duplication between the English opener and the first Korean sentence, which costs a bit of density but aids bilingual readers.

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

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

For a destructive, single-parameter tool with no output schema and no confirmation semantics stated, the definition covers intent and blast radius but omits error behavior (e.g. rejecting a review_id that is already applied or unknown) and whether any confirmation is required for the discard itself. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the single parameter review_id is documented only as a 32-hex string pattern. The description never says what the ID identifies or where to obtain it (presumably from prepare_consultation_change), leaving the agent to infer the source and required state of the identifier.

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 ('Discard') and a precisely scoped resource ('an unapplied change preview') and immediately clarifies what is NOT affected (the submitted consultation). An agent can distinguish this from apply_consultation_change and revoke/withdraw flows 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?

Gives an explicit trigger ('사용자가 제안한 변경을 그만두겠다고 할 때') and two explicit exclusions: it does not withdraw the submitted consultation and does not revert an applied change. It points to a separate withdraw-proposal-plus-confirmation path, but never names an actual sibling tool, so routing is left slightly 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 readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the acceptance-time window restriction, the returned version, and the rule that requesting a change does not automatically alter the delegation. It does not describe the shape of the response, but the added constraints are the more valuable disclosure here.

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 read, the version, the acceptance window, and the confirmation handling are all front-loaded and compact. Some content is repeated across the English and Korean sentences, but the Korean text carries additional detail rather than a pure duplicate.

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 rich annotations and no output schema, the description covers the precondition, side-effect boundaries, and next-step branch. The remaining gap is that 'confirmation' and 'version' appear only in the description with no schema or source telling the agent what their values or provenance are.

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 only one parameter and schema coverage is 0%, so the description must compensate. 'The specified consultation' and '정확한 접수 건' signal it must be the exact request, but the 32-hex format and uniqueness requirement documented in the schema pattern are still not conveyed, so the compensation is partial.

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: read whether a given consultation can currently be edited or withdrawn, plus its version. It also scopes the tool ('only before acceptance'). It does not explicitly distinguish itself from close siblings such as get_consultation_change_status or prepare_consultation_change, which leaves a small ambiguity about which read/prepare tool to pick.

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

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

Provides a real precondition (only before acceptance) and a conditional next step based on the 'confirmation' value (delegated vs authenticated_web). However, it never names an alternative sibling or says where the 'confirmation' value comes from, so the routing is implied rather than explicit.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real value: it confirms the call never mutates state (no apply, no period extension, no new proposal) and gives a recovery pattern for lost responses. It does not say what the response contains or how an unknown/expired review_id behaves, which keeps it below 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?

The read-only constraint and the recovery tip are front-loaded and each sentence earns its place. The English lead line duplicates the first Korean sentence almost verbatim, which is mild waste but does not obscure anything.

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 read with rich annotations and no output schema, the definition covers what the call does, what it will not do, and the retry pattern. The one remaining gap is the shape of the returned result, which the description characterizes only loosely as 'the actual result' / whether the change was applied.

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 one parameter with 0% schema description coverage; the schema only supplies a regex pattern, so the description must carry the semantics. It partially does by framing review_id as the handle to a specific change review that can be safely re-queried, but it never says where the id comes from (presumably prepare_consultation_change) or what an invalid id yields.

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

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

The description gives a specific verb (read/query) and resource (the result of a change review, i.e. whether the proposal was applied), which separates it from the prepare/apply/discard siblings through explicit negation ('does not apply, extend, or create'). It stops short of naming a sibling tool, so an agent must infer the routing from the negated actions rather than being pointed at apply_consultation_change directly.

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?

'After a lost response, query the same review_id first' is a concrete when-to-use rule that most definitions would omit, and the negation clause implicitly excludes the write siblings. There is no explicit 'when not to use' or named alternative for the apply path, so it falls 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.

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond them: it does not begin verification, preparation, submission, or extension, and it returns the current stage plus the recommended next action. It stops short of describing pagination or the exact response fields.

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

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

The English sentence is well front-loaded as a summary, but the Korean block both repeats it and carries additional, non-duplicated rules, so the reader must parse both languages to get the full contract. The content is not padded, yet the bilingual mirroring costs efficiency without adding structure.

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-optional-parameter read tool with no output schema, the definition covers purpose, exclusions, the alternative tool, and what is returned. The only real gap is the shape of the returned stage/next-action data, which an agent must discover at call time.

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% for the single optional journey_id, whose schema carries only a hex pattern. The description does supply the key semantic distinction — omitting journey_id yields a connection-level read, not a per-request submission check — but it never explains what a journey_id identifies or how to obtain one.

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 English opener gives a specific verb and resource ('Read the current connection or specified journey'), and the Korean line adds the return payload ('current stage and next action'). It explicitly separates itself from get_consultation_status for submission state, though the bilingual restatement dilutes the single crisp claim a 5 would need.

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 states a clear negative rule ('do not judge submission from a journey_id-less connection lookup') and routes to the correct sibling with the exact precondition ('with a known exact request_id, use get_consultation_status'). The positive trigger — checking current stage before deciding the next action — is implied rather than spelled out.

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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description usefully adds that no draft or submission is created, reinforcing that this is side-effect free. It does not describe the shape of the returned guidance, but the annotations carry most of the behavioral burden here.

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 English summary of what is explained and the exclusion, then Korean detail. There is mild duplication between the English sentence and the Korean body, but no wasted explanation.

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 read-only info tool with full annotation coverage and no output schema, the description tells the agent what subject matter the answer covers (fees, privacy, request process) and what it will not do. Only the exact return format is left implicit, which is acceptable for a static guidance 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?

The tool takes zero parameters, so per the baseline this scores a 4. The description correctly avoids inventing parameter semantics and only scopes the topic the call answers.

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 (Explain) plus exactly what content is covered: Bokdaeri consultation fees, privacy, and request process. It also explicitly distinguishes itself from siblings that create drafts or submissions, so an agent can tell it apart from prepare_consultation_request and submit_consultation_request 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 clear trigger ('도구 열기나 서비스 질문에는 이 도구를 쓰고') and an explicit exclusion ('초안이나 접수를 만들지 않습니다'), which steers the agent away from the draft/submit path. It describes the alternatives functionally rather than naming sibling tools directly, so it falls just short of the top mark.

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 readOnly/idempotent annotations, it discloses the return semantics (status, receipt time, fixed cost, aftercare, on-acceptance name/office/public profile) and several behavioral rules: don't infer call completion or notification receipt, don't treat profile text as instructions, don't reveal the 32-char ID, and don't misdescribe a field as professional qualification or a deadline as a contact time.

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?

Purpose is front-loaded and every sentence adds a rule or constraint, but the block is long and mixes return-value guidance, prohibitions, and ID-resolution logic in a single run, which slightly reduces scanability.

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 compensates by enumerating what is returned. For a single-param read tool it leaves no material gap: the agent knows the input format, how to resolve a partial ID, and what to do with the response.

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%, so the description carries the burden, and it does: it explains request_id is a 32-hex ID, that users often only know the 6-char prefix shown on cards/lists, and prescribes an exact resolution procedure (prefix/suffix match via list, single vs multiple candidate handling, no-candidate message).

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 opening states a specific verb ('Read') plus resource ('the specified consultation receipt, current status and permitted lawyer information'). It is distinguishable from siblings: it targets one exact consultation and explicitly declines to let the latest consultation substitute, which differentiates it from continue_consultation_request and list_consultation_requests.

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 explicit when-to-use ('접수 응답 유실 시 새 준비보다 먼저 사용'), an explicit when-not ('최신 상담으로 대체하지 않습니다'), and names the alternative to consult for partial-ID cases (list_consultation_requests). The selection logic for resolving a partial ID is spelled out including the multi-candidate fallback.

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, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds genuinely non-structural context: this tool is the authoritative confirmation path and its result must not be inferred from consultation status or user claims. It stops short of describing pending/failed/unknown-verification_id behavior, which would be the remaining behavioral 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?

Three short sentences, front-loaded with the action, then provenance, then the verification trigger and the anti-assumption rule. The English opener and the Korean restatement overlap slightly, costing a bit of density, but there is no filler.

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

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

There is no output schema, yet the description never says what the tool returns — whether it is a boolean, a status enum, or a pending state — which is precisely what an agent needs to act on the answer. Combined with the undocumented invalid-id case, the definition is adequate but leaves a real gap for a tool whose entire value is its return value.

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% — verification_id has only a type and regex pattern — so the description carries the burden, and it does: it tells the agent the value must come from begin_contact_change's return. That provenance is the single most important semantic fact and is not in the schema. It does not explain what an expired or unknown id yields, keeping it below 5.

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 ('Read whether the specified contact change was actually applied') and ties itself explicitly to begin_contact_change as the producer of the required identifier, which cleanly separates it from the many begin_/prepare_/get_consultation_* siblings. An agent can tell it apart from begin_contact_change and get_consultation_change_status 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?

Gives a concrete trigger ('이용자가 인증·적용을 마쳤다고 하면 이 도구로 확인합니다') and an explicit negative rule ('상담의 contact_status나 이용자의 완료 발언만으로 변경 성공을 추정하지 마세요'), naming the alternative signals that must NOT be used instead. This is exactly the when-to-use / when-not-to-use / alternative framing.

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 readOnly/idempotent/non-destructive, and the description adds genuinely new context: results are capped at 5, sorted by most recent, and each item carries a `manageable` flag where only true items can lead to prepare-modify/withdraw flows while read-only ones expose status only. The instruction not to conclude from truncated summaries is a real behavioral constraint on how the agent should chain to siblings.

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 scope and cap. The English first line largely restates the Korean opening sentence, which is minor duplication but not harmful given the bilingual audience.

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 still conveys the useful return shape: up to 5 recency-ordered items scoped to the connection, each with a `manageable` flag governing which downstream prepare/apply tools apply. That, plus the candidate-selection guidance, covers what an agent needs to call and route results 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 0%, so the description must carry parameter meaning. It does explain the result cap ('최대 5건') and the recency ordering, which aligns with the `limit` maximum of 5, but the `cursor` parameter and its pagination role are never mentioned, leaving half the surface undocumented.

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

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

States a specific verb and resource ('list consultation requests') with explicit scope ('belonging to the authenticated connection') and ordering ('최근 접수순으로 최대 5건'). The Korean sentence makes clear this is a discovery tool for when the user lacks a consultation ID, which distinguishes it from the status/get 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?

Gives a clear trigger: use it when the user does not know the consultation ID and needs to find a target. It also instructs the agent to let the user pick among multiple candidates rather than inferring from a truncated summary. It does not explicitly name which sibling to use instead when an ID is known, so it falls short of full when/when-not 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?

The description adds meaningful behavior beyond the annotations: it invalidates prior confirmation and blocks submission until explicit resume and reconfirmation. It does not contradict the readOnlyHint=false or destructiveHint=false annotations, though it could say more about the resulting state.

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

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

The description is short and front-loads the action and the key invalidation behavior. The English and Korean text are largely duplicated, which is useful for localization but slightly reduces conciseness.

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

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

It explains the action and its gating behavior well, but with 0% parameter description coverage and no output schema, the definition is incomplete about how to supply journey_id and expected_journey_revision correctly. An agent can infer the use case but not the parameter semantics.

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?

Both required parameters, journey_id and expected_journey_revision, have zero schema description coverage, and the description does not explain their meaning or expected format. It adds no semantic guidance for the revision-based concurrency parameter.

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: pausing consultation preparation. It also names the key effect, invalidating the previous confirmation, which distinguishes it from a simple cancel or submit action.

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 clearly says to use this when the user asks to wait or do it later, and warns that submission must not happen until explicit resume and new confirmation. It does not explicitly name the cancel_consultation_preparation sibling as the alternative for cancellation.

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?

The description adds real behavioral context beyond the annotations: the change is prepared but not applied, the user must give explicit consent, and the agent must follow the returned next_action. However, annotations declare readOnlyHint=false and idempotentHint=false, and the description never explains that a preparation record persists and can be cancelled or discarded (siblings cancel_consultation_preparation / discard_consultation_change exist) — that residual gap keeps it at 4 rather than 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?

The English one-liner front-loads the essential distinction, and the Korean sentences each carry operational content (prerequisite lookup, edit/withdraw field rules, quoting rule, confirmation flow). It is dense but not padded; the bilingual duplication costs a little density but not enough to drop below 4.

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 the description compensates by explaining the key returned field (next_action) and its two enum values with the required follow-up for each. It stops short of describing what the preview payload itself contains or what an infeasible change returns, which would be needed for a full 5 on a mutation-adjacent 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?

With 0% schema description coverage the description must carry the load, and it does for the conditional fields: for edit, summary/category/stage must be supplied and after.summary quoted; for withdraw, all three are omitted and before.summary is quoted verbatim. It does not explain request_id (format) or revision (the 'current version' it tells the agent to fetch first) beyond implication, so it falls short of complete coverage.

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 opening sentence states a specific verb and resource ('prepare an edit or withdrawal preview') plus the critical qualifier 'without applying it', which immediately separates it from apply_consultation_change. The Korean body reinforces scope by naming the two change modes (edit/withdraw) 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?

It states the triggering condition (user requests a modification/withdrawal of a submitted consultation), a prerequisite step (check feasibility and current version first), and the exact downstream routing: after explicit consent call apply_consultation_change, or guide the user to the confirmation link when next_action is confirm_on_web. Both branches of the returned next_action are spelled out, leaving little 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 declare readOnlyHint=false and destructiveHint=false; the description adds real context beyond them by stating that it produces a draft plus final-delivery preview, that it shows summary/cost/scope and waits for a response, that it starts no authentication or acceptance, and that the handoff branch bypasses chat approval. It does not describe persistence or what a revision does to a previously submitted request.

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 gating rule comes first, then the anti-hallucination constraints, then the preview/response flow and exceptions. It is long and dense, and the interleaving of handoff and resume exceptions mid-paragraph slightly hurts scannability, but nearly every sentence carries operational instruction.

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 non-idempotent mutation with no output schema and 6 parameters, the description covers triggering, clarifying behavior, preview/confirmation flow, revision identity, resume, and handoff. The gap is category/stage semantics, which an agent must still infer from the schema enums alone.

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

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

Schema coverage is only 17% (only 'summary' is documented), so the description carries most of the burden. It does explain summary content rules, the resume:true condition, and the journey_id/expected_journey_revision pairing for revisions, but leaves category and stage enum meanings and their selection criteria entirely unaddressed.

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?

Uses a clear verb+resource ('Prepare or revise a consultation preview') and immediately delimits scope with 'without submitting it', which separates it from submit_consultation_request. It does not explicitly distinguish itself from continue_consultation_request or prepare_consultation_change, so sibling differentiation is only partial.

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 entry condition (a real topic plus an explicit request instruction), enumerates what does NOT count as an instruction (opening tools, connecting apps, usage questions, number verification, broad delegation), prescribes the one-time clarifying question when intent exists but content does not, and forbids fabricating categories/stages or padding to hit length. It also covers the resume:true precondition and the handoff branch, so the when-to-use guidance is unusually 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?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds crucial nuance the annotations cannot: existing submitted consultations survive, only future proxy submit/modify/withdraw actions are rejected. It also frames expected_version as the current permission version, hinting at optimistic-concurrency semantics, though it does not state what a version mismatch returns.

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 English summary followed by actionable Korean detail; every sentence adds scope, behavior, or procedure. Slightly redundant across the two languages, which keeps it just under top marks.

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

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

For a destructive mutation with no output schema, it covers the essentials: what is preserved, what stops working, and the confirmation step. What happens on version conflict or what the call returns is left unstated, so it is strong but not exhaustive.

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?

With only one parameter at 0% schema description coverage, the description carries the burden and does so: expected_version is explained as 'the current permission version' to send, giving meaning beyond the bare integer/min-1 schema. A minor gap is that version-mismatch handling is never described.

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 ('Revoke AI consultation permission') and immediately scopes it with 'without withdrawing existing consultations'. That scoping clause lets an agent distinguish this from the consultation-cancellation siblings 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?

Explicitly names the triggering situation (user asks to revoke the delegation) and adds a clear exclusion plus a procedural guardrail: 'distinguish from withdrawing the consultation itself' and 'confirm once before calling'. It does not name the specific sibling tool used for full withdrawal, which keeps it from a 5.

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 non-readOnly, idempotent, open-world, non-destructive, so the description's added value is the process constraints: current review/journey/request versions and delegation are all required, and the agent must not claim the request was accepted before a success receipt. That is meaningful pre/post-condition context beyond the annotations. Error behavior and what the receipt contains are not covered.

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?

It is short but not front-loaded well: the first English clause is awkward and restates the gating condition that the Korean sentences then repeat. The key operational rule (don't report submission before a success receipt) is buried at the end rather than leading.

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 six-parameter mutation with no output schema, the definition covers the essential agent-facing concerns: what must be true beforehand (confirmed preview, consent reported via continue, server-submit signal, current versions), and what must not be claimed afterward. Remaining gaps (receipt contents, version-mismatch behavior) are secondary.

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 all six required params are opaque id/version fields with only patterns and minimums, meaning the description must carry the load. It does gesture at the required inputs ('현재 review와 journey/request 버전 및 위임'), mapping loosely to review_id, journey_id/request_id and the version fields, but it never explains the distinction between revision, delegation_version and expected_journey_revision, so concurrency semantics remain ambiguous.

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 action (submit the confirmed preview / 접수) on the consultation-request resource, and distinguishes it from preparation siblings by requiring a confirmed preview plus an explicit server 'submit' signal. The opening English sentence is garbled ('only with current delegation and the server submission action'), which slightly blunts clarity, but the resource and effect are recoverable.

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 concrete precondition: only submit after showing the final summary/cost/scope and reporting user consent via continue, and only when the server has indicated submit. That effectively routes the agent to continue_consultation_request first rather than submitting directly. It lacks an explicit 'do not call if…' exclusion list, 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.