uplika

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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description adds a concrete consequence ('Making it public') and the prerequisite state ('held by reply approval'). It doesn't explain 'ignore' behavior or the return format, but it extends beyond annotations meaningfully.

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, front-loaded sentences with no filler. Each clause carries signal: platform, action, scope, effect, and workflow hint.

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?

The schema fills in parameter details and queue-listing behavior, but with no output schema the description doesn't state return values, 'ignore' semantics are under-specified, and the 'pending: true' hint is ambiguous without naming a tool. A small but real gap remains.

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 75%, with approve, replyId, and workspaceId already documented. The description adds no new parameter detail; the 'pending: true' remark isn't a parameter on this tool and doesn't clarify any input.

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 ('approve') and resource ('a reply held by reply approval'), scopes the tool to Threads, and clarifies the outcome ('makes it public'). This clearly distinguishes it from siblings like delete_reply, hide_reply, and reply.

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 clear usage context: Threads-only, for replies held by reply approval, and instructs the agent to read the queue with 'pending: true' before acting. It doesn't name alternatives or state exclusions explicitly, but the context is sufficient to route correctly.

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 a safe read; the description goes far beyond them, enumerating the state values (online, offline, logged_out, login_needed) and what each means, the per-OS wake commands, the ~1 minute reconnection window, queued post behavior, and the fields userMessage/extensionVersion/kinds. This is rich behavioral context an agent needs to interpret and act on the result.

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 hard constraint ('Naver Blog only') and the primary instruction ('Call this before publishing'), then streams return-field semantics efficiently. It is dense and runs long with several clauses per sentence, but nearly every clause carries actionable information, so little is wasted.

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?

No output schema exists, so the description must carry the return contract, and it does: state enum meanings, userMessage, queued, extensionVersion, kinds, and the wake commands. Combined with the pre-publish usage rule, an agent has everything needed to call and interpret this 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% and both parameters are documented in the schema itself, so the baseline is 3. The description adds no additional semantics for accountId or workspaceId (no format, defaulting, or edge-case guidance), so it neither compensates nor detracts.

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: checking the Naver Blog publishing bridge (browser extension) status and returning wake commands. The scope is pinned with 'Naver Blog only' and it explains the mechanism (posts written by the uplika extension in the user's own Chrome). It does not differentiate itself from the related sibling diagnose_naver_blog, which keeps it 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?

Explicitly says when to call it ('Call this before publishing to Naver Blog'), what to do with the result (relay userMessage, run wake commands), and how to follow up ('call this again or get_post to check'). It also notes that publish returns the same bridge object, and names siblings that interact with queued posts (delete_post, update_post).

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 value beyond the annotations by explaining that the operation only creates a draft and does not immediately complete the automation. It also conveys the follow-up workflow involving put_automation. The annotations already signal a non-read-only, non-destructive mutation, so the description does not need to restate those.

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 two short sentences with no filler. The core behavior is front-loaded, and the alternative workflow is stated in one clear sentence. Every clause earns its place.

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?

The description provides enough context to select and invoke the tool correctly, including the template source and what to do when no template fits. The absence of an output schema means return details are not specified, but for a draft-creation step this is a minor gap given the clear workflow.

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 already covers most parameters, and the description meaningfully connects templateId and params to list_automation_templates, telling the agent where the values come from. This adds semantic guidance beyond the bare property descriptions, especially for the nested params object.

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 ('Create'), a specific resource ('an automation'), and the source ('any template in list_automation_templates'). It also clarifies the immediate outcome ('Creates a draft'), making it easy to distinguish from related tools like put_automation or enable_automation.

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 explicitly says when to use this tool: when creating from a template. It also names the alternative for uncovered cases: 'build the document yourself and call put_automation on the draft.' This gives a clear either/or routing decision with no reliance on 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 only declare it is a non-read-only, non-destructive, closed-world write. The description goes far beyond that: draft-only until enable_automation, the Meta private-reply mechanics (one per comment, 7-day limit, 24-hour window), one-time fileUrl validation on save, delivery ordering, and platform-specific rejection rules. This is exactly the behavioral context annotations cannot carry.

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 critical constraint ('Creates a draft; nothing goes out until enable_automation') is bolded and front-loaded, which is good. But the body is a single dense run-on paragraph mixing file handling, platform rules, ordering, and error codes; it is informative yet hard to scan and could be structured into sections.

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 23-parameter, nested-object tool with no output schema, the description covers the essential behaviors an agent needs: lifecycle (draft + enable), platform constraints, delivery ordering, file-delivery paths, and public-reply rules including the AI mode's dependency on publicReplyInstruction. Little an agent needs to invoke it correctly 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 coverage is 74% and the description adds real meaning on top: post accepts 'any'/'next'/id/link, fileUrl vs mediaId 'not both', openingDm:false semantics, and followUp's dependency on openingDm plus a link. However several params (match, emailRetry, recheckTitle, emailMessage, notFollowingMessage) remain undocumented in both schema and description, so it doesn't fully compensate.

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?

Opens with a concrete verb+resource framing ('when someone comments on a post, DM them') and immediately clarifies the draft semantics. It names the sibling that must run afterward (enable_automation) and the alternative for Threads (create_automation with comment_public_reply), so an agent can distinguish it from 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?

Explicit when/when-not coverage: use create_automation for Threads, requireFollow is rejected on Facebook, openingDm:false rejects requireFollow/askEmail/followUp/files, and fileUrl vs mediaId are mutually exclusive. The 409 next_post_taken and 7-day window constraints tell the agent exactly when this call succeeds or fails.

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 flag destructiveHint=true, but the description adds the non-obvious consequences: run history is destroyed with the automation, the action is irreversible, and live automations are hard-refused unless force is used. It also explains WHY the confirmation matters ('deleting it stops what is going out to people'), which is behavioral context no annotation provides.

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, front-loaded with what is deleted, then irreversibility, then the refusal/force mechanics. No filler and no repetition of the title.

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?

No output schema exists, so the description carries the error-contract burden and does so (automation_live error, force override, workspaceId omission rule echoed in the schema). For a destructive 3-parameter tool, an agent has everything needed to call it safely.

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 67% and the schema itself documents force and workspaceId. The description still adds real meaning for force (it only matters for live automations, and requires person confirmation first), which the schema's 'Delete even if it is live' does not convey. The id parameter remains undocumented in both places, but its meaning is self-evident.

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 ('Delete an automation') and immediately extends scope to 'and its run history', which distinguishes it from sibling disable_automation (a non-destructive state change) and from delete_post/delete_reply. An agent can tell exactly what is removed 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?

Explicitly names the alternative path ('disable it first'), the blocked case (live automation refused with automation_live), and the escape hatch ('pass force: true after the person confirms'). This is a complete when/when-not/alternative statement, with the required human-confirmation gate 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 destructiveHint=true and openWorldHint=true, but the description adds critical context: irreversibility, channel-specific quotas, draft/scheduled behavior, 409 account_disconnected handling, bridge.nextStep protocols, and a retry cap. No contradiction with 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?

The purpose and irreversibility warning are front-loaded, and the dense channel/error details are valuable. However, the long unbroken paragraph could be structured with lists for faster scanning, and a few clauses feel redundant.

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 high-complexity destructive tool with no output schema, the description is remarkably complete: it covers channel limits, error responses, bridge workflows, and draft semantics. An agent has everything needed to invoke and handle outcomes 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 100%, so both parameters are fully documented in the schema. The description repeats the accepted id forms but adds no new syntax or format details beyond what the schema already states. 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 ('Delete a post from the channel') and immediately clarifies the irreversible nature. The resource 'post' inherently distinguishes it from siblings like delete_reply or delete_automation, so an agent can select it without ambiguity.

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 extensive when/when-not guidance: channel-specific daily limits, accounts where deletion is impossible (TikTok no API, Instagram login cannot delete), Facebook Page-only restriction, and the alternative (tell the person to delete in the app). This goes well beyond naming an alternative and covers preconditions and exclusions.

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 mark destructiveHint=true, but the description adds substantial context: deletion is irreversible, it removes anyone's comment on Instagram/Facebook but only the connected account's replies on Threads/Bluesky. This goes well beyond the hint flag and accurately describes what gets destroyed.

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 sentences cover purpose, irreversibility, platform differences, and an alternative recommendation with no filler. The most critical fact ('cannot be undone') is front-loaded, and the description is efficiently ordered.

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 tool with no output schema and a simple flat parameter set, the description is complete: it covers irreversibility, platform-scoped behavior, support lookup via list_platforms, and the hide_reply fallback. The agent has everything needed to decide when and how to invoke this tool 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 100%, with postId, replyId, and workspaceId all documented inline. The tool description adds no new parameter-level meaning beyond what the schema already provides, so the baseline score 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 states a specific action ('Delete a comment for good') and distinguishes itself from hide_reply, which is the key sibling it could be confused with. It also explains channel-specific behavior (Instagram/Facebook vs Threads/Bluesky), making its purpose unmistakable.

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 'This is not hide_reply' and advises 'Prefer hide_reply when the person just wants it out of sight,' giving a clear when-not-to-use and alternative. It also directs the agent to list_platforms to determine channel support, providing actionable 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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses topic-dependent output behavior: without a topic it returns an overview and topic list, with a topic it returns that section in full including 'mistakes that fail silently.' It also reveals data provenance—the values come from the same grammar the publisher validates against—adding meaningful trust context.

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 dense but well-structured: it front-loads the purpose, then platform scope, then usage timing, then behavior, then reliability. Examples like 'highlighting a phrase, a styled table, a collage' make the advanced-use case concrete without wasting space.

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?

Even without an output schema, the description tells the agent exactly what to expect for both call shapes (with and without topic), the non-Naver edge case, and the guarantee that returned syntax matches what publish accepts. Combined with the annotations, there is no obvious missing information for invoking the tool 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?

The schema already covers all three parameters at 100% coverage, so the baseline is met. The description adds extra meaning for the topic parameter by describing what happens with and without a topic, and clarifies platform behavior by noting that non-Naver platforms return not_supported rather than an error.

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 clearly states the tool's purpose: it provides the body-writing syntax for a channel that has its own markup, specifically Naver Blog. It distinguishes the tool from siblings by explicitly calling out that every other platform returns not_supported, making it unmistakably a lookup/reference tool rather than a publishing or mutation tool.

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 explicit call timing: 'Call this before writing a Naver Blog body for the first time, or whenever you want something the basics do not cover.' It also tells agents what to expect for unsupported platforms—not_supported is not an error to work around—which functions as clear 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 readOnly/openWorld/non-destructive, but the description goes well beyond them: 24-hour caching, a 20-per-day per-person quota surfaced in the response, the 50-post cap and what summary.capped means, and a caveat that seedCandidates are candidates rather than proven keywords. That is substantive behavioral context an agent cannot get from 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?

Front-loaded with the core purpose and tightly packed with useful facts, but several sentences are long and clause-heavy, so a reader has to parse a lot to extract the quota and cap details. Little is wasted, though it could be broken into cleaner units.

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 correctly carries the return-value burden, naming the fields it produces (seedCandidates, summary.oldest/newest/capped, flags, thresholds.lowIntentPct). Combined with cached/quota/403 details, an agent has everything needed to call and interpret this 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%, so the schema already documents both 'blog' and 'workspaceId' in detail (including the do-not-ask-again guidance). The description adds no additional parameter meaning, 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 ('Reads a blog's public RSS feed... says whether the titles are written for search') and scopes it to Naver Blog only. It enumerates the concrete outputs (intent share, date/episode prefixes, posts per month, categories, repeated words), which distinguishes it from keyword-research siblings like research_naver_keywords and expand_naver_keywords.

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?

Explicit when-it-works context: any public blog, not only connected ones, no Naver keys required. It also gives operational conditions — cached 24 hours, a cache miss costs one of 20 daily diagnoses — and the exact failure path (403 research_tool_disabled with enableUrl, plus the instruction to tell the person once and not retry).

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 discloses a specific behavioral nuance beyond annotations: 'Runs already waiting for a button stay waiting but nothing new starts.' This informs the agent that the operation does not cancel pending runs, only prevents new ones. Annotations only indicate non-read-only and non-destructive, so this added detail is valuable and non-contradictory.

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 two concise sentences, front-loaded with the main purpose and immediately followed by a key behavioral detail. There is no redundancy or fluff, and every word earns its place.

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 mutation tool with one required parameter and no output schema, the description covers the essential behavior (stopping an automation and its effect on pending runs). The optional parameter is well-documented in the schema. Nothing critical is missing for an agent to correctly invoke the tool, though it could have mentioned the result or success indication, but that is minor.

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 50% (id has no description, workspaceId has a detailed one). The tool description adds no parameter information. With low schema coverage, the description should compensate, but it does not. The id parameter is left undocumented in both schema and description, so the agent gets no additional meaning about the parameters from the description.

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 clearly states the action ('Stop an automation') with a specific verb and resource. It also adds a distinguishing behavioral detail ('nothing new starts') that separates it from enable_automation and other sibling tools. The purpose is unambiguous and easily distinguishable.

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 usage by stating the action, but it does not explicitly mention alternatives or when-not-to-use conditions. The sibling list includes enable_automation, and the opposite semantics are clear, but there is no direct guidance like 'Use this to stop an automation; to start one, use enable_automation.' Thus, usage 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 only declare it is a non-read-only, non-destructive, non-open-world write. The description goes beyond that with real behavioral detail: runs and versions are not copied, post-bound copies retain their post, and next-post flows re-wait. It does not, however, state where the resulting draft surfaces or what identifier comes back.

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 core action, then a dense clause covering the three non-obvious copy behaviors. No filler and no repetition of the title.

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 should ideally say what the copy returns (e.g., the new draft's id) for a follow-up enable/publish call. Everything else an agent needs — what is copied, what is not, post binding behavior — 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 coverage is 67% and the description adds only the optionality of the name ('optionally with a new name'), which the schema already covers with its default hint. The workspaceId guidance lives entirely in the schema, so the description neither compensates nor detracts; 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 precise verb+resource ('Copy an automation as a new draft') and immediately scopes what makes it distinct from create_automation/update_automation by specifying what is carried over (triggers and settings). An agent can distinguish it from its 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?

The description conveys the semantics of a copy but never states when to prefer this over create_automation or list_automation_templates. Usage is implied by the copy semantics ('same triggers and settings, optionally with a new name') rather than explicitly routed.

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 destructiveHint=true and readOnlyHint=false, but the description adds substantial behavioral context: it explains the real-world effect ('messages start going to real people'), specific error codes and their causes, and uniqueness constraints. Far exceeds what annotations provide.

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 key effect in bold, then detailed constraints. Somewhat verbose but well-structured; every sentence provides actionable information. Slightly dense but not wasteful.

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?

Comprehensive for a mutation tool: covers safety, real-world impact, error conditions, and constraints. No output schema needed as errors are explained. Missing nothing critical 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 coverage is 50%: the id parameter is undocumented in the schema, but the description implies it identifies the automation. workspaceId is described in the schema. Description adds no extra parameter detail, but given the schema coverage, baseline 3 is exceeded by context. Not quite 5 due to lack of parameter-specific hints beyond implicit 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?

States a specific verb+resource: 'Turn an automation live' with precise semantics, distinguishing it from disable_automation and from create_automation/update_automation.

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 warns to confirm with the person first, and enumerates the exact conditions under which enabling a second automation is refused (next_post_taken, automation_catch_all_taken, reconsent_required, feature_in_review). Provides clear context for when to use and when it will fail.

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?

Goes well beyond the readOnly/openWorld annotations: discloses a seven-day cache, a per-person 60-second server-path throttle with no daily cap, the two execution paths (extension vs server) and how the 'via' field reports which answered, and named error codes with retryAfterSeconds. This is exactly the behavioral context annotations cannot carry.

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 core purpose and scope in the first sentence, then error/rate-limit handling. It is long and dense, but nearly every sentence targets a distinct failure mode or routing decision, so little is wasted.

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 compensates by describing the return shape (found[].from is seed or L1:<seed>), the 'via' field, and every notable error path including retryAfterSeconds and the enableUrl. Nothing an agent needs to call or recover from 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?

Schema coverage is 100%, so both parameters are already documented. The description restates the 'up to 10 seeds' limit and reinforces the workspaceId omission rule, but adds little syntactic meaning beyond 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 (expands), resource (seed keywords), mechanism (Naver autocomplete), and scope constraint (Naver Blog only), then disambiguates from the sibling by noting these are 'candidates to measure with research_naver_keywords, not proven keywords.' An agent can tell it apart from research_naver_keywords 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?

Names the alternative tool and the condition that selects it, and gives explicit fallback routing: when naver_autocomplete_unavailable, 'pass your own keyword list to research_naver_keywords instead.' It also states the enablement precondition for the 403 case, covering when-not-to-call.

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 the tool is a destructive, non-read-only open-world operation; the description adds substantial context beyond that: the pending-until-accepted semantics, the 'already' return, the absence of an unfollow, and the full bridge.nextStep protocol including the retry limit of two.

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?

Dense but front-loaded: the primary action and the mutual distinction come first, followed by error-handling detail. Every sentence carries operational value, though the bridge passage is long and could be tightened.

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 compensates by explaining the observable return states ('already') and the bridge error protocol, including exact next-step handling and retry guidance. An agent has everything needed to invoke and recover 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 coverage is 100%, so the baseline is 3, but the description adds real meaning about `mutual` (it sends a request the other blog must accept, otherwise immediate plain-neighbor) that goes beyond the schema's one-line description. It does not add anything for message/accountId/workspaceId.

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 (Follow) and resource (an account/blog on the channel), scoped to Naver Blog. It is immediately distinguishable from ambiguous siblings like like, reply, or send_dm.

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?

Clearly explains the two modes (mutual:true vs plain neighbor), the already-a-neighbor outcome, and that there is no unfollow. It does not, however, name any alternative sibling tools or broader when-not-to-use conditions, 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.

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), yet the description adds real behavioral detail absent from structured fields: pastComments is the latest send_to_past_comments job with its progress or null, and templateParams appears only while the flow retains its template shape. With no output schema, these return-shape semantics carry genuine weight.

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 core payload (document contents) before secondary concerns like version consumption and pastComments. It is dense but every clause adds a distinct fact; no filler sentences.

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 must describe the return shape, and it does: document fields, version, templateParams conditionality, and pastComments nullability. Missing are any hints about failure modes or size/limits, but for a single-resource read tool this is close to 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 coverage is 100%, so the baseline is 3. The description goes beyond it by explaining what the version parameter selects (an older saved version's document) and pointing to its source list_automation_versions, adding intent the schema's 'saved version number' phrasing does not fully convey.

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 ('One automation as a document') and immediately enumerates what the document contains: triggers, nodes, start. It also names the siblings it relates to (put_automation, update_automation, list_automation_versions), so an agent can distinguish it from list_automations 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?

Explains the version-selection path ('Pass version to read an older saved version's document instead (list_automation_versions)') and why the returned version matters to put_automation/update_automation. It stops short of an explicit when-to-use-this-vs-list_automations statement, but the routing context is clear.

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 destructiveHint=false, so the description does not need to repeat that it's a safe read. It adds valuable behavioral context: the follow relationship data is Instagram-only and only available for contacts who have messaged, plus the note that follower lists are not available on any channel. This goes beyond the structured hints and helps the agent set 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?

The description is two sentences and avoids padding. The first sentence front-loads the core purpose ('One contact:') and immediately lists the output fields, making it easy to scan. The second sentence clarifies a key limitation. It is concise and efficient, though a more explicit action verb like 'Retrieves a single contact by ID' would strengthen it further.

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 must convey return semantics, and it does by itemizing the fields. It also highlights the Instagram-only caveat and the lack of follower lists, which is important context. Given the tool's simplicity (read-only, one required parameter) and the annotations covering safety, the description is largely complete. It could mention what happens if the contact does not exist or the meaning of 'refresh', but those are minor.

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 input schema covers refresh and workspaceId with descriptions, so across 3 parameters, coverage is 67% (above 50%), giving a baseline of 3. The description adds no parameter-specific meaning; it does not explain what 'refresh' does or when workspaceId is needed beyond what the schema already says. Thus the description neither compensates for gaps nor adds value, so a 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 states the tool retrieves a single contact and enumerates the exact fields returned (name, username, follow relationships, follower count, tags, opt-out, messaging window close). It also distinguishes itself from listing tools by explicitly noting that follower lists do not exist on any channel, making it clear this is the only way to get such data. This is a specific verb+resource with clear scope.

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 provides no guidance on when to use this tool versus alternatives like list_conversations or list_mentions. The only hint is 'Follower lists do not exist on any channel; this is the closest thing,' which implies it's the way to get follow status but does not explicitly say 'use this when you need a single contact's profile' or 'don't use this for bulk contact listing.' No exclusions or alternatives are named.

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 destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that: argument-count-dependent modes (list-all vs single full answer) and the shape of each answer (steps, links, and a public URL). It does not address rate limits, error responses, or auth, keeping it 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?

Front-loaded with purpose before the invocation mechanics, and every clause carries information. It runs long as a single dense multi-clause sentence, which slightly reduces scannability, 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, so the description correctly carries the return-value burden by explaining that each answer contains steps, links, and a shareable URL. Combined with the mode selection and empty-argument behavior, an agent has everything needed to call and use the tool 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 100%, so the baseline is 3, but the description goes further by tying parameters to intent: the error code supplied by an Uplika response, or a short question in any language, and it explicitly tells the agent to omit workspaceId when already decided rather than re-ask the person. That usage-level meaning exceeds the schema text.

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 (look up) and resource (Uplika troubleshooting answers) and opens with the exact problem it solves: why something did not work and what can be done about it. This is clearly distinguishable from siblings like diagnose_naver_blog or get_insights, and an agent can route to it 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?

Explicitly names the triggering situations (a failed call, an automation that did not react, a DM that did not arrive, the person asking why something happened) and maps each argument mode to a scenario: code for an error code, query for a natural-language question, id for one full answer, no args to list everything. The when-to-use is concrete and there is little left 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 it as a safe read operation, but the description adds substantial context: null values mean unreported metrics, not zero; bridge responses require specific next steps; and retries are capped at two. This is rich behavioral detail beyond the structured 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?

The description is front-loaded with the core purpose and then gives necessary null and bridge handling details. It is somewhat long, but the additional sentences carry operational value and no obvious 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 output schema, the description carries most of the return-value burden. It lists the returned metrics, explains null semantics, and details bridge failure modes and retry behavior. It could still specify the general response shape more fully, but it is largely complete for this 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%, so the schema already fully documents the id and workspaceId parameters. The description adds only 'one publish' as context and does not extend parameter meaning beyond what the schema provides, 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 clearly states it returns engagement metrics for one publish, naming the specific metrics: views, likes, replies, reposts, quotes and shares. It does not explicitly distinguish itself from siblings like get_post or list_posts, so it is clear but lacks sibling differentiation.

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 'for one publish' implies the usage context, but there is no explicit guidance on when to choose this tool over alternatives such as get_post or list_posts. The bridge instructions address error handling rather than 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?

Annotations already declare read-only, non-destructive, non-open-world behavior, and the description adds substantial context beyond them: newest-first ordering, the meaning of an empty list, and a concrete failure mode (403 with enableUrl) plus retry policy. It surfaces an operational constraint the agent could not derive from the 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?

Four front-loaded sentences with no filler: payload, interpretation, empty case, then error handling. Each sentence carries distinct, actionable information and nothing is repeated from the schema.

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 carries the return-shape burden and does so fully (per-day points, ordering, three metrics), plus edge cases and error handling. An agent has everything needed to call it correctly and react to failures.

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 the schema already documents all three parameters including defaults and the workspaceId conditional. The description adds no parameter-level syntax or format detail beyond what the schema states, 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 names a specific verb and resource ('the measurement history of one keyword') and specifies the grain, ordering, and payload ('one point per day it was actually measured, newest first, with search volume, document count and posts per month'). This cleanly separates it from research_naver_keywords, expand_naver_keywords and list_naver_keyword_reports.

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 runtime guidance for the disabled-tool case (403 research_tool_disabled with enableUrl, tell them once, do not call again until re-enabled) and explains the empty-list meaning. What it lacks is a direct statement of when to prefer this over the sibling research_naver_keywords call, though the 'history' framing implies it.

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 readOnly/destructive/openWorld; the description goes well beyond them by disclosing the disconnected-account state (connectionId null, accountHandle set), the exact 409 account_disconnected failure on edit/delete/retry, id stability, and the full bridge nextStep protocol (run_wake / ask_user_login / ask_user_update) with a retry cap.

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 return semantics and the sibling comparison before the dense edge-case material. The bridge paragraph is lengthy with several nested conditions, but each clause governs a distinct agent action (which field to read, what to say, whether to retry).

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 carries the return-shape burden and does so for the salient cases (per-target status, failure reason, bridge object). It leaves other response fields, such as media or account metadata, unspecified, but covers everything needed to call and interpret the tool 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 100%, so both parameters are already documented, including that id accepts a publish id, channel id, or link. The description adds no format or edge-case detail beyond what the schema states, 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 (retrieve one publish/post) and immediately clarifies the scope: per-target status plus the reason any target failed. It explicitly distinguishes itself from the sibling open_post, so an agent can route correctly without opening 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?

Names the alternative (open_post) and the condition that selects it ('For a post link'). It also gives retry guidance (do not retry more than twice) and the bridge.nextStep branch conditions, which is genuine when-to-act guidance. It does not, however, contrast with list_posts for multi-post retrieval.

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 establish readOnly/non-destructive, and the description adds real behavioral context beyond them: the not_supported behavior for other channels, that values are per-account and drift when the person edits TikTok settings, and that privacyLevel has no default so this call is the source of that value.

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 dense sentences that are front-loaded with the scope restriction, then the return contents, then the pre-publish requirement and the privacyLevel dependency. 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?

With no output schema, the description carries the burden of describing return fields (nickname, privacy levels, postability, video length limit) and does so, plus it explains the one cross-field dependency (privacyLevel required, no default). Nothing needed for correct invocation 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 coverage is 100%, so the baseline is 3, but the description adds rationale the schema only implies – that these values are per-account (justifying required accountId) and that workspaceId should be omitted rather than re-asked when already decided. It stops short of adding format/syntax detail beyond 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?

States a specific resource (TikTok creator publish settings) and a clear verb (get), and explicitly scopes itself as TikTok-only, which distinguishes it from the broad publish/publish_now siblings. An agent can tell what it returns 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 explicit when-to-use ('call it before every TikTok publish'), explicit when-not ('do not call it for any other channel'), and even pre-empts a wrong reaction to the not_supported response ('which is not an error to work around'). This is exactly the routing guidance an agent needs.

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 this read-only, and the description adds meaningful behavioral context: it reports live platform usage rather than static limits, and it describes an additional account-level rate cap relevant to interpreting publish failures. This goes beyond the annotations without contradicting them.

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 no filler. The core purpose comes first, followed by usage timing and a key differentiation from related tools.

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 tool with optional parameters, the description covers purpose, timing, and a subtle behavioral caveat about rate limiting. The lack of an output schema is partly mitigated by the description's clear framing of what the quota represents.

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 input schema already documents both optional parameters fully, with 100% schema description coverage. The description adds no parameter-level meaning, but it also doesn't need to since the schema carries that burden.

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 resource (24 hour publishing allowance) and what it reports (usage for posts, replies, deletes). It distinguishes itself from list_platforms and publish, making the tool's role 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?

Explicitly tells the agent to check this before a burst of publishing, and warns that publish can return rate_limited even when the platform allowance has room. It also names list_platforms as the source of static limits, not this tool.

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 and destructiveHint=false, and the description adds value by explaining the operation is reversible ('show it again with hide: false'). This clarifies the non-destructive nature without contradicting 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?

One efficient sentence covers the action, the toggle behavior, and the parameter provenance. Every clause earns its place, and the core verb is 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?

For a simple two-required-parameter tool with full schema coverage and no output schema, the description provides enough context to call it correctly. The only notable omission is guidance on when to choose this over the similar delete_reply 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%, and the description mostly repeats what the schema already says: replyId comes from list_replies and postId is the publish it belongs to. It adds minimal new meaning beyond the structured parameter descriptions.

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 uses a specific verb and resource: 'Hide a reply on the channel, or show it again'. It clearly distinguishes this from deletion by emphasizing reversibility, and the 'hide: false' clause makes the toggle behavior explicit.

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 clear context for when to use the tool: to hide or unhide a reply, and it tells the agent where the replyId comes from ('list_replies') and that postId is the parent publish. However, it does not explicitly name sibling alternatives like delete_reply or state when hiding is preferable to deletion.

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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: only 'active' accounts can be published to, an empty list means no connected channel, and the user should be sent to the connection dashboard. No contradiction with annotations exists.

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?

Six short sentences, each earning its place: output fields, publish routing, active-status rule, unnamed-channel behavior, empty-list handling, and a fallback URL. The key instruction is front-loaded and 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?

Even without an output schema, the description explains the item fields and the practical consequences of the result: which accounts publish, what to do when no channel is named, and what an empty list means. The only omitted detail, workspaceId semantics, is already fully covered by the input schema, so nothing essential is missing for a low-complexity list 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%, so the workspaceId parameter is fully documented in the input schema itself. The tool description adds no extra parameter-level meaning, so the baseline score 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 clearly identifies the resource ('connected social accounts') and the kind of data returned (id, platform, handle, status). It also ties the tool to the publish workflow ('accountIds you pass to publish are these ids'), but it does not explicitly name sibling tools like list_platforms or select_channels to differentiate 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?

It gives an explicit trigger: 'Call this before publishing anything,' and explains how to use the result: pass accountIds to publish, target every active account when no channel is named, and redirect to the dashboard when the list is empty. It lacks explicit when-not-to-use guidance or named alternatives, so it stops just 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 readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety is covered. The description adds substantial domain context beyond that: the meaning of each terminal and blocked status, that blocked_ai_quota resets at 00:00 UTC, and that AI failure reasons appear in the log as classify_failed or ai_failed. It does not disclose pagination behavior for the limit/before parameters.

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 a single clear sentence stating what is returned, followed by the status enumeration. The long parenthetical list is dense but earns its place because no output schema exists to document these values elsewhere; minor sprawl keeps it from a 5.

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 usefully covers return semantics (statuses and step log), and annotations cover the safety profile. However, the undocumented limit/before pagination parameters and the required id parameter leave an agent without guidance on result size or how to page through runs.

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 25% (only workspaceId is documented). The description explains status values, which are output semantics rather than parameters, and says nothing about id, limit, or before (pagination). With four parameters and a large coverage gap, the description fails to compensate.

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 with scope ('Runs of one automation') and names the two things returned ('status and a step log'). It is clearly distinguishable from list_automations, get_automation, and list_automation_versions 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?

Usage is implied: you need one automation's id to retrieve its run history, and the status list hints at debugging why a run stopped. But there is no explicit when-to-use statement, no comparison to get_automation or list_automation_versions, and no prerequisites (e.g., required permissions).

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 a safe read (readOnlyHint, non-destructive). The description adds field-level return context and a conditional note that templateParams appears only when the flow still has its template shape. It doesn't cover pagination or volume limits, but the added behavioral detail is meaningful.

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 dense sentences: return content, filters, then alternative tool. No wasted words and the key information is 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?

For a read-only list tool with no output schema, the description tells the agent what is returned and how to filter, plus the sibling for detail. Missing only pagination/ordering behavior, which is minor.

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 the schema already documents each parameter with descriptions and an enum. The description maps the filters to intent and hints at availability of templateParams, adding marginal value.

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 specific verb (list) plus resource (automations) and enumerates the returned fields: name, channel, live/draft, triggers, run count, templateParams. This clearly distinguishes it from get_automation, which reads a single flow's document.

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 alternative (get_automation) and its purpose, and specifies the three filter dimensions (accountId, status, templateId). The routing rule is clear.

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 destructiveHint=false, so safety is covered; the description goes further by disclosing response content (each template's channels, the renamedFrom field, the ai_comment_reply alias). That is meaningful behavioral context beyond the structured fields, though return shape/pagination is still unstated.

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 purpose and usage cue are front-loaded in the first two sentences, but the remainder sprawls into detailed reference material about specific templates and aliases without structure. This detail is useful but not tightly organized, and some sentences would be better placed in per-template documentation.

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 carries the return-value burden and does explain what the answer contains (channels per template, params, renamedFrom) and how to act on it. It is close to complete for a low-complexity, one-optional-param list 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% and the single optional workspaceId is fully documented in the schema, including its conditional requirement. The description never mentions the parameter, so it adds no semantics beyond the schema — the baseline 3 for high coverage 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 opening line states a specific resource (ready-made automation templates) and what it returns (the params each one takes), so the verb+object is clear. It does not explicitly distinguish itself from the sibling list_automations (which lists configured automations rather than templates), leaving a small ambiguity an agent must resolve from context.

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?

"Read this before create_automation" is an explicit, actionable when-to-use cue tied to a named sibling. It lacks any when-not-to-use note or a direct contrast with list_automations, so it falls short of full alternative routing.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds genuine context that versions are produced by put/update operations, but says nothing about ordering, pagination, or return shape.

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, front-loaded with what is listed and followed by the routing hint. No filler and every clause carries 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?

For a read-only listing tool with no output schema and only two parameters, the description covers what it returns, how versions arise, and how to fetch one. Return format details are the only meaningful 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?

Schema coverage is 50%; workspaceId is well described in the schema, while id is undocumented in both places. The description adds no parameter meaning of its own (the 'version' it mentions belongs to get_automation), so it neither compensates for the gap nor obscures it.

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 ('saved versions of one automation') and adds the salient mechanism that each put_automation/update_automation creates a version. It references get_automation to distinguish reading a single version, but does not explicitly differentiate itself from list_automation_runs, the closest 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?

Routes the agent to get_automation plus a version argument when a single version is wanted, which is clear alternative guidance. It lacks an explicit when-not-to-use statement relative to list_automations/list_automation_runs, but the context is unambiguous.

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 destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: each item indicates whether the 24-hour window is open and how much time remains, which is beyond the schema. However, it does not disclose pagination, ordering, or whether the search parameter filters by contact name or message content.

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 compact and front-loaded with the core concept ('The inbox'), then explains the window indicator and the two key filters. Every sentence earns its place, though the parameter explanations could be slightly more structured.

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 read-only list tool with no output schema, the description covers the main purpose and the two most important filters. However, with 7 parameters and no output schema, an agent would benefit from knowing what fields each conversation item contains, how pagination works, and what the search parameter matches. The description is adequate but not 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 only 14%, so the description must compensate. It explains the meaning of 'state' and 'kind' enums, which is helpful, but the other five parameters (limit, search, unread, accountId, workspaceId) are left undocumented in both the schema and description. The workspaceId parameter has a schema description, but the rest rely on naming conventions.

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 clearly states the tool lists inbox conversations across Instagram DMs, Facebook DMs, and Threads mentions, and distinguishes it from the sibling list_mentions by covering both DM and mention kinds. The verb 'list' plus the resource 'inbox conversations' is specific and 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?

The description explains the default state ('open') and the kind filter ('dm or mention'), giving an agent enough context to know when to use this tool. It does not explicitly name alternatives or exclusions, but the sibling list_mentions is implicitly differentiated by the mention coverage. No explicit when-not-to-use guidance is 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 the safe read profile (readOnlyHint, destructiveHint=false), so the bar is lower. The description still adds real behavioral value: webhook delivery, the dependency on a dedicated permission, empty-list semantics, and the notice codes (feature_in_review, reconsent_required) an agent must interpret.

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 dense sentences that lead with what the tool returns before detailing permissions and alternatives. Parentheticals are compact, though the error-code aside adds some reading load.

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 read-only list tool with no output schema, the description supplies the permission gating, the empty-result condition, and the correct next-step sibling. The only real gap is that the three input parameters are left entirely to the schema.

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% — unread and accountId carry no description in either place — and the description says nothing about any of the three parameters. With low coverage the description is expected to compensate, and it does not.

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 ('Threads posts that mention the connected account') and immediately positions it against a sibling by noting it is the same shape as list_conversations with kind mention. An agent can tell exactly what this returns without opening another 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?

Names the follow-up tool (send_dm) and the diagnostic sibling (list_platforms) explicitly, and explains the permission condition that makes the list empty. It stops short of a full when-to-use/when-not statement, but the routing context is clear.

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 destructiveHint=false, and the description adds substantial behavior beyond them: the extension version gate, the extension_outdated error, and the full bridge.nextStep protocol (run_wake / ask_user_login / ask_user_update) with what to tell the person in each case. That is rich operational context the agent cannot infer from 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?

Front-loads the scope and returned fields, then the handoff, then error handling. Every sentence carries information, though the bridge/error-branching section is dense and slightly long for a single description block.

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 compensates by naming the returned fields and ordering, and it covers prerequisites, error codes, and recovery steps. An agent has everything needed to call it and handle the common failure paths.

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 both parameters are already documented in the schema. The description adds little parameter-level meaning beyond what the schema states, so the baseline 3 for fully-covered schemas 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 ('Lists the drafts (temp-saved posts) sitting in the blog's draft box') and immediately scopes it to 'Naver Blog only', which cleanly separates it from siblings like list_posts and list_channel_posts. It even enumerates the returned fields and sort order.

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 explicit routing guidance: 'Pass a logNo from here to publish_naver_draft' names the downstream alternative and the handoff condition. It also states prerequisites (extension 0.7.2+), the failure mode (extension_outdated), and an explicit retry policy ('Do not retry more than twice').

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 cover the read-only/non-destructive profile, and the description goes well beyond them: newest-first ordering, the exact shape of returned data, and a specific failure mode (403 research_tool_disabled with enableUrl) plus how to behave on it. This is genuine behavioral context an agent cannot get from 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?

Five dense clauses, front-loaded with the core action and return contents, then the ownership caveat and the error-handling rule. No filler; each sentence carries operational 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?

With no output schema, the description compensates by describing the return contents, and it closes the loop on the one meaningful failure path. Nothing an agent needs to call this correctly is absent.

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 baseline is 3, but the description adds interpretive value by clarifying that reports belong to the person rather than a workspace, which informs how the optional workspaceId should be treated. It does not, however, explain the limit parameter beyond 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?

States a specific verb and resource ('Lists the person's saved keyword research') and immediately enumerates the returned fields (when, typed text, first set's main/sub keywords, every set with its prompt). This clearly separates it from siblings like get_naver_keyword_history and research_naver_keywords.

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 clear context (it surfaces saved research originating from research_naver_keywords or the dashboard, ordered newest first) and explicit handling for the disabled-tool case with a concrete retry instruction. It does not, however, explicitly compare against the nearest alternative, get_naver_keyword_history.

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 mark readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context: explains the meaning of each status value (live, beta, bridge, soon), how charCount should be used, and that options is a JSON Schema for publish parameters. This goes far beyond the annotations and helps the agent interpret the output correctly.

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 bit long, but it is well-organized: it opens with the purpose, then details status, charCount, and options sequentially. Each sentence contributes meaning; it is not bloated. Front-loaded with the core purpose, so a 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?

For a read-only tool with no output schema, the description covers what the tool returns (channels and their rules), how to interpret status, charCount, and options. It lacks explicit notes on pagination or error handling, but these are minor given the tool's simplicity. Overall it is sufficiently complete for an agent to use it 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?

The only parameter workspaceId is fully documented in the schema (coverage 100%), with clear guidance on when it is needed and when to omit it. The description does not add parameter-specific information, 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?

The description clearly states the tool lists every channel and its rules (character limit, media requirements, state). It specifically says 'Every channel and its rules' and lists the fields. It distinguishes itself from siblings by focusing on platform limit details, which is unique among list_accounts, get_quota, etc.

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 explicit when-to-use guidance: 'Read this instead of guessing a platform's limits' and advises checking charCount before calling publish to avoid failures. It does not mention alternatives directly but clearly indicates the appropriate context. Slight gap in naming specific alternatives, so 4.

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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: inclusion of scheduled/draft posts, paging semantics (hasMore, nextBefore, limit cap of 100), ordering ('newest first'), and the exclusion of pre-existing channel posts. This is rich, non-obvious 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?

The description is a dense but well-ordered paragraph: scope, default behavior, paging, usage example, exclusions, and sibling alternative. Every sentence carries new information and is front-loaded with the core purpose. No fluff 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?

For a read-only list tool with no output schema, the description covers what is returned, ordering, pagination, filtering, defaults, and the boundary vs. list_channel_posts. With rich parameter schemas and annotations, nothing an agent needs to invoke it correctly 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%, so the baseline is 3. The description reinforces the paging parameter interaction ('pass the returned nextBefore as before') and gives a filter example, but it largely restates what the schema already documents (limit default, sort behavior, since/until semantics). It adds marginal value over the schema, so 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 states a specific verb and resource ('list posts published through us'), enumerates what the list includes (recent publishes, scheduled, drafts), and explicitly contrasts with list_channel_posts. An agent can immediately distinguish this from the sibling tool without reading schemas.

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 direct when-to-use guidance: 'Posts that already existed on the channel are not here. Use list_channel_posts for those.' It also provides a concrete use-case pattern ('To answer "what is scheduled this week", pass status scheduled with since and until and sort scheduled.'), which fully routes the agent to the right tool and parameter combination.

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?

Well beyond the readOnly/openWorld/non-destructive annotations, it discloses that results may be truncated via a `truncated` flag, that the count can legitimately differ from get_insights, and it decodes the `bridge` error payload into concrete nextStep actions (run_wake, ask_user_login, ask_user_update) with a two-retry cap. This is unusually rich failure-mode disclosure.

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 in the first sentence, followed by caveats and then the bridge handling in ascending order of operational rarity. The bridge paragraph is dense, but every clause maps to a distinct action an agent must take.

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 steps in and explains the two non-obvious response aspects an agent will encounter: `truncated` and the `bridge` object. Combined with complete schema coverage and safety annotations, nothing needed to call this correctly 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%, so both `id` (publish id, channel id, or post link) and `workspaceId` (only needed for multi-account, error reports ids) are already fully documented in the schema. The description adds no parameter meaning, which is fine but earns only the 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?

The first sentence names the resource and its scope precisely: the whole reply thread under a post, nested replies included. It distinguishes itself from the replies metric in get_insights, though it does not route to a true selection alternative among siblings like list_mentions or read_conversation.

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 by the resource (fetch replies to a given post) and the description gives operational guidance for failures, but it never states when to prefer this tool over siblings or any precondition beyond the id. The guidance offered is retry behavior rather than tool-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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description reveals an internal verification step: 'We check the file really landed before marking it ready.' This adds meaningful behavior context about validation and state transition that the annotations alone do not convey.

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, purposeful sentences with no filler. The most important information (when to call) is front-loaded, followed by the verification behavior and the downstream requirement. Every sentence earns its place.

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 workflow-step tool with no output schema, the description covers the essential context: position in the flow, trigger condition, internal check, and downstream constraint. It does not explicitly describe the return value or failure behavior, but enough context is present for an agent to invoke it correctly in the media-attachment workflow.

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 the baseline is 3. The tool description itself does not add additional meaning to the parameters beyond what the schema already states, such as id coming from media_presign and workspaceId's conditional use. No special compensation is needed or provided.

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 ('finish a media upload'), identifies it as 'Step 2 of attaching an image or video', and clarifies it must be called after the upload finishes. This clearly differentiates it from sibling tools like media_presign, media_upload_link, and media_upload_status by workflow position.

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 explicit timing context: 'Call it after the upload finishes.' It also gives a downstream rule ('Only a ready media id can be passed to publish') and the schema adds workspaceId guidance. It does not explicitly name alternatives or when not to use it, so it falls just 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?

With annotations covering the safety profile (readOnly=false, destructive=false, openWorld=true), the description still adds substantial behavior: the server downloads and re-hosts the file, format is validated from bytes not headers, the returned media id is meant to be passed to publish, and each channel applies its own format check at publish 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?

Front-loaded with the action and the payoff ('attach... we give you a media id you can pass to publish'), then constraints, then formats, then the altText cue. No filler sentences; every clause carries actionable 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?

No output schema exists, yet the description explains what comes back (a media id for publish) and how formats/channels interact. For a 4-param, one-required tool with a single remote input, nothing an agent needs to invoke it correctly 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 coverage is 100%, so the baseline is 3. The description adds real value beyond it: url must be a direct file URL ending in the file itself, accepted MIME list, and the cue that altText should be written whenever the image is visible. It does not elaborate on aiGenerated or workspaceId beyond 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?

States a precise verb+resource: attach already-hosted media by URL, with the mechanism spelled out (we download it, copy it into storage, return a media id). It clearly positions itself against the upload-style siblings (media_presign/media_upload_link) by saying 'no upload needed'.

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 strong usage conditions and exclusions: https only, Google Drive/Dropbox share links return HTML and won't work, use a direct file URL. It does not name a specific sibling tool to use instead when the URL is a local/private asset, so it stops short of explicit alternative routing.

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 are minimal (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description carries the rest: the uploadUrl is one-time, a follow-up call to media_complete is required, and the returned mediaExpiresAt means an unpublished id vanishes and later publish calls fail with media_expired. Per-type MIME lists, byte caps (20MB/8GB/25MB), duration, resolution and aspect-ratio limits are all disclosed.

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-loads the gating condition and alternative routing before any format detail, which is the right order for the agent's decision. It is long, but nearly every sentence carries a constraint or a downstream step; only the 'Any image pixel width is fine' remark is close to 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, so the description takes on the burden of describing the return payload (media id, uploadUrl, mediaExpiresAt) and the full multi-step lifecycle through media_complete. Given the tool's complexity and the file-type-dependent constraints, an agent has everything it needs to call it correctly in one pass.

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 already 88%, so the baseline is 3. The description goes further by tying parameter values to constraints the schema only names: which content types are valid images vs video vs documents, that documents are for DM automations (deliver.mediaId) and not posts, and that contentType must be reused when PUTting bytes. It does not, however, add anything for fileName or the width/height fields beyond 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?

States a specific verb and resource (start/direct media upload) and immediately distinguishes itself from the three sibling tools in the same family (media_upload_link, media_from_url, media_complete). It also spells out the artifact produced (a media id and a one-time uploadUrl), so the agent knows exactly what it gets.

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?

Explicit when-to-use and when-NOT-to-use: 'Use this only when you can HTTP PUT the file bytes yourself... Web and mobile chat clients cannot, so do not call it there.' It names both alternatives and the condition that routes to each (on-device file -> media_upload_link, public https URL -> media_from_url). Nothing is left 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?

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), the description discloses the asynchronous lifecycle: the link is short-lived, the agent must hand it to the person and wait, poll media_upload_status with the token, and must not publish before status is ready. This is meaningful behavioral context. It stops short of covering auth requirements or failure modes, so a 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?

Purpose and return value are front-loaded, followed by the required workflow, then the alternative and edge case. It is denser and longer than a single-sentence ideal, but every clause carries distinct operational information (wait, poll, do-not-publish, document exception).

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 carries the return burden and does so ('Returns a short-lived link'), and it supplies the full downstream sequence needed to use the result correctly. For a 2-param tool with 100% schema coverage, nothing needed to call it correctly 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% for both parameters, so the schema already documents note and workspaceId, including the 'leave it out if already decided' guidance. The description adds no parameter-level detail of its own, 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 states a specific action and artifact ('Ask the person to upload files from their own device. Returns a short-lived link'), and explicitly contrasts itself with media_from_url. An agent can distinguish it from siblings like media_presign or media_complete 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?

It gives an explicit when-to-use condition ('when the file is on their computer or phone') and names the alternative tool with the condition that selects it ('use media_from_url when the file already has a public https address'). It also gives a when-not constraint for the document case (PDF/HWP cannot ride a post).

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?

With annotations already marking it read-only and non-destructive, the description adds significant behavior: status values, pagination limit of 20 with offset, previewId mapping for image blocks, and duplicateOf semantics. This goes well beyond the annotations and fully discloses the tool's 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?

The description is compact yet information-dense, front-loaded with the core purpose and then efficiently explaining return values, pagination, and duplicate handling. No sentence is wasted; every clause adds operational value.

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?

Without an output schema, the description fully specifies what the tool returns and how to use it (statuses, media IDs, previewIds, offset, duplicateOf). It also explains the workspaceId nuance and how to proceed with publish. An agent has everything needed to call it 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?

The schema covers all parameters at 100%, so the baseline is 3. However, the description adds extra semantics: it clarifies token origin, explains the 20-image limit and offset usage, and reinforces workspaceId guidance. This adds value beyond the schema, meriting a 4.

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 clearly states the tool checks upload status and returns waiting, ready, or expired plus all media IDs. It also explains how to use those IDs with publish, making the purpose unambiguous. It distinguishes itself from sibling upload/publish tools by focusing on status retrieval.

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 implies usage context (after media_upload_link, before publish) and explains how to chain with publish. It does not explicitly name alternatives or state when NOT to use it, but the context is clear enough for an agent to select it appropriately.

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 destructiveHint=false, and the description adds meaningful behavioral context beyond that: it explains the default layout transformation (#/## headings become quote headings, thin rules, photo placement), explicitly states 'Text never changes,' and clarifies that the server never chooses a form for the user. This enriches the agent's mental model of the tool's side-effect-free 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?

The description is long but dense and purposeful. It front-loads the core purpose, then explains the default layout behavior, the preview-then-publish workflow, and the alternative forms workflow. While it could be tightened into bullet points, every sentence contributes useful operational detail rather than 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?

Given five parameters, no output schema, and rich annotations, the description covers the key invocation semantics, the two main usage modes, and the return-shape difference (layouts[] vs one layout). It also describes what each preset layout result contains. It does not formally specify the output object, but it gives enough for an agent to call the tool and interpret 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 100%, so the baseline is 3, but the description adds value by tying parameters to the publishing workflow: content and mediaIds should be the same ones used for publish, workspaceId is optional once decided ('do not ask the person again'), and forms: 'all' returns layouts[] with name, usage note, and summary. These semantics go beyond the literal schema descriptions.

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 opens with 'Naver Blog only' and 'Shows how publish will lay the body out before anything goes out,' giving a specific verb, resource, and scope. It clearly distinguishes this preview tool from the sibling publish tool by framing it as the pre-publication layout check.

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 workflow guidance: 'Call this with the same content and mediaIds you will publish, show the person the result if they care about structure, then publish' or alternatively pass options.naver_blog.layout: 'as-is'. It also explains the forms branch ('To let the person choose a form, pass forms: all') and ends with 'The server never picks for you,' making the human-in-the-loop decision 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 cover the safety profile (readOnly, non-destructive, open world), yet the description adds real behavioral context: replies or metrics may come back null when the platform refuses that part, and the `bridge` object signals a Chrome/extension or auth problem with a defined remediation path. This is exactly the runtime nuance an agent cannot get from the 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?

Front-loads the scope sentence before the failure handling, and there is no filler. The bridge/retry passage is long and reads more like error-recovery procedure than tool description, but every clause is actionable and the retry cap is stated tightly.

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 carries the return-shape burden and does so: it enumerates the three payload sections, flags nullable fields, and explains the `bridge` object's meaning. Nothing needed to call or interpret the response 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%, so `id` and `workspaceId` are already fully documented in the schema, including accepted id formats and the 'do not ask again' guidance. The description adds no syntax or format detail beyond what the schema provides, 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 resource and the exact payload it returns ('the text, the whole reply thread, and its metrics') plus a concrete trigger ('when someone hands you a post link'). This implicitly contrasts with narrower siblings like get_post and list_replies, but neither is named, so the differentiation is inferential rather than explicit.

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 selection condition ('the right tool when someone hands you a post link') and then prescribes behavior for edge cases: interpret `bridge.nextStep`, branch on `run_wake` vs `ask_user_login`/`ask_user_update`, surface `bridge.userMessage`, and never retry more than twice. That is far beyond what most definitions offer.

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 flag it as a non-readonly, destructive, open-world write; the description adds the mechanism (extension loads the draft and presses publish, so manual Naver edits survive), the dedupe rule (a draft: externalId draft flips the same post record to published rather than creating a duplicate), the offline bridge object, and the wait:true timeout behavior. This is rich context well beyond 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?

Front-loaded with the core behavior and the key exclusion ('Do not send content') before the recovery detail. It is dense and long, but nearly every sentence carries actionable information; the bridge section is verbose where a compact mapping would do.

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, network-dependent write with no output schema, the description covers the success shape (202 with a target resolving to published), the deferred/offline shape, the dedupe outcome, and the user-facing recovery path. An agent has everything needed to call it and handle failure.

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 the baseline is 3, but the description adds the framing rule that category, tags and openType fall back to the draft unless explicitly passed, binding the override parameters into one behavioral contract. It largely echoes schema defaults, hence not a 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 with scope: publishes a Naver Blog draft exactly as it sits in the draft box, and explicitly says content is not sent. It also distinguishes itself from siblings by naming update_post and publish, so an agent can route without opening other schemas.

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 explicit when-not guidance ('Do not send content') and names the alternative path: to publish uplika's own copy of the text, use update_post on that post instead. It also enumerates the bridge failure modes and the exact recovery action for each (run_wake, ask_user_login, ask_user_update) with a retry cap of two.

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 destructiveHint annotation, the description discloses important asynchronous behavior: it returns while publishing unless wait: true is passed. It also surfaces a precondition for drafts and an error case for already-published posts, which are genuinely useful behavioral details not visible in 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?

Three sentences, each earning its place: the main action, the async behavior with wait option, and the draft/already-sent edge cases. The most important information is 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?

For a destructive, async tool with no output schema, the description covers the core action, waiting behavior, a prerequisite, and an error condition. It is nearly complete, though it relies on the reader knowing publish's semantics and does not describe the response shape beyond holding for the result.

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 the schema already explains id, wait, and workspaceId well. The description reinforces the wait behavior and draft requirement but does not add substantial new meaning beyond what the schema provides.

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: send a scheduled or draft post now, rather than waiting. It also distinguishes the tool from siblings by emphasizing the immediacy and the scheduled/draft scope, and references publish as a behavioral comparison.

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 clear context: use this when you want to send a scheduled or draft post immediately. It also provides a prerequisite (a draft needs at least one target account) and an exclusion (posts that already went out return post_not_editable), though it does not explicitly name alternative sibling tools.

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 destructiveHint=true; the description goes well beyond that by naming the specific refusal errors (automation_is_template, version_conflict), explaining the concurrency guarantee (a stale version will not overwrite a concurrent edit), noting that validation failures return paths, and warning that editing a live flow changes what goes out to people.

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-loads purpose and the update_automation alternative before diving into node/loop semantics, so the important routing decision survives skimming. It is dense and long, with a parenthetical node-type list and the wait/loop rule repeated from the doc field's schema description, which costs some efficiency.

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 tool whose doc parameter is a deeply nested object schema with no output schema, the description covers the failure modes an agent must anticipate, the versioning contract, and the structural rules the schema cannot express (loops must pass through a wait, button next: null semantics). What remains thin is the trigger/document construction detail, though the schema largely handles that.

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 50% schema coverage across six parameters, the description carries real weight: it explains version semantics (stale versions rejected), the meaning and risk of detachTemplate, and how doc semantics work (node types, wait-as-send-node, comment postId accepting a link). Some of the node-type and wait content duplicates enums already present in the schema, so it is not purely additive.

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 with its exact semantics: 'Edit an automation by replacing its whole document.' It further scopes which flows this applies to (flows no template covers or already edited on canvas), which cleanly separates it from create_automation and update_automation.

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?

Explicit routing: if get_automation shows templateParams, use update_automation instead; use detachTemplate only when the change cannot be expressed as template params. It also mandates the read-then-write workflow by requiring the version from get_automation, so the agent knows exactly when and how to invoke this.

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 destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail: it returns recent messages, contact fields, Instagram-only follow state, opt-out, and draft status, which goes beyond the annotations without contradicting them.

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 compact and front-loaded with the core outcome, then lists key returned fields and the draft-status nuance. Every sentence adds information, with no filler or repetition of the annotations.

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 simple read-only nature and no output schema, the description adequately outlines what the tool returns, including the Instagram-only condition and draft handling. It does not specify message ordering, pagination, or error behavior, but these are not critical for a basic single-conversation read.

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 50%: workspaceId is thoroughly described in the schema, while id has only a type and no description. The description does not explain the parameters, but id's role as the conversation identifier is clear from the tool name and required field, so the gap is minor.

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 clearly states that the tool returns a single conversation with recent messages and contact details, which matches the name and title. It does not explicitly differentiate from list_conversations or get_contact, but the singular focus on one conversation and its contents 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 guidance on when to use this tool versus siblings like list_conversations, get_contact, or list_mentions. The workspaceId parameter note gives invocation advice, but it does not help an agent choose this tool over 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 flag it as a non-read-only, destructive, open-world write; the description goes well beyond that by disclosing asynchronous completion ('returns before the reply is live'), the 10-second wait ceiling, and a full bridge-error playbook (run_wake, ask_user_login, ask_user_update) with what to tell the person. Nothing here contradicts the destructiveHint annotation, since it publishes content.

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: the core reply semantics and replyTo behavior come first, then async behavior, then the bridge error ladder. It is long, but each clause carries operational weight; only the bridge detail could be trimmed without losing meaning.

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 carries the return-value burden and does so: it explains the returned id, the bridge/bridge.nextStep field, and how to check final status via get_post. For a 6-parameter publishing tool with error-recovery needs, nothing essential 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 coverage is 83%, so the schema already documents id, wait, replyTo, secret and workspaceId; the description's parameter content (empty replyTo, wait:true) largely restates the schema rather than adding syntax or format detail. Baseline 3 is appropriate 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?

The first sentence states a specific verb+resource ('Reply to a post or to a reply') and immediately distinguishes the two modes via the replyTo parameter. It names and routes to siblings (list_replies, get_post, publish), so an agent can tell it apart from publish or send_dm without opening anything else.

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?

Explicit when-to-use for every branch: omit replyTo to reply to the post, pass a list_replies id to nest, pass wait:true to block, otherwise poll get_post with the returned id. It also gives a bounded retry policy ('Do not retry more than twice'), which is rare and genuinely 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?

Rich disclosure well beyond the annotations: seven-day cross-user caching, a time budget that yields partial:true with unmeasured[], a ten-minute dedupe window that returns an existing reportId, the 403 research_tool_disabled error with enableUrl, and the fact that each call persists a report. The description discloses side effects (report saving, cache writes) that readOnlyHint=true does not surface, but it does not assert the opposite of the annotation, so this is understatement rather than contradiction.

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 scope, function, and card outputs before the mechanics, and nearly every sentence carries operative detail (caching, budget, dedupe, 403 handling). It is a dense single block, however, and the prompt/draftPrompt/prompt-distinction sentences run together, making it harder to scan than it needs to be.

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?

Even with no output schema, the description explains what comes back (verdicts with reasons, sets with same-intent subs, prompt, draftPrompt), how partial results are signaled, and how failures and dedupe resolve. For a four-parameter tool with a time-budgeted, cached, error-prone backend, an agent has everything needed to call it 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 100%, so the schema already documents topic, seedText, workspaceId, and keywords in detail. The description reinforces a few things the schema says (topic flows into draftPrompt, workspaceId should not be re-asked) and adds the 1-60 keyword bound, but adds no formats or constraints beyond that. 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 specific verbs and resources: it measures Naver Blog keywords across three metrics, judges each into named verdicts (best, possible, hard, wall, hot, saturated, phantom), and groups them into post sets with main + sub keywords. The scope 'Naver Blog only' is clear. It never names or contrasts with the nearby expand_naver_keywords, get_naver_keyword_history, or list_naver_keyword_reports siblings, so differentiation is left 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?

Gives concrete usage context: Naver Blog only, up to 60 keywords, and explicit instructions for the 403 research_tool_disabled path (tell the person once, do not retry until enabled). The partial:true / unmeasured[] re-call guidance tells the agent exactly when to call again. It stops short of comparing against alternative keyword tools (expand_naver_keywords), so 'when not to use this' is only partially covered.

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 (destructive=true, openWorld=true) only flag risk; the description goes far beyond by enumerating concrete error codes and their meaning (429 naver_rate_limited, 400 naver_form_required, 409 naver_draft_unknown, 409 naver_reply_unknown, 409 duplicate_post, nothing_to_retry), noting that it replays the same payload, and warning that a failed Naver target may have left a post or draft in the editor. No contradiction with 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?

Purpose is front-loaded in the first sentence and every subsequent sentence carries actionable branching logic rather than filler. It is dense and long, but the length is justified by the number of distinct error states; a bulleted error-code list would have made it easier to scan.

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?

No output schema exists, and the description fully compensates by spelling out every return code, the retryAfterSeconds field, the prerequisite reads (get_post errorCode/retryable, list_naver_drafts, the blog comment), and the force escalation path. An agent has everything needed to call it 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 coverage is 100% and the schema already documents id, force, and workspaceId well, so the baseline is 3. The description nonetheless adds meaning by tying force to the specific error states and their required pre-checks, and by clarifying that workspaceId should not be re-asked — reinforcing how the parameters interact with the failure flow.

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 with scope: 'Retry the targets that failed on a publish. Targets that already went out are left alone.' It distinguishes itself from publish, publish_now, and publish_naver_draft by framing itself as a replay of a prior publish's failures, and it explicitly routes to publish when retryable is false.

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?

Explicit when/when-not and alternatives throughout: don't call again before retryAfterSeconds, call publish instead when retryable is false, check list_naver_drafts before force:true, check the blog comment before force:true on naver_reply_unknown, and read the conversation / show forms via naver_layout before choosing a Naver form.

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 cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds substantial behavioral context: duplicate folding, skipped channels with reasons and reconnect links, limits calculation, accountIds passing to publish, empty-candidate meaning, and Naver Blog bridge states with user messages.

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 dense but front-loads the core purpose and key instruction ('Call this before publish'). Every sentence carries useful guidance, though the long multi-clause sentences could be broken into clearer parts.

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 must explain return behavior. It covers candidates, accountIds, skipped, limits, and the Naver Blog bridge object, giving the agent enough to interpret most outcomes and handle edge cases.

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 the schema already documents both parameters. The description adds concrete examples for the array items and notes duplicate folding, but it largely repeats the schema's scope description and says nothing about workspaceId.

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: 'Pick which connected channels to post to.' Clearly distinguishes from sibling publish by positioning itself as the selection step before publishing.

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 to call it before publish and show the result to the person, explains how to use empty scope vs 'all' vs an array, and gives fallback instructions for empty results and Naver Blog accounts. It names the next tool (publish) and the conditions for each path.

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 and destructiveHint=true, so the description doesn't need to restate that. It adds valuable behavioral context: the 24-hour window, the public reply behavior on mention threads, and the 30-minute automation pause. It doesn't mention whether the message is irreversible or any rate limits, but the annotations cover the destructive nature. The description adds meaningful context beyond 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?

Four sentences, each carrying essential information: the core action, the critical time constraint, the mention-thread behavior, and the automation pause. No filler or repetition. The most important constraint (24-hour window) is 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?

For a mutation tool with no output schema, the description covers the key behavioral constraints (24-hour window, public reply on threads, automation pause) and parameter nuances (draftId, workspaceId). It doesn't describe the success/failure response format, but the error case for window_closed is mentioned. Given the tool's complexity and the annotations covering safety, this is nearly 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 80%, so the schema already documents most parameters. The description adds meaning for draftId ('AI draft that was waiting for approval') and workspaceId ('Only needed when the account has more than one — the error tells you the ids when it matters'). It doesn't add detail for text or mediaId, but the schema covers those adequately. The description compensates for the less obvious parameters.

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: 'Send a message in a conversation as the account.' It also distinguishes itself from siblings by clarifying that on a mention thread it posts a public reply, and by mentioning draftId for AI drafts. This clearly differentiates it from related tools like reply, approve_reply, and create_comment_to_dm.

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 explicitly states the critical 24-hour window constraint and what happens outside it (refused with window_closed). It also gives guidance on when to use draftId and when to include workspaceId, including the instruction not to ask the person again. This is strong usage 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 and openWorldHint=true; the description goes well beyond by explaining irreversibility ('a sent message cannot be recalled'), the Meta 7-day / one-private-reply constraint, the 750 replies/hour shared rate limit, the alreadyReplied refusal path, and the error codes (automation_not_live, past_comments_running, past_comments_no_post). This is exactly the added context the annotations cannot carry.

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 and the critical 'preview first' warning are front-loaded, and nearly every sentence carries operational content (limits, error codes, mode effects). It is dense and long with heavy parenthetical asides, which costs a little readability, but little of it 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 output schema, the description compensates by naming where results surface: preview counts, get_automation (pastComments) for progress, and list_automation_runs for each answered comment. Combined with the mutation warnings and preconditions, an agent has everything needed to invoke this safely.

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 the baseline is 3, but the description adds real meaning: mode preview is described as reading the newest comments and reporting eligible vs skipped by reason, start as queuing a throttled job, and includeAnswered/publicReply are tied to their effect on skipped/answered comments. It stops short of documenting workspaceId behavior, which only the schema covers.

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 — running a live comment automation against comments already on the post — and immediately scopes it against the default behavior ('An automation normally reacts only to new comments'). An agent can distinguish this from create_automation, enable_automation, or a normal live run 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?

Explicitly prescribes the workflow: 'Always preview first, show the person the numbers, and start only after they confirm.' Names when each mode applies (preview/start/stop), when not to proceed (7-day limit, alreadyReplied), and what happens if you skip preview. Nothing is left 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 destructiveHint=true but say nothing about merge semantics and versioning. The description adds substantial behavioral context: top-level fields replaced, objects merged one level deep with a concrete example (deliver.text keeps deliver.links), null removes a field, arrays replaced whole, stale version answers version_conflict, and live-flow edits take effect immediately. This is rich disclosure beyond 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?

The description is dense but front-loaded with the core update semantics, then the versioning rule, then the failure-mode routing. It is one long paragraph; a break between the merge rules and the routing/steering sentences would improve scanability, but every sentence carries needed 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?

For a destructive mutation with no output schema, the description covers the essential unknowns: merge/replace semantics, null behavior, version precondition and conflict error, rename and enable behavior, the Instagram follow-check fields, the not_a_template routing to put_automation, and the immediate effect on live flows. Nothing an agent needs to call it safely 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 coverage is 50%, so the description must compensate. It explains the id/version pairing (read first with get_automation and pass its version), the params merge semantics, and that name/enabled are also editable with the same checks as enable_automation. It does not restate the workspaceId rule, but that is already documented in the schema, so the description covers the documented gap well.

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 (edit) and resource (an automation with its template shape), and explicitly names the fields it can change (name, enabled, template params). It distinguishes itself from put_automation by stating the template-shape precondition, so an agent can tell which sibling to pick without opening 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?

Explicit when-to-use (an automation still having its template shape) and when-not (a canvas-edited flow has no template shape, use put_automation). It also tells the agent to read it first with get_automation and pass the version, and explains the version_conflict failure mode. Sibling routing is fully specified.

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 key behavioral context beyond the annotations: the timing effect ('Applies to posts published or edited after this call'), the lack of retroactive changes, and the propagation behavior ('Every copy of the same file in your workspaces follows'). These traits are not captured in the annotations (readOnlyHint: false, destructiveHint: false) and would otherwise be unknown to the agent, so this is valuable disclosure.

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 two sentences with no redundant words. It front-loads the core action, then packs in scope, timing, an alternative tool, and a workspace behavior. Every clause carries information that an agent needs, earning its place without any fluff.

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 mutation tool with no output schema, the description covers purpose, behavior, and parameter usage comprehensively. The only missing element is an explicit note about what the tool returns (e.g., success or updated media) or error cases beyond the workspace-id hint. Since there is no output schema, a brief mention of the return value would fully round it out, but the current description is already strong enough for correct invocation in most scenarios.

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?

Even though schema coverage is 100%, the description adds significant meaning to the parameters. It tells the agent where the id comes from (media_presign, media_from_url, or media_upload_status) and gives nuanced guidance on workspaceId: when it's needed, that the error reveals the ids, and to leave it out if already decided without asking again. This goes beyond the schema's basic type descriptions and aids correct invocation.

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 explicitly states the verb ('Mark or unmark'), the resource ('uploaded image or video'), and the attribute ('aiGenerated'). It also distinguishes itself from the sibling update_post by noting that posts already out do not change and referencing update_post for that case, making it easy for an agent to select the right tool.

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