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 structurally. The description adds no behavioral context beyond that — nothing about what the 'introduction' contains, whether it is static, or why an agent would call it. It also does not contradict the annotations.

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

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

A single short sentence with no padding; front-loading is adequate since there is only one claim to make. It is concise, though arguably too terse to be informative rather than efficient.

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 an output schema present and zero parameters, the description carries little structural burden, and the tool's complexity is minimal. However, it still fails to say what the about-content covers or who the intended audience/purpose is, leaving the agent to guess what it gains by calling it.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. Parameter semantics are inherently complete for a no-argument tool.

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

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

The description ('Introduction to the place where WriteMoa was made (NodeMoa)') conveys that this tool returns background/about information, but it largely restates the name 'about_writemoa' rather than specifying what content is returned. It does not differentiate itself from sibling tools such as list_styles or get_my_style_guide, though those are clearly unrelated in intent.

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

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

There is no guidance on when to use this tool versus any alternative, no mention of prerequisites, and no indication of what an agent should do with the result. The agent must infer usage entirely from the tool name.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds one genuine behavioral fact not in the annotations or schema: an empty 'kind' triggers inference, falling back to a '종류 미정' bucket that is always folded into the overall style. It does not cover failure modes, deduplication, or what the write 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?

Two short sentences, front-loaded with the core action and followed by the one non-obvious default rule. No filler, though the parenthetical about the overall style is slightly compressed and could be 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?

An output schema exists, so return values need no explanation, and all four parameters are fully documented in the schema. The description supplies the remaining non-obvious rule (kind inference fallback), leaving only minor gaps like duplicate handling.

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

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

Schema description coverage is 100% and the schema already explains kind, style, and text thoroughly (including pointing at list_writing_kinds and the kind-vs-style distinction). The description only restates the kind default behavior, so it adds little beyond the structured field — baseline 3.

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

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

The description names a specific verb+resource ('사용자가 직접 쓴 글 한 편을 넣는다' — adds one self-written piece), which clearly separates it from read_my_writing/list_my_writings/remove_my_writing siblings. It stops short of explicitly naming any sibling, but the action is unambiguous.

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

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

It gives useful in-the-moment guidance about the 'kind' field ('비우면 짐작하고, 확실하지 않으면 「종류 미정」') but never states when this tool should be chosen over alternatives such as import_my_naver_blog or set_writing_kind. Usage context is implied by the domain rather than stated.

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 openWorldHint=false and idempotentHint=true, so the agent already knows this is a bounded, repeatable operation. The description adds genuinely new behavior: analysis is auto-triggered on add/remove of writing. It does not state the operation is read-only, but with an output schema present, return-format disclosure is unnecessary.

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

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

A single compact sentence with the primary action front-loaded and the caveat about auto-analysis parenthetically attached. Nothing is redundant, though the parenthetical slightly muddies the main statement.

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, idempotent tool with a documented schema and an existing output schema, the description covers the essentials: what it returns and the fact that analysis happens elsewhere. The only gap is lack of explicit differentiation from sibling style tools.

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

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

There is a single optional parameter with 100% schema description coverage, and the schema already explains the '기본' default, when to leave it blank, and the style-vs-kind distinction in detail. The description adds nothing about the parameter, so the baseline of 3 is appropriate.

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

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

The description gives a clear verb+resource ('내 문체 요약을 본다' – view my style summary) and importantly reconciles the misleading tool name by clarifying that the analysis itself is automatic, so this tool only retrieves the summary. It does not, however, differentiate itself from close siblings such as get_my_style_guide or list_styles, leaving the agent to guess which summary/guide 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?

There is a partial when-not-to-use signal ('분석은 … 저절로 되니 따로 부르지 않아도 됨'), telling the agent it need not trigger analysis separately. However, no alternative tool is named and no positive condition ('call this when you want to display the user's style summary') is stated, so the routing guidance is only implied.

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

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

Annotations declare only openWorldHint=false and idempotentHint=true; there is no readOnlyHint, so the description carries the rest. It implies a non-mutating analysis by saying it 'tells' the user what to fix, and enumerates the analysis dimensions, but says nothing about permissions, whether the draft is stored, or performance. Useful but incomplete.

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 that front-loads the core action (compare draft to my writing) before the long parenthetical checklist of dimensions. Efficient and well-ordered, though the parenthetical enumeration 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?

An output schema exists, so return formatting needn't be explained, and the schema fully documents the four parameters. The description explains what the analysis covers, making it complete enough for an agent to call the tool correctly; only sibling routing is missing.

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

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

Schema description coverage is 100% and all four parameters are documented in the schema (kind, text, style, title). The description only obliquely touches parameters via '그 종류에 빠진 것' (what's missing for that kind), which loosely relates to the kind parameter but adds no new syntax or constraints. Baseline 3 is appropriate.

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

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

The description gives a specific verb (알려 준다, 'reports') and resource (a written draft compared against the user's own writing), and even enumerates the dimensions checked (tone, length, line breaks, punctuation, AI-ness, missing elements for the kind, duplicate old sentences). This clearly distinguishes it from siblings like analyze_my_style, though that contrast is not spelled out 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?

Usage is implied – you run it on a draft to get revision guidance – but there is no explicit when-to-use/when-not, and no routing against the closely related analyze_my_style or get_my_style_guide. An agent can infer the context but gets no exclusions or 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?

Annotations only declare idempotentHint and openWorldHint=false, so they convey little about output. The description adds real behavioral content: the fallback rule that when fewer than 2 writings of a kind exist, it returns common habits plus the kind's basics. This conditional behavior is not in the annotations or schema and directly shapes the agent's expectations.

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

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

Two tight sentences with zero filler, front-loading the core purpose before the conditional fallback detail. Every clause carries information the agent needs.

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?

An output schema exists, so return values need not be explained, and annotations cover idempotency. The description supplies purpose, timing, and the important fallback branch, leaving only minor gaps such as how results relate to analyze_my_style.

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

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

Schema description coverage is 100%, so both kind and style are already documented (including the note that kind is an id/name and style is normally left empty). The description clarifies that supplying kind selects the per-kind guide, adding marginal meaning over the schema, so baseline 3 is appropriate.

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

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

States a specific verb+resource: reading one's own style guide (문체 안내서), and specifies the branching behavior when a kind is supplied. It is clearly distinguishable from list/analyze siblings by being a retrieval-of-a-curated-guide tool. It stops short of a full 5 because it never explicitly names which sibling it complements or replaces (e.g. analyze_my_style).

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 opening phrase '글을 쓰기 전에 읽는' establishes a clear usage moment (before writing), which is genuine context. However there are no explicit when-not conditions and no named alternatives (check_draft, analyze_my_style), so the routing decision is left 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?

Annotations mark this as a write with openWorldHint=true, and the description adds real value beyond that: only public posts are imported, and critically it warns that the service cannot verify ownership, so misuse is the user's responsibility. It does not cover rate limits, failure modes, or what happens to duplicate posts, but the ownership caveat is substantive.

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, followed by the ownership constraint. No filler or restatement of the tool name.

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?

An output schema exists, so return values need no explanation, and the schema covers all parameters. The description supplies the key behavioral caveat (ownership unverifiable, public posts only). Missing only auth/prerequisite context, which is minor given the annotation profile.

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 all three parameters (blog, count, style) are already documented in the schema, including the note about style vs kind. The description adds no parameter-level detail, so baseline 3 applies.

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

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

States a specific verb and resource — fetching and inserting recent public posts from the user's own Naver blog — which is distinguishable from siblings like add_my_writing (manual entry) and read_my_writing (retrieval). It does not name a sibling explicitly, but the scope is concrete enough for selection.

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 explicit exclusion — only the user's own blog, never someone else's — which is genuine usage guidance. However it says nothing about when to prefer this over add_my_writing or what prerequisites (e.g. being logged in, blog reachability) are needed.

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 safe-read profile is covered. The description adds only that the result is a scoped list of the user's own writings, which is modest value; it discloses nothing about ordering, pagination, or emptiness 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 compact sentence with the resource front-loaded and zero filler. It is appropriately sized, though it is terse enough that it borders on under-specification rather than being a model of informative brevity.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. With one fully-documented optional parameter, the description carries enough to call the tool correctly, missing only sibling routing guidance.

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

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

Schema coverage is 100% and the single 'style' parameter is documented thoroughly in the schema, including the style-vs-kind distinction and the '기본' default. The description adds no parameter meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a clear verb+resource (list my stored writings) and even enumerates the returned fields (number, kind, title, character count). It distinguishes itself implicitly from read_my_writing and add/remove_my_writing through the 'list' verb, but does not explicitly name or contrast with any sibling.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives like read_my_writing for a single item or list_writing_kinds. The style/kind distinction lives in the schema, not in usage guidance, so an agent gets no routing help from the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the concept of grouped style bundles, but no additional behavioral context such as ordering, pagination, or what the listing contains.

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

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

A single concise sentence that front-loads the purpose. It is appropriately sized for a simple list operation, though it omits any structural detail beyond the parenthetical example.

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

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

Given the tool has no parameters, an output schema, and read-only annotations, the description is near complete. The only notable gap is the lack of when-to-use guidance relative to sibling list operations.

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?

Zero parameters, so the description has nothing to compensate for and the schema is fully documented. Baseline 4 applies for a no-param tool.

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

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

States a specific verb+resource ('list' + 'styles'), and the parenthetical clarifies that styles are grouped into bundles/categories. It is distinguishable from siblings like list_writing_kinds, though it doesn't explicitly contrast itself with them.

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

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

The description offers no guidance on when to use this tool versus alternatives such as get_my_style_guide or list_writing_kinds. No exclusions, prerequisites, or contexts are provided.

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 conceptual context about why kinds are tracked but says nothing extra behaviorally (e.g. that this is a fixed/derived list, or auth needs), which is acceptable given annotation coverage.

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

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

A single front-loaded sentence that names the resource first, then the reason the kinds axis exists. Efficient, though the explanatory clause is more thematic than operational.

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?

An output schema exists, so return values need not be described, and with no parameters there is little else to specify. The description is adequate for a simple read-only enumerator, missing only the sibling tie-breaker against list_styles.

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 no parameter semantics to document; the baseline of 4 applies. The description correctly implies a no-argument listing operation.

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 lists writing kinds (글 종류 목록) and clarifies the concept by naming concrete kinds (blog, announcement, email, paper). This implicitly separates 'kinds' from the sibling list_styles, though the distinction is never stated outright.

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 rationale ('same person's style differs per kind, so it learns separately') implies when kind-level granularity matters, but there is no explicit when-to-use instruction and no mention of the adjacent list_styles tool that an agent could easily confuse it with.

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 and openWorldHint=false already tell the agent this is a safe, closed-world read, so the description's burden is light. The word "본문" (body text) usefully signals that it returns content rather than metadata, but nothing is said about behavior on a nonexistent or wrong-owner id, and the return shape is left to the output schema.

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

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

A single short sentence with no filler, and the scope-defining word (본문, 한 편) is front and center. It is arguably too terse rather than padded, so efficiency is not the issue.

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 an output schema, full parameter coverage, and safety annotations already present, most of the agent's needs are covered by structured fields. The description nonetheless omits retrieval prerequisites (id must exist / come from listing) and any error expectation, leaving it just adequate for a simple read 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%, including a thorough style explanation and the note that writing_id is the number from list_my_writings, so the schema does the heavy lifting. The description contributes no additional parameter meaning, which is the baseline 3 case.

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

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

"넣어 둔 글 한 편의 본문을 본다" names a concrete verb (본다/read) and a concrete resource scope (a single stored writing's body), which implicitly separates it from list_my_writings (listing) and check_draft (draft review). It stops short of explicitly naming any sibling, so an agent must infer the boundary.

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

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

No when-to-use, when-not-to-use, or alternative is stated. The only hint that writing_id comes from list_my_writings lives in the schema, not the description, so routing guidance is absent from the text itself.

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 earns credit for the additional non-obvious behavior: deletion happens on the local disk folder and the analysis is re-run excluding the removed writing — a cascade side effect an agent could not read off the annotations.

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, front-loaded with the destructive action and location, followed by the re-analysis consequence. No filler or repetition.

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

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

An output schema exists and annotations cover safety and idempotency, so the description only needs the disk-location scope and the re-analysis side effect — both present. The missing piece is failure/prerequisite handling, but the essentials are covered.

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

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

Schema coverage is 100% and the writing_id description even points at list_my_writings for discovery, so the schema carries the parameter burden. The description adds nothing beyond the schema about writing_id or style, making the baseline 3 appropriate.

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

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

The description states a specific verb+resource (deletes one writing) and scopes it to a concrete location (the 내글모아 folder on the user's computer), which separates it from read/write siblings like add_my_writing and read_my_writing. It does not explicitly name a sibling it replaces, but the action is unambiguous.

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

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

There is no when-to-use guidance, no prerequisite (e.g. that the writing_id must already exist, or what happens if it doesn't), and no alternatives mentioned among the many siblings. The agent must infer usage entirely from the verb.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description only restates the mutation implied by the name (바꾼다) and adds no context about reversibility, permissions, or effect on existing data, which is minimal value over the structured fields.

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

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

A single short sentence, front-loaded with the verb and resource and free of filler. It is efficient, though its extreme brevity leaves clear gaps that conciseness alone cannot offset.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a mutation tool whose description is essentially a name restatement, missing usage context leaves it only minimally 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 kind, style, and writing_id are all documented in the schema with usage notes (e.g., the style/kind distinction, 「미정」 clearing the kind). The description adds nothing beyond that, so the baseline 3 applies.

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

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

The description gives a specific verb (바꾼다 = changes) and a specific resource (넣어 둔 글의 종류 = the kind of a stored writing), so an agent can distinguish it from read/list/remove siblings. It does not explicitly name or contrast a sibling, so it stops short of a 5.

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

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

There is no when-to-use, prerequisite, or alternative guidance in the description. The only routing hint (use list_writing_kinds for kinds, 「미정」 to clear) lives in the parameter schema, not the description.

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