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

Annotations provide readOnlyHint=false and destructiveHint=true, correctly implying a mutating action. Description adds behavioral details critical for agent expectations: mutual requests become pending, 'already a neighbor' returns as 'already', and there is no unfollow. It also notes that the 'message' parameter is ignored unless mutual is true. Adding specific return semantics (already) is valuable beyond the generic annotations. Slight deduction for not explicitly stating that choosing follower status is permanent (given no unfollow), but that's implied.

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 moderately concise, opening with the core action and then immediately highlighting a platform-specific constraint ('Naver Blog only'). It then explains the two modes and a special return value, with a final note about 'no unfollow'. While it is a paragraph, each sentence contributes a distinct piece of actionable info. The ordering is sensible: action, key distinction, behavioral result, and boundary. A slight deduction for length but overall well-structured and front-loaded.

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

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

Given the tool has 5 parameters, one required, and no output schema, the description covers the key use cases: how to follow normally, how to follow mutually, outcomes for both, and the absence of unfollow. It addresses the optional parameters indirectly by saying they are only needed in multi-account scenarios, which is sufficient context. It lacks explicit mention of error cases beyond 'already', but with no output schema, listing all possible return values isn't strictly necessary. The description is sufficient for a competent agent to pick the right options and understand the flow.

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

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

Schema coverage is 100%, so description doesn't need to repeat parameter descriptions. However, the description adds value by explaining the behavioral interplay: the 'message' is sent only with a mutual request, and that mutual requests require acceptance (resulting in pending status). It also clarifies that 'accountId' and 'workspaceId' are optional unless there are multiple, providing selection criteria. This adds context that the schema descriptions (which likely say 'which' but not when) do not fully capture.

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?

Description clearly states the action ('Follow an account'), the specific resource (Naver blog as a neighbor), and provides a crucial scoping constraint ('Naver Blog only today' removes ambiguity about platform). Distinguishes from siblings like 'like' or 'reply' by focusing on neighbor-following. It also differentiates the two behavioral modes (mutual vs plain) with explicit timing (immediate vs pending acceptance).

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?

Description includes explicit when-to-use guidance: 'mutual: true' is used when a mutual request is needed; 'without it' plain neighbor. It also states the consequence of the 'mutual' option (pending until accepted). It disambiguates from other actions by specifying 'no unfollow', clarifying that this is one-way. While it doesn't name alternatives, the description makes the use case and decision rules explicit.

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