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

Annotations already declare destructiveHint=false, idempotentHint=false and openWorldHint=true, and the description adds real value on top: no publishing occurs, local images are auto-uploaded and embedded, and a dry-run mode previews what would be sent. It stops short of stating auth requirements or the non-idempotent effect of re-running with the same Markdown.

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 compact sentences: conversion/save first, then the no-publish constraint, then image handling, then the dry-run recommendation. Nothing is wasted; it could only be tighter by folding the image note into the first sentence.

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

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

For a 6-parameter, zero-required mutation-adjacent tool with no output schema, the description covers conversion, storage target, side effects (image upload), and safety (no publish, dry-run preview). Only authentication/credential expectations and the fact that repeated runs create duplicates (idempotentHint=false) are unaddressed.

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

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

Schema description coverage is 100%, so all six parameters (including dry_run, markdown/markdown_path exclusivity, base_dir, eyecatch_path) are already documented in the schema. The description only re-mentions dry_run and adds no syntax or format detail beyond it, so the baseline 3 applies.

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

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

States a specific verb+resource ('Markdown を note 用の HTML に変換し…新しい下書きとして保存する') with the medium and destination. The emphasis on a NEW draft distinguishes it from the sibling update_draft without needing to open either schema.

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

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

It recommends the dry_run-first workflow and clarifies that publishing is out of scope, which is useful guidance. However, it never explicitly states when to prefer create_draft over update_draft/list_drafts or what prerequisites (e.g. authentication) apply, so routing remains partly inferential.

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=true, so the safety profile is covered. The description usefully adds the sort order (newest first) and the fields returned — valuable context given there is no output schema — but it says nothing about pagination behavior despite the page parameter.

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

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

One compact sentence that front-loads the verb, scope, ordering, and return contents with no filler.

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

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

For a simple read-only list tool with annotations covering safety, the description adequately covers the return shape since no output schema exists. The only gap is that it does not explain pagination or how many drafts appear per page.

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

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

Schema description coverage is 100% and the single 'page' parameter is fully documented in the schema (range and default). The description adds nothing about pagination semantics, so the baseline 3 applies.

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

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

States a specific verb and resource ('返す' / '下書き') plus the ordering and returned fields, so it is clearly distinguishable from create_draft and update_draft. It stops short of explicitly naming those siblings as alternatives, but the verb makes the distinction obvious.

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 says what is returned but never says when to reach for this tool versus create_draft/update_draft, nor any prerequisite such as being logged in. Usage is only implied by the read-only listing nature.

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 openWorldHint=true, so the mutation and repeat-call profile is covered. The description adds the ID-validity constraint, but does not disclose the key behavioral risk implied by destructiveHint — whether an existing eyecatch is overwritten and how that interacts with idempotency. With annotations carrying the safety profile, a 3 is appropriate.

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

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

Two short sentences with zero waste; the core action is front-loaded and the ID constraint follows immediately. Nothing extraneous.

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

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

For a two-parameter mutation tool with no output schema, the description covers purpose and the ID constraint. It omits the overwrite/destructive behavior and any note on whether path must reference an already-uploaded image, which matters given destructiveHint=true.

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 documents both id (pattern ^\d+$) and path (PNG/JPEG/GIF, 10MB limit). The description adds only the constraint that id must come from the draft list, which is marginal over the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (設定する) and resource (見出し画像/アイキャッチ) scoped to an existing draft, so the action is unambiguous. It does not explicitly distinguish itself from sibling upload_image, which likely handles the upload step, leaving the boundary to inference.

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

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

The phrase '下書き一覧にある ID だけ受け付ける' gives a validity constraint (the ID must exist in the draft list) that implies when the tool is applicable. However, it names no alternative and gives no explicit when-to-use vs upload_image or update_draft, nor any prerequisites like uploading the image first.

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 openWorldHint=true, so the safety profile is largely covered. The description adds real value on top: the update is a wholesale replacement (丸ごと置き換える), not a patch, and it will not publish — useful specifics about what is destroyed and what side effect is deliberately absent. Remaining gaps (auth requirements, error behavior) are minor 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?

Three tight sentences with the core action front-loaded, then the scope constraint, then the non-publish guarantee. No filler and nothing an agent must scan past.

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 seven-parameter mutation tool with no output schema, the description covers the essential action, the destructive full-replacement semantics, and the eligibility constraint; dry_run return behavior is documented in the schema. It could still say more about failure modes or image handling, but nothing critical 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 seven parameters (including the markdown/markdown_path mutual exclusion and dry_run semantics) are documented in the schema itself. The description adds no parameter-level detail of its own, 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?

States a precise verb and resource: replaces an existing draft's title and body wholesale with the given Markdown. It also bounds the scope by noting published articles cannot be updated and that only draft-list IDs are accepted, which cleanly separates it from create_draft/list_drafts and from any publish step. An agent can tell exactly what this tool does 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?

Gives a clear when-not condition (公開済みの記事は更新できない, only IDs present in the draft list are accepted) and clarifies it will not publish. It does not, however, explicitly name an alternative (e.g. create_draft for new drafts or a publish action), so the routing guidance is contextual 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 cover the safety profile (destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds real behavioral context: accepted MIME types, the 10MB limit, and that the output is an embeddable URL. It does not mention auth requirements or what happens on oversized/unsupported files, so it falls just short of a 5.

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

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

Two tight sentences, with the core purpose and constraints front-loaded and the routing guidance following immediately. No redundant filler.

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

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

For a single-parameter upload tool with no output schema, the description covers the resource, constraints, return value (embeddable URL), and when not to use it. Everything an agent needs to call it correctly is present.

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

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

Schema description coverage is 100% and the single 'path' parameter is documented there. The description's 'ローカルの画像' clarifies the path refers to a local file, adding minor value, but the format/size constraints are resource-level rather than parameter-level, so this stays at baseline.

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 (upload a local image to note) plus accepted formats and size cap, and clarifies it returns an embeddable URL. It is clearly differentiated from siblings like create_draft, which it names.

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

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

Explicitly tells the agent that create_draft normally performs this automatically and that standalone use is rarely needed — a direct when-not-to-use statement naming the alternative tool.

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