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

With no annotations, the description carries the full disclosure burden. It does disclose a meaningful behavioral trait: trying GraphQL first and falling back to Playwright on auth/API errors, plus the image pipeline (HTML/SVG → screenshot → velcdn upload →  embed). However, it omits end-state behavior when both paths fail, side effects, and account/auth requirements beyond a schema reference.

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 core behavior is front-loaded in one clear sentence, but the writing style guide is a large 7-bullet block of content-quality guidance that is only tangentially needed for invoking the tool. It is organized with a header and bullets, but much of it is verbose secondary material rather than scannable invocation-critical information.

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

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

This is a complex tool (5 parameters, dual execution paths, image generation) with no output schema and no annotations. The description never states what the tool returns on success (post URL? ID?), what happens if both GraphQL and Playwright fail, or whether drafts are recoverable. The style guide is thorough on content but thin on the operational contract an agent needs.

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 60%, and the writing style guide substantially compensates for the gap: it specifies body structure (## subheadings, --- dividers, bold emphasis, lists, short paragraphs), tone (first-person, experience-based), and title hook patterns. This adds rich meaning beyond the schema's bare '마크다운 본문' field. tags and publish gain little from the description, but publish is already well documented in the schema.

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

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

The opening sentence '벨로그에 새 글을 작성합니다' states a specific verb (create) and resource (Velog post). The word '새 글' (new post) implicitly distinguishes this from the sibling velog_edit_post, though it never names that sibling 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?

No guidance on when to use this tool versus velog_edit_post, velog_login, or velog_list_posts. There are no usage conditions, prerequisites, or exclusions. The only usage-adjacent text describes the internal fallback mechanism (GraphQL → Playwright), which is behavioral, not selection 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?

Without annotations, the description must disclose side effects, but it only notes 'GraphQL 전용, 폴백 없음' (GraphQL-only, no fallback). It does not mention that the operation mutates the post, requires authentication/ownership, or how existing fields are replaced or merged.

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 first sentence is efficient, but it is followed by a large, unrelated 'writing style guide' block that dominates the description. Most of that content does not help an agent invoke the tool and should be moved elsewhere.

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

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

For a mutation tool with five parameters, no annotations, no schema descriptions, and no output schema, the definition is incomplete. It omits authentication/account requirements, partial-update behavior, error conditions, and return information; the style guide does not fill these 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%, and the description fails to explain any of the five parameters, including required 'id' and 'account', or the optional 'body', 'tags', and 'title'. The style guide discusses writing style but not parameter meaning, format, or relation to the schema.

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

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

The opening sentence states the operation clearly: '기존 벨로그 글을 수정합니다' (edits an existing Velog post), with a specific verb and resource. The word '기존' (existing) distinguishes it from creation, but it does not explicitly contrast it with sibling tools.

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 guidance on when to use this tool versus velog_create_post, velog_list_posts, or velog_list_accounts. The only contextual clue is that it edits an existing post, and the long style guide is about content writing, not tool selection.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It only says the tool returns a list and does not disclose whether this is a read-only local operation, whether prior login is required, or what the exact return shape is. For a simple list tool the risk is low, but the description adds no behavioral context beyond the action itself.

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 a single, tightly written sentence in Korean that front-loads the resource ('등록된 벨로그 계정 별칭 목록') and the action ('반환합니다'). Every word earns its place, with no redundancy or 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 parameterless list tool, the description is minimally adequate: it states what is returned and no input is needed. However, there is no output schema to define the response structure, and the description does not clarify whether the list is in-memory, persisted locally, or requires an active session. This leaves a small but real gap for an agent deciding if the tool is applicable.

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 has zero parameters, so the baseline is 4. There is nothing for the description to add about parameter meaning or syntax, and no schema gap to compensate for.

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 ('반환합니다' / returns) and a specific resource ('등록된 벨로그 계정 별칭 목록' / list of registered Velog account aliases). This clearly distinguishes it from siblings like velog_list_posts (which lists posts) and velog_login (which authenticates).

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 implies this tool is used to see registered account aliases, likely before other Velog operations, but it does not explicitly state when to use it or mention alternatives. No exclusions or routing guidance is provided, leaving the context to be inferred from the 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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation and recency ordering, but does not disclose authentication needs, pagination behavior, error handling, or any side effects. The basic read nature is clear, but little else 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?

A single sentence that conveys the core purpose with no filler or redundancy. It is appropriately short and front-loaded, making it easy to parse.

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, no annotations, and minimal parameter documentation, the tool description is not complete enough for an agent to invoke it confidently. Missing details include the response shape, whether authentication is required, and how the 'limit' parameter behaves.

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 schema description coverage is 0%, so the description must compensate. It indirectly clarifies that 'account' is the author of the posts, but it says nothing about 'limit' or its default behavior. This leaves one of the two parameters effectively 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?

The description states a specific verb ('조회합니다' = retrieves) and resource ('해당 계정이 쓴 최근 글 목록' = recent posts written by that account). This clearly distinguishes it from the sibling tools like velog_list_accounts, velog_create_post, and velog_login.

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

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

The description only states what the tool does. There is no guidance about when to use it versus alternatives, whether prior login via velog_login is required, or how to obtain the account name. An agent gets no context for choosing this tool over other operations.

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

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

No annotations are provided, so the description carries the full burden. It discloses that a browser window is opened, the session is saved as a profile, and manual token insertion is avoided. However, it does not mention interaction expectations, potential for existing session overwrite, or what the call returns when completed.

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

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

Three sentences each add distinct value: what, when, and outcome. No filler words, and the most important action appears first.

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 login tool with no annotations or output schema, the description covers the essential context: why, when, and the persistent effect. It could mention what the tool returns or how the agent confirms login success, but the side effect of saving a profile is stated.

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 only parameter 'account' is already documented in the schema with an alias example, and schema coverage is 100%. The description doesn't add additional meaning about the parameter, but also doesn't need to because the schema does the job.

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: opens a browser window to proceed with velog login. This clearly distinguishes from sibling tools like velog_create_post or velog_list_posts, which handle content operations. The action is not a tautology of the tool name.

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 says when to run: on initial use or when session expires. It doesn't name alternatives or exclusion conditions, but the context is enough for an agent to decide. Sibling tools are for other purposes, so no ambiguity.

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