Hermoso

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds valuable behavioral context beyond the annotations: it mentions the cost model (a transcription call, no ScrapeCreators credits) and details the output contents (transcript, beat list, timestamps). This transparency helps the agent gauge resource usage and expected results 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?

The description is two sentences, front-loaded with the core purpose and outputs, followed by use case and cost. Every sentence earns its place: no fluff, clear structure, and easily scannable by an agent. It avoids repetition of the title and name.

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

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

For a simple read-only tool with one parameter and no output schema, the description fully covers what the agent needs: it specifies inputs, outputs, use case, and cost. It does not require additional context about errors or pagination because it is a one-shot analysis. The description is complete for an agent to select and invoke 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% (the single param 'url' is described in the schema). The description does not add extra parameter detail beyond the schema, so it relies on the schema's explanation. This aligns with the baseline of 3 when schema covers everything; the description's mention of 'a served /generated/ path or a public http(s) video' is repeated from the schema, adding no new semantic 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?

The description clearly states the verb ('Break a video ad down') and the resource (video ad), then specifies the exact outputs: verbatim transcript, beat list, duration, and sampled frame timestamps. This distinguishes it from editing tools like clip_video or reframe_video and from research tools like competitor_teardown, which could be related but are explicitly differentiated by the phrase 'study a reference/competitor ad before remixing its structure.'

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 a direct use case: 'Use to study a reference/competitor ad before remixing its structure.' It also provides cost context ('Costs ~a transcription call; no ScrapeCreators credits'), which helps the agent decide when to invoke it. It does not explicitly list alternatives or when not to use, but the purpose is specific enough that the intended scenario 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?

The description goes well beyond the annotations by disclosing that it is an upsert (replaces previous answer), that deleting is public, immediate, and confirm-gated. It also mentions the connectivity and approval requirements. This adds meaningful behavioral context that the annotations alone (destructiveHint, idempotentHint) do not 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?

The description is two sentences, front-loading the primary actions and then explaining the upsert and delete gating. The 'THIS IS AN UPSERT' emphasis is effective for clarity, though the sentence structure is a bit verbose with the repeated 'one answer per account' phrasing. Overall it is concise and well-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 5-parameter tool with no output schema, the description covers the key operational details: what it does, the upsert behavior, delete confirm-gating, and prerequisites. It does not mention error handling or return values, but those are not essential given the description and schema. The tool's behavior is sufficiently clear for an agent 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 60% (text and confirm have descriptions, delete and locationId do not). The description adds context about delete and confirm ('Deleting is public and immediate and is confirm-gated') and the upsert behavior, but does not clarify locationId or explicitly state that text is omitted when deleting. It partially compensates for the coverage gap but leaves some parameters under-explained.

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 ('Post the business’s answer... or delete the answer') on a specific resource ('Google Business Profile listing'). It distinguishes this tool from siblings like list_google_business_questions and reply_to_google_business_review by focusing on answering public questions, and from delete_google_business_post by addressing answers rather than posts.

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 provides clear context for when to use the tool (to answer or delete an answer on a Google Business listing) and includes prerequisites ('Needs Google Business Profile connected and the project approved'). However, it does not explicitly name alternative tools or state conditions when not to use it, though the upsert and delete-confirm behavior implicitly guide usage.

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 indicate a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the reachability constraint (only docs Hermoso can access), which is useful behavioral context beyond annotations. It does not cover error handling or side effects, but the append action is straightforward.

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

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

The description is a single sentence that front-loads the primary purpose and then explains scope. It is concise but manages to pack essential usage detail without redundancy.

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 append tool with clear schema and annotations, the description adequately covers how to obtain the documentId and what scope is allowed. With no output schema, the description doesn't need to detail return values. It misses explicit mention of alternatives (e.g., append_to_sheet) but is otherwise 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 baseline is 3. The description adds value by explaining the documentId's provenance (from create_doc or list_drive_files), which is not in the schema. The text parameter is self-explanatory in the schema, so no further semantics needed.

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 ('Append text to the end of a Google Doc') with a specific verb and resource. It also distinguishes scope by specifying which documents are reachable, setting it apart from related tools like update_doc and append_to_sheet.

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 clear context on when to use: it targets documents Hermoso can access (created via create_doc or user-provided via file picker, found via list_drive_files). This guides the agent on sourcing the documentId. It does not explicitly mention alternatives like update_doc for other modifications, but the append-at-end scope is implicit.

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

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

Annotations already convey that this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the behavioral constraint that it only operates on sheets Hermoso can reach, which is useful scoping. However, it does not disclose side effects, error conditions, or reversibility beyond what annotations imply. Given the annotations, the description adds moderate value but not rich behavioral detail.

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, front-loaded with the purpose, then provides sourcing guidance. It is concise, with no wasted words, and each sentence earns its place. It could arguably be a single sentence, but the structure is clear and efficient.

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

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

For a simple append tool with no output schema, the description covers how to get the ID and the row format. It does not mention the optional range parameter, but that is documented in the schema. It also doesn't specify return behavior (e.g., success/failure indicators), but given the operation's simplicity, this is a minor gap. Overall, the description is adequate but could mention error scenarios or result expectations.

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%, with all parameters described (rows, range, spreadsheetId). The description reiterates the rows format ('array of row arrays') and adds context on how to source spreadsheetId (from create_sheet or list_drive_files), which is beyond the schema's plain description. This adds marginal but non-critical value, so it sits at the baseline for high-coverage schemas.

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 appends rows to a Google Sheet, specifying the verb (append), resource (rows to a Google Sheet), and the scope (sheets Hermoso can reach). It distinguishes from siblings like update_sheet by implying it adds new rows rather than modifying existing cells. Also, it explains how to identify the target sheet (via create_sheet or list_drive_files), making the purpose 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 gives clear context on when to use this tool: when appending rows. It explains how to obtain the spreadsheetId, either from create_sheet or list_drive_files, which guides the agent on prerequisite steps. However, it does not explicitly mention alternatives like update_sheet for modifying existing cells, nor list any exclusions. The context is sufficient for an agent to decide when this tool is appropriate, though explicit comparisons are missing.

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 goes well beyond the annotations by disclosing the dry-run default, cost quoting, confirm flag, cursor continuation, and the nuanced evidence quality of backfilled posts (weaker evidence, unattributed posts don't vote on hooks). It also warns against guessing hooks from captions. This is comprehensive behavioral disclosure that the annotations (readOnlyHint: false, idempotentHint: true) only hint at. 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 description is lengthy but well-organized, with key terms (BOUNDED, RESUMABLE, QUOTED) highlighted and critical behavioral details emphasized. It front-loads the primary purpose and then proceeds logically through channels, exceptions, execution mode, and data quality caveats. While dense, every sentence earns its place given the complexity of the tool. A slightly tighter structure would improve it, but it's not bloated.

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 covers all essential aspects: supported channels, reasons for exclusions, dry-run behavior, confirmation requirement, cursor for pagination, cost implications, and the data-quality implications of backfilled posts. It even advises against guessing hooks from captions. There is no output schema, but the description describes what the tool returns (count, cost, cursor). 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% with descriptions for all parameters. The description adds meaning beyond the schema by explaining the confirm flag ('omit for a dry run'), the cursor mechanism ('pass the returned cursor to continue'), and the purpose of limit and accountRef. It clarifies the interaction between confirm and the dry-run behavior, which the schema alone doesn't convey. This adds value above the structured definitions.

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: importing a brand's past posts from a channel into the performance record to support hook analysis. It specifies the exact verb, resource, and scope, and distinguishes it from siblings that list current posts or post new content. The level of detail makes the tool's function 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 explicitly explains when to use the tool (to draw on historical posts) and why certain channels are excluded (LinkedIn/Reddit lack endpoints, X has per-read billing). It does not name an alternative sibling directly, but the context makes it clear this is for backfilling history rather than current post management. The note about passing confirm:true clarifies the usage path, though it stops short of stating explicit when-not-to-use scenarios.

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 annotation, the description discloses billing scope behavior ('IN A SHARED TEAM WORKSPACE A MEMBER SEES THE PLAN AND THE BALANCE ONLY') and the correct attribution for missing card/auto-reload data. It also reveals the precise pricing semantic (use plan.priceUsd per plan.period, not plan.monthlyUsd). This adds deep context the annotation cannot express. 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 description is longer than average, but every sentence contributes critical operational guidance: the exact price fields, the admin-rights check, the member-scope restriction, the warning about mail cards. It is front-loaded with the core purpose. A few extra words add safety value, so conciseness remains strong despite length.

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 fully enumerates the returned fields (plan, balance, auto-reload, card, admin rights) and the privacy constraints. It also provides decision-relevant info (when to call, what to expect for members). An agent can use this tool correctly without any additional context. Truly 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?

The input schema is an empty object with 0 parameters, so schema coverage is trivially 100%. Per the baseline for 0 params, a score of 4 is appropriate. The description doesn't need to explain parameters since none exist; it correctly focuses on output semantics instead.

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 ('Show this account's billing at a glance') and enumerates exact fields (plan id/label/ACTUAL price, credit balance, auto-reload, card on file, admin rights). It distinguishes itself from siblings like upgrade_plan and set_auto_reload by explicitly positioning itself as the pre-check for those. No ambiguity about what the tool does.

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 ('Call it before upgrade_plan / set_auto_reload to know what's possible') and even documents who can use it for what (members have read-only billing). It also provides negative guidance: never claim a member has no card, just say you can't see it. This is far beyond typical descriptions.

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 include readOnlyHint and destructiveHint, but the description adds substantial behavioral detail: MISSING vs zero engagement semantics, the absence of impression/view counts in AT Protocol, and the need for a connected account. It also declares read-only and 0 credits, which are not in the annotations. No contradictions.

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 every sentence carries key information—purpose, addressing, caveats, semantics, and prerequisites. It is structured logically: what, how-to, warnings, status behavior, and limitations. No 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?

The description covers purpose, parameters, limitations, behavioral outcomes, and prerequisites. With no output schema, it could be clearer about the exact return structure (e.g., how counts are keyed), but it does explain that missing URIs yield MISSING. Minor gap: no mention of response format beyond the metric types.

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 single parameter 'uris' already has a schema description including the 25 limit. The tool description adds crucial meaning: AT-URI not web URL, sourced from post_to_bluesky return, and clarifies the maximum. This goes beyond schema and prevents misuse.

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 reads engagement metrics (likes, reposts, replies, quotes, bookmarks) for up to 25 posts, and specifically identifies the platform (Bluesky). It differentiates from similar tools by focusing on Bluesky and mentions the AT-URI addressing, which is distinct.

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 usage guidance: address by AT-URI not web URL (and where to get it), warns against computing engagement rates, and states prerequisites (connected account, read-only, 0 credits). However, it does not explicitly compare to sibling tools like x_post_metrics or collect_post_metrics, so an agent might not know when to pick this over those.

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?

Despite annotations indicating readOnlyHint=false and idempotentHint=false, the description goes far beyond: it explains the multi-step flow (list, quote, confirm), the need for billing-admin rights, the saved-card requirement, the quote_token's 10-minute validity and idempotency guarantee, and the Stripe checkout URL path. It also notes that subscriptions are human-managed, covering important side-effect behavior 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?

The description is dense but every sentence serves a purpose. It front-loads the core action ('Out of credits? Top up...'), then systematically covers the two paths, the token mechanics, security prerequisites, and the recommended alternative (set_auto_reload). No filler words; structure mirrors the logical workflow.

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 with three optional parameters, two distinct purchase paths, and no output schema, the description is remarkably complete. It covers the list→quote→confirm sequence, falls back to checkout URL when no card exists, explains idempotency via the token, mentions admin rights, and even suggests auto-reload as a preventive measure. Missing only minor details like error handling or rate limits, which are not critical given the coverage.

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?

Although the schema already documents all three parameters with 100% coverage, the description enriches them by explaining the interplay: omitting 'pack' lists packs, 'confirm:true' requires 'quote_token', and the token binds the exact price and enables idempotent retries. It clarifies the required sequence and which parameters matter in which flow, adding substantial value 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?

The description clearly states the tool's purpose: buying credit packs and topping up an account. It specifies the resource (credits), the action (buy/top up), and distinguishes the one-click flow from the checkout path. It implicitly differentiates from sibling billing tools like billing_status and set_auto_reload by focusing on pack purchases and quoting.

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 explicitly tells when to use this tool ('Out of credits? Top up with a credit PACK'), when not to (subscriptions are managed by a person), and provides an alternative (set_auto_reload for automatic topping up). It also details the two distinct usage paths (checkout URL for first purchase, one-click for subsequent) and their prerequisites.

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 and idempotentHint, and the description adds important behavioral constraints: it only works while queued, and cannot unsend published posts. This goes beyond the annotations by explaining the operational limit.

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 efficient sentences, front-loaded with the action, then limitations, then alternative. No wasted words, and the important constraints are placed early.

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 single-parameter deletion tool, the description covers acquisition of the id, the operational constraint, and the alternative for published posts. With annotations covering safety and schema covering parameters, 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 covers 100% of the parameter with a clear description (id from list_scheduled). The description reinforces this source but adds little new meaning beyond the schema. 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 a specific verb (Remove) and resource (queued post), and clearly distinguishes it from other tools by noting the alternative for published posts (manage_meta_post). This leaves no ambiguity about what the tool does.

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 instructs where to get the id (from list_scheduled) and provides a clear when-to-use (queued) and when-not-to-use (published) with a named alternative. This fully routes the agent to the correct action.

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 provide only basic hints (readOnlyHint=false, destructiveHint=false). The description adds valuable context: it reveals the tool is paid, returns the served URL, and preserves performance/lip-sync/background sound. While it doesn't detail all side effects, it covers key behavioral traits 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?

Two sentences with zero waste. The core action is front-loaded, followed by usage guidance and then practical details (cost, return). Every sentence earns its place, and the structure leads with the most critical information.

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

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

For a simple tool with 2 parameters, no output schema, and basic annotations, the description covers all essential aspects: what it does, when to use it, what it returns, and the cost. 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 both parameters (video and voice) are fully documented in the schema. The description mentions the voice parameter's default and example presets but adds no new meaning beyond what the schema already provides. 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 a specific action ('Swap the narration'), a specific resource ('a finished video'), and what is preserved ('performance, lip-sync, and background sound'). It also distinguishes itself from dub_video, making the purpose unambiguous even among many sibling tools.

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

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

Explicitly states when to use this tool ('when the user likes the video but wants a different narrator voice') and when not to ('use dub_video only for language translation'). This direct routing to the alternative leaves no ambiguity for the agent.

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, but the description adds specific behavioral detail: it 'pulls Meta's actual policy pages', returns quotes verbatim, and 'never changes the creative'. It also mentions the flat 1-credit cost, which is useful operational context 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 a single, dense sentence that front-loads the core purpose, then layers specifics about output, behavior, and use cases. No wasted words; every clause adds value. It is appropriately sized for the complexity of the tool.

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 covers what the tool does, how it behaves (read-only, returns verdicts with quotes), when to use it, and the credit cost. It lacks explicit detail on failure modes or exact response format, but for a read-only check tool with no output schema, it is sufficiently complete for an agent to invoke 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% with each parameter described. The description adds a small nuance for the 'category' parameter (helps pick relevant policy pages) but does not elaborate on copy, claims, or imageDescription beyond the schema. This matches the baseline of 3 for high coverage with minimal extra detail.

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 ('pre-flight'), a resource (ad copy against Meta's Advertising Standards), and the exact output (verdict pass/fix/block with verbatim quotes and rewrites). It clearly distinguishes itself from siblings like plan_ad or render_ad by emphasizing it is a check, not an edit, and by referencing live policy pages.

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 'before you run it' and lists specific high-risk categories and claim types where it is especially useful. It implies when to use it (pre-flight) but does not mention alternatives or when not to use it, though no direct sibling offers the same function. Overall, it provides strong contextual 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 (destructiveHint=true, idempotentHint=true, readOnlyHint=false), the description discloses the non-obvious behavior: nothing is cleared on the first call, the count is returned, and confirmation requires echoing that count. It explains the safety purpose of the echo, the lack of a default range, and the read-back verification. This is rich, non-redundant behavioral context that significantly exceeds 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 a single dense paragraph but every sentence serves a purpose: purpose, destructive warning, protocol, rationale for echo, no default, verification, alternative. It is front-loaded with the core purpose and progressively details the safety flow. It could benefit from slight structural breaking (e.g., bullets), but remains efficient and free of 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 destructive tool with a mandatory safety protocol, the description covers all essential operational steps: the two-call flow, confirmCells echo, read-back verification, and the alternative for tab removal. It also explains the return value context (filled-cell count) on first call. The absence of an output schema is mitigated by this description. Nothing critical 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 only 40% (range and confirmCells have descriptions). The description adds meaningful semantics to confirmCells (echo the filled-cell count) and range (no default, explicit). However, it offers no explanation for sheetUrl or spreadsheetId, which lack schema descriptions. Since coverage is low and these remain unexplained, the description only partially compensates for the gap.

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 a specific verb and resource: 'Empty a range of cells in a Google Sheet, leaving the rows themselves in place.' It clearly distinguishes from the sibling manage_sheet_tabs by explicitly stating the alternative for removing a tab, making the tool's scope 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 provides explicit when-to-use guidance, detailing the mandatory two-step confirm protocol: first call without confirm to get the filled-cell count, then call again with confirm:true and confirmCells set to that count. It also names the alternative tool (manage_sheet_tabs) for removing a whole tab, leaving no ambiguity about when to choose 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 are minimal (only non-read-only, non-destructive), so the description carries the full burden. It discloses the pipeline (transcription, vision call for subject-aware reframing, crop offset held per clip), the deliberate nontracking to avoid shimmer, the default burned-in captions and approximate timing, and the return fields (reframedToSubject, reframeWhy, captionsBurned). This goes far beyond annotations with actionable behavioral detail. 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 description is long but every sentence carries critical operational information. It is front-loaded with the core purpose, then systematically covers input types, restrictions, cost, return shape, caption defaults, and timing caveats. The structure uses clear labels (ACCEPTS, NOT supported, Cost, RETURNS) that make scanning easy, and there is no filler or repetition.

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

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

Despite no output schema, the description fully explains what the tool returns (clips[] with mp4 URLs, titles, hooks, captions, scores, timecodes) and how to interpret result fields. It also documents constraints (15s-600MB, 40-min analysis limit), costs, and caveats (approximate timing, unidirectional crop behavior). An agent has everything needed to call this tool correctly and interpret its output.

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%, but the description adds significant value beyond the schema. For example, it explains the default behavior of `captions` (burned by default, delivered bare if no readable speech) and `aspectRatio` (9:16 default for vertical platforms, 'keep' leaves source framing). It also clarifies that `count` is 1-8 with default 4, though the schema already covers that. The description enriches parameter understanding with usage context and edge-case handling.

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: 'Cut ONE long video into several RANKED, ready-to-post short clips' with explicit target use cases (podcast, webinar, interview, etc.). It clearly differentiates from sibling tools like edit_video, dub_video, and reframe_video by describing the full pipeline (transcribe, select, cut, reframe) and the output format (multiple clips, not a single edit).

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 when-to-use context and exclusions: acceptable input formats (YouTube, direct files, Hermoso URLs) are listed, and unsupported sources (TikTok/Instagram/Facebook, age-restricted, live) are called out with a fail-fast/refund policy. Also states prerequisites (min length, max size) and cost implications, giving the agent full decision criteria for invocation.

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 goes well beyond the annotations. It discloses that metrics accrue over time, that missing channels are recorded as ABSENT (never zero), that failed reads are recorded as 'could not tell', that X is skipped by default due to per-call billing, and that the skip is always reported. This is rich behavioral context that aligns with the readOnlyHint:false (it writes) and idempotentHint:true (skips already-taken readings). No contradictions.

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 substantial but every sentence carries a distinct piece of information: core action, accrual logic, absent/failure handling, X's cost, and the reporting of skips. It is not terse, but it is well-ordered (front-loads the main purpose) and avoids redundancy. A bit tighter prose would make it excellent, but it earns 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?

The description covers the key behavioral aspects: when to invoke, how accrual works, how missing/failed data is represented, and the cost implications of X. It does not mention the return value (e.g., whether the collected metrics are returned or just stored) or how the time-series can be retrieved afterward. Given no output schema, this is a minor gap, but the tool is otherwise well explained.

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 both parameters well (100% coverage), so the baseline is 3. The description adds meaningful context beyond the schema: it explains why includeMetered bills credits, why the default is to skip X, and that the skip is reported even when omitted. This extra context about cost and reporting justifies 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 action ('Fetch fresh performance numbers'), the target ('this brand's recorded posts'), and the outcome ('store them as a time-series'). It further clarifies the accrual logic and how missing or failed reads are recorded, making it distinct from similar metric tools like x_post_metrics or post_performance, which focus on single posts or other scopes.

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 does not explicitly contrast with sibling tools such as x_post_metrics, post_performance, or x_post_insights. It explains when to invoke the tool (when readings are due) and how it behaves (skipping already-taken readings), but it doesn't provide criteria for choosing this tool over alternatives or mention that this is the canonical way to collect time-series metrics for recorded posts.

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 indicate a write, non-destructive, non-idempotent operation. The description adds that the comment is PUBLIC and posted as the brand, instructs showing the user exact wording and getting go-ahead, and discloses Meta's restriction on Instagram top-level comments. This provides behavioral context 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 well-structured, front-loaded with the core action, then explaining the tactic, behavioral cautions, and platform restriction. It is slightly long but every sentence adds value, and the information is logically organized. Minor redundancy (e.g., 'FACEBOOK ONLY' and Instagram refusal) is acceptable but prevents a perfect 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?

For a write operation with 4 params and no output schema, the description covers all critical context: what it does, when to use it, where to get postId, the need for user approval, and platform limitations. It also contrasts with reply_to_meta_comment, ensuring the agent has enough information to use it correctly. Very 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?

The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal parameter meaning—mainly that postId comes from list_meta_posts, which is redundant because the schema already mentions that. No additional parameter semantics are provided, so the score stays at baseline.

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

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

The description states a specific verb and resource: 'Leave a NEW top-level comment on one of the brand’s own Facebook Page posts, as the brand.' It explicitly differentiates from reply_to_meta_comment (replies) and clarifies it's for top-level comments, not edits or Instagram. This makes the tool's purpose unambiguous and distinct from siblings.

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 explicit when-to-use scenarios: the 'link in the first comment' tactic, adding pinned clarifications, offer codes, or corrections. It also says postId comes from list_meta_posts and explicitly warns that Instagram media IDs are refused by name, directing users to reply_to_meta_comment instead. This gives clear guidance on when and how to use the tool versus 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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical behaviors: TikTok silently hides spam comments, raw URLs are refused on new comments, and authorization is required. These are essential operational details not captured in annotations, and they do not contradict anything.

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 at ~110 words, but every sentence serves a purpose. It front-loads the core action, then delivers constraints, workflow, and warnings. All-caps warnings are justified for critical pitfalls. It could be slightly more concise, but it is efficiently 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?

The description covers all essential aspects for correct invocation: authorization requirement, text/image requirement, upload-first rule, silent spam hiding with verification steps, and the caution against repetitive comments. With no output schema needed, nothing critical is missing for an agent to use this tool safely and effectively.

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 has 100% parameter coverage, but the description adds significant value: it explains the text-or-image requirement, that imageUri must come from upload_tiktok_comment_image and that width/height must be passed together, and clarifies the character limit and UTF-8 encoding. This greatly aids correct parameter usage beyond 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 states the action ('Write'), the resource ('TikTok post the authorized account owns'), and specifies 'NEW top-level' to distinguish from replies. It also mentions the two content options (text or image). This clearly separates it from sibling tools like reply_to_tiktok_comment.

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 contrasts with replies ('a reply is the one place TikTok accepts a plain URL'), instructs to use upload_tiktok_comment_image for image upload, suggests list_tiktok_comments for visibility verification, and directs to tiktok_account_status for authorization. This provides clear when-to-use and when-not-to-use 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 declare readOnlyHint=true and openWorldHint=true; the description adds valuable behavioral context: it spends LLM tokens, optionally ~1-2 ScrapeCreators credits when auto-pulling, and auto-tailors to the user's saved brand. This discloses side effects beyond 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 dense but front-loaded with purpose and then the contract. While relatively long, every sentence delivers value—output components, cost implications, and tailoring behavior—so it is efficient for the complexity it covers.

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 complex tool with optional auto-pull, the description thoroughly covers inputs, behavior, costs, and outputs (playbook components). It doesn't specify the exact return format, but since no output schema exists and the description lists the playbook elements, it's sufficient for an agent to call 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%, but the description adds meaning beyond the schema: ads are described as raw ad objects from prior calls, omitting them triggers auto-pull, and competitor.domain is noted to sharpen the auto-pull page match. This goes beyond the schema's basic 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 clearly states the tool's purpose: 'Tear a competitor's ad strategy down into an actionable playbook' and lists specific outputs (hook MIX, themes, white space, counter-plays, territories). It distinguishes itself from data-pull siblings like pull_competitor_ads by being the analysis step, not the retrieval step.

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 an explicit contract: either pass `ads` from prior pull_competitor_ads / search_meta_ads calls, or omit them to trigger an auto-pull. This clearly indicates when to use the tool and how it relates to sibling tools, though it doesn't explicitly mention when not to use it over alternatives like research_ads.

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=true, destructiveHint=false), so the description carries the full burden. It reveals key behaviors: conversion happens on Microsoft's servers (no local re-encoding), the result is stored at a durable Hermoso URL, Microsoft's own link expires quickly (warning not to share it), and it requires OneDrive connected but asks for no new permissions. This adds substantial context beyond the annotations and helps the agent understand side effects and output properties.

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 longer than minimal but every sentence earns its place. It front-loads the core purpose, then provides supporting context (format support, use cases, critical requirement, output URL behavior). The structure is logical, with the most important constraints (JPG dimensions, durable URL) clearly highlighted. Slightly verbose but justified by the tool's complexity.

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

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

Given the tool's complexity (4 params, no output schema but describes output URL, broad format support), the description covers all critical aspects: what it does, when to use it, parameter requirements, output characteristics, and prerequisites (OneDrive connected). An agent has everything needed to invoke it correctly without additional research. Failure modes are not detailed, but that's not a requirement for this scoring.

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 100% schema description coverage, baseline is 3, but the description adds meaning: it explicitly states that JPG REQUIRES both width and height, clarifies fileId comes from list_onedrive_files, and notes format defaults to pdf. These are non-obvious details that prevent common errors. The description goes beyond mere schema documentation.

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 a clear verb+resource: 'Turn a file already in the user's OneDrive into a PDF or a JPG.' It also specifies the exact output formats and differentiates itself by highlighting the broad format support (PSD, raw camera formats, etc.) that nothing else in the product can open. This distinguishes it from related tools like get_onedrive_file or generate_image 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?

Explicit use cases are given: 'turn a client's deck into images... get a usable JPG out of a designer's PSD... hand someone a PDF of a spreadsheet.' It also explains why it's the right tool for these scenarios ('the point is the 130 source formats'). While it doesn't explicitly name alternatives or when-not-to-use, the context strongly implies its niche and conveys critical usage constraints (e.g., JPG requires both width and height). The guidance is clear and 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?

The description adds valuable context beyond annotations: it explains that the tool switches to the new workspace, that workspaces are isolated (data separation), and that it's free until draft_brand is run. It aligns with annotations (idempotentHint=true, destructiveHint=false) without 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?

Three sentences, no fluff. The main action is front-loaded, and each subsequent sentence adds distinct value (concept, usage alternatives, idempotency/cost). Efficient and well-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 2-parameter creation tool with no output schema, the description covers the conceptual model, isolation, switching behavior, idempotency, cost, and sibling differentiation. Nothing essential is missing 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?

Schema coverage is 100%, so both parameters are already well-documented. The description does not add significant new semantic detail beyond the schema, though it reinforces the 'switch' behavior tied to the activate parameter. 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 a specific verb and resource: 'Add a NEW brand workspace'. It distinguishes itself from siblings by naming draft_brand and update_brand and explaining what each is for. This leaves no ambiguity about what create_brand does.

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 states when to use this tool ('for a second brand or a new client') and when to use alternatives ('use draft_brand to FILL a workspace, and update_brand to edit one'). Also explains behavior on re-running (idempotent) and the credit implication, providing complete 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 readOnlyHint: false and destructiveHint: false, so the description's mention of 'create' is consistent. The description adds the connector requirement and return info (id + URL), which are useful. However, it does not disclose what happens if the connection is missing, whether the tool always creates a new doc (non-idempotent, which annotation confirms), or any side effects beyond creation. For a mutation tool, this is adequate but not rich behavioral 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 two sentences with no padding. The first sentence states the purpose and gives examples; the second covers the return value and prerequisite. Everything is front-loaded and every word earns its place. It is concise without sacrificing essential 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 simple 2-parameter tool with no output schema, the description covers the key aspects: what it creates, the return value, and a prerequisite. It does not explicitly mention error handling or formatting, but given the tool's simplicity and the presence of sibling tools that handle modifications (append_to_doc, update_doc), this is fairly complete. The examples and connector note provide useful context beyond the bare minimum.

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% with descriptions for both 'title' and 'text'. The description adds examples of usage and clarifies 'optional body text', but it also states 'title + optional body text', implying title is required, while the schema marks both parameters as optional (required: 0). This creates a slight inconsistency. The examples add some semantic value, but the mismatch in requiredness prevents a higher score.

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 verb 'Create', the resource 'a new Google Doc', and specific attributes (title + optional body text). It provides concrete examples (export ad copy, creative brief, report) that help distinguish it from related tools like append_to_doc, update_doc, and create_sheet. The scope is unambiguous: 'in the user’s Drive'.

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 context for when to use it via examples ('e.g. export ad copy...') and notes the prerequisite of having Google Drive connected. It does not explicitly state when NOT to use it (e.g., when appending to an existing doc) or name alternative tools, but the purpose is clear enough that an agent would correctly infer it is for creating new docs. The connector instruction adds practical 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 cover readOnlyHint=false and destructiveHint=false, so the description doesn't need to repeat those. It adds valuable context beyond annotations by stating the return value (folder id + webViewLink) and the crucial distinction between folder NAME and ID when interacting with save_to_drive. This is more than the schema 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?

The description is a bit long but front-loaded with the main purpose and return value. The extra note about how to use the ID and the save_to_drive distinction is valuable and earns its place, though it could be trimmed slightly. Overall, it is efficient and well-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 simple create tool with only two parameters and no output schema, the description is highly complete. It states the return values, explains nesting, and disambiguates from a confusing sibling (save_to_drive). Nothing essential 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% (both name and parentId are described). The description reiterates the optional parentId and its default (Drive root), but doesn't add new semantics beyond what the schema already states. The baseline of 3 is appropriate since the schema carries the parameter documentation.

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 verb ('Create'), the resource ('a folder in the user’s Google Drive'), and the optional nesting behavior. It distinctly distinguishes itself from siblings like create_onedrive_folder and create_doc by specifying 'Drive folder'.

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 explains when and how to use this tool: to organize saved files, and it gives concrete downstream usage of the returned ID (as moveToFolderId or parentId). It also warns about the gotcha with save_to_drive's folder name, providing clear 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?

The description extensively discloses behaviors beyond the annotations: Meta silently accepts duplicate names and creates twins, so Hermoso refuses them and returns the existing id; vertical and portfolio are permanent; confirmation is read back from Meta rather than echoed. Since annotations only give generic flags (readOnlyHint, idempotentHint), this description carries the full transparency burden and does so thoroughly.

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 nearly every sentence carries a pitfall or precondition relevant to successful execution. It is somewhat front-loaded with the create purpose, though the single tight paragraph and a few optional extras ('Free, 0 credits') keep it from being perfectly concise for an agent-read system.

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 five-parameter, no-output-schema creation tool, the description answers every non-obvious call decision: how to designate ownership, what happens on ambiguity, how duplicates are handled, what is permanent, and what the confirmation actually contains. An agent can invoke this tool without requiring external knowledge of Meta cataloging behavior.

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 with 100% schema coverage, the description adds material meaning: businessId and businessName are two ways to identify the owner; a name match that is unknown or ambiguous is refused rather than guessed; duplicate names are guarded by default and require allowDuplicateName:true. These are operational semantics the schema alone does not 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?

The first sentence states a concrete verb (create), a specific resource (product catalog), and a target (Meta business portfolio). It also grounds the tool in a workflow — this is the first step before feed ingestion and campaign targeting — which distinguishes it from list_meta_catalogs, update_meta_catalog, and delete_meta_catalog.

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 makes the intended usage sequence explicit: create the catalog first, fill it from feed or Shopify, then point a campaign at it. It also tells the agent how to identify the portfolio using list_meta_catalogs output. It does not explicitly say 'use update_meta_catalog when you need to modify an existing catalog,' so it stops short of naming the alternative pathways.

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, so mutation is expected. Description adds that it returns folder id and webViewLink, and clarifies nesting behavior. Does not disclose idempotency behavior (e.g., duplicates on repeat), but annotations already indicate it's not idempotent. Adds 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?

Three sentences with clear structure, front-loaded with the core action, then returns and usage. No redundant phrasing.

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 create operation with two parameters, the description covers purpose, return value, and cross-tool usage. It could mention behavior on existing folder names, but that's a minor gap. Overall adequate.

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 describes both parameters clearly (name, parentId with default root). Description reiterates nesting but doesn't add new semantics beyond schema. Since schema coverage is 100%, description adds minimal extra 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 a specific verb (create) and resource (folder in user's OneDrive), mentions optional nesting, and distinguishes from related tools by naming save_to_onedrive and update_onedrive_file. Clear purpose.

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 how to use the returned id with update_onedrive_file and for nested folders, and clarifies that save_to_onedrive uses a name, not this id. This helps the agent choose the correct tool. Does not explicitly contrast with create_drive_folder but the name implies the service.

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?

Though annotations already indicate non-readOnly and non-destructive, the description adds valuable behavioral context: the default PUBLIC visibility, the invisibility of Pins on SECRET boards, and the logical dependency that a board must exist before pinning. This goes beyond the annotation hints and helps the agent understand consequences and prerequisites.

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 with no fluff, front-loaded with the core action and then the most important usage nuance. Every clause earns its place, and the structure is easy 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?

Covers the key workflow (check list first, then create), the default privacy behavior, and the caution about SECRET. It does not mention the response format or potential errors, but for a create tool with no output schema, these are not critical. The description is functionally 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 input schema already provides detailed descriptions for all three parameters (100% coverage), including enums and character limits. The description reinforces the privacy behavior but does not add substantive new meaning beyond what the schema already states. Since schema covers everything, 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 a specific verb and resource ('Create a board on the connected Pinterest account') and goes beyond by explaining the prerequisite role of boards for pins. It clearly distinguishes from siblings like update_pinterest_board and delete_pinterest_board by focusing on creation and the empty-boards scenario.

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 when-to-use guidance: if list_pinterest_boards returns empty, create a board here rather than telling the user you can't pin. It also warns against using 'SECRET' unless the user requests it, which is a clear constraint on when not to use a particular parameter. This directly supports tool selection among related list/update/delete 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 already indicate non-read-only and non-destructive behavior. The description adds valuable behavioral context: it returns the spreadsheet ID and URL, it optionally fills rows (implying empty sheets are possible), and it requires a Google Drive connection. These details go beyond the annotation hints and help the agent understand side effects and prerequisites. 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 description is compact and well-organized: it leads with the core purpose, explains the data format, states the return value, and ends with the connection prerequisite. Every sentence adds functional value, and the length is appropriate for the tool's simplicity.

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 with 2 optional parameters and no output schema, the description covers all necessary aspects: what it does, how rows are structured, what it returns, and the required connection. The agent has enough information to invoke it correctly without ambiguity. Missing details like default title behavior are minor and not 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?

Since schema description coverage is 100% and both parameters ('rows' and 'title') already have descriptive text in the schema, the description adds little new meaning. It repeats the row-array structure and headers note, but does not introduce novel syntax, formatting rules, or default behavior. Baseline 3 is appropriate when the schema handles parameter documentation.

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 ('Create a new Google Spreadsheet'), the location ('in the user's Drive'), and the optional data filling capability. It distinguishes itself from sibling sheet tools (append, update, read) by focusing on creation, and it provides concrete examples (swipefile, ad list, performance report) that make the purpose immediately understandable.

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 clear context on when to use this tool (creating a new spreadsheet, optionally populating it) and even gives example use cases. It does not explicitly name alternatives or state when-not-to-use, but the distinction between creating vs appending/updating is implicit and clear. The connection requirement is also stated, which is a useful precondition.

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 goes far beyond the annotations by disclosing that Meta re-categorises templates, that submission does not make a template sendable, that language variants are distinct, that media headers require an uploaded handle or the tool refuses locally, and that carousel cards must share identical components. These are non-obvious behavioural facts that materially affect how an agent should use the tool.

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 every sentence carries operational weight and the most important facts are front-loaded. It is structured by topic: purpose, category consequences, naming/language, post-submission state, carousels, media handles, and cost. There is no filler; the density is justified by the complexity of the tool.

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

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

Given the tool's complexity, the rich schema, and the absence of an output schema, the description covers essentially everything an agent needs to know before calling it: required components, template lifecycle, category reclassification, media upload limitations, carousel constraints, and the need to later read the template via list_whatsapp_templates. It even discloses the credit cost.

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?

Although the schema already covers 100% of parameters, the description adds substantial meaning the schema alone does not convey: category affects price and review policy, name constraints are reinforced, language is never defaulted, and the components parameter gets deep carousel and media-handle semantics. It explains the 160-character card body limit, the 1024-character bubble limit, and the difference between card_index and components, which are essential for 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 opens with a specific verb and resource: "Submit a new WhatsApp message template for Meta's review." It immediately distinguishes this from sending messages, listing templates, or deleting templates by explaining this is the only way to initiate a WhatsApp conversation outside the 24-hour window. The scope is 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?

The description clearly states when this tool is needed: to start a WhatsApp conversation outside the 24-hour customer-initiated window. It also gives explicit follow-up guidance, saying the template returns PENDING and must be re-read with list_whatsapp_templates. However, it never explicitly names send_whatsapp_message as the alternative for actually sending an approved template, so the when-not-to-use guidance is mostly implied rather than stated.

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

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

The description goes far beyond annotations by disclosing irreversibility (no trash, no undelete), deletion of associated engagement, the two-phase confirmation to prevent blind deletion, and the requirement that it only works on own posts. It also notes 0 credits and the connection prerequisite. No contradictions 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 description is long but every sentence contributes critical guidance. It opens with the core action and irreversibility, then logically proceeds through the two-call workflow, identification methods, and constraints. The structure is front-loaded and well organized, avoiding redundancy.

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 covers all necessary context: the destructive and irreversible nature, the safety mechanism to prevent wrong deletions, identification options, prerequisites (own post, connection), and behavioral details (credits, engagement loss). For a destructive tool, this is exceptionally 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?

Although the schema already describes all three parameters, the description adds significant semantic value by explaining the interplay: confirm must be true, confirmText is required once the post has engagement and must echo the post's text (first 40 chars), and uri can be either an AT-URI or record key. This clarifies relationships not evident from the schema.

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

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

The description clearly states the tool permanently deletes a Bluesky post from the connected account's own posts. It specifies the resource (post), the action (delete), and the scope (own posts), distinguishing it from other delete tools for different platforms.

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 step-by-step instructions: call without confirm first, show the user the post's text and engagement counts, get unambiguous yes, then call with confirm:true. It also specifies when confirmText is required and how to identify the post (AT-URI or record key), covering edge cases like no-text posts.

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, but the description goes well beyond by detailing irreversibility, shared-workspace impact, and the exact safety mechanism behind confirmName and confirmConnectors. It also explains why the first brand cannot be deleted (root storage). This is substantive behavioral context the annotations do not 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?

Though longer than typical, every sentence carries purpose. The safety warning is front-loaded, the workflow is sequential, and the rationale for the confirm fields is included without fluff. It avoids redundancy and is well-organized for an agent to parse under time pressure.

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 destructive nature and absence of an output schema, the description fully explains the tool's contract: what it destroys, the inventory returned on the first call, the required confirmations, and the edge case of the first brand. The agent has all necessary information to invoke it safely and 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 critical semantics: it explains the dual-call pattern (first call without confirm, second with confirm:true), the conditional requirements for confirmName (when not empty) and confirmConnectors (when at least one connected account), and the rationale that confirming intent does not prove correct workspace. This transforms the parameters from bare fields into a guarded workflow.

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 precise verb ('PERMANENTLY delete') and a specific, scoped resource ('a brand workspace and EVERYTHING in it') with an exhaustive list of what's included (brand profile, memory, swipefile, generated assets, etc.). It clearly distinguishes from sibling delete tools (delete_playbook, delete_creator) by naming the full workspace scope, so the agent can immediately route correctly.

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 an explicit two-phase workflow: call WITHOUT confirm first to get inventory, show it verbatim, get unambiguous yes, then call again with confirm:true and the required confirmation fields. It also states the exclusion for the account's FIRST/anchor brand, which is a critical condition. This is model usage guidance with no ambiguity.

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 indicate destructive and idempotent hints. The description adds valuable behavior beyond that: it records a cross-device delete to prevent reappearance, clarifies that ads are untouched, and mentions reversibility via save_creator. These details go beyond the structured annotations and help the agent understand side effects. It does not cover auth or error handling, but it is strong.

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 three sentences with no filler. The main action is front-loaded in the first sentence, and each subsequent sentence adds distinct value: cross-device behavior, scoping to roster-only, and reversibility. It is concise, well-organized, and 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 simple one-parameter tool with annotations covering destructive and idempotent behavior, the description gives everything needed: how to get the id, what it does, side effects, and reversibility. It also disambiguates from save_creator. There is no output schema, but the operation is straightforward. The description is complete 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?

The schema has one parameter (id) with a description 'the creator id (from list_creators)', providing 100% schema coverage. The description reinforces this by saying 'by id (from list_creators)' but adds no new semantic meaning beyond what the schema already provides. Baseline for 100% coverage is 3, and the description does not exceed that.

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 a specific verb ('Remove'), a precise resource ('a saved creator from this workspace's cast'), and the method ('by id'). It explicitly references list_creators as the source of the id, distinguishing it from sibling delete operations like delete_skill or delete_brand. There is no ambiguity about what this tool does.

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 clear context: it is used to remove a creator from the workspace cast, with the id sourced from list_creators. It explains that the delete is not permanent ('can be saved again with save_creator') and that ads are unaffected, which guides usage. However, it does not explicitly mention when not to use it (e.g., vs. other delete tools), but given the clear purpose, this is sufficient.

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 idempotentHint:true, but the description adds critical behavioral context: default sends to Trash (recoverable), permanent:true deletes forever, and irreversibility warning. It also specifies the confirmation requirement, enriching the safety picture beyond 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?

Two sentences with no filler. The primary action and default behavior are front-loaded, followed by required parameters and a caution. Every word contributes value; the structure is efficient and scannable.

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 operation with no output schema, the description covers all essential aspects: behavior (trash vs permanent), required confirm flag, source of fileId, and user-confirmation guidance. It leaves no critical gaps for an agent to execute 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 already documents all three parameters with 100% coverage, so baseline is 3. The description adds meaningful context: fileId comes from list_drive_files, confirm must be true, and permanent overrides the default trash behavior. This goes beyond the raw schema definitions, though it partly echoes 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?

The description states a specific verb and resource: 'Delete a Drive file.' It distinguishes from siblings like update_drive_file, get_drive_file, and save_to_drive by specifying the action and the source of the identifier (list_drive_files). The purpose is unambiguous and differentiated.

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 provides clear operational guidance: how to obtain fileId (from list_drive_files) and the requirement of confirm:true. It also advises caution for permanent deletion and instructs to confirm with the user. However, it does not explicitly mention alternatives or when not to use this tool (e.g., for OneDrive or other storage), though the Drive-specific scope is implicit.

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

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

Annotations already indicate destructive (destructiveHint: true) and not read-only (readOnlyHint: false). The description adds valuable behavioral detail: the deletion takes effect 'immediately' and 'CANNOT be undone,' plus a warning to confirm with the user first. It also communicates the prerequisite of a connected Google Business Profile. This goes beyond the annotations and gives the agent a realistic sense of impact and step-before-calling. 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 description is four short, information-dense sentences, each earning its place: purpose, effect/warning, parameter source, and prerequisite. It is front-loaded with the core action, and there is no fluff or redundancy. Every sentence conveys necessary information for correct invocation.

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

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

For a single-parameter destructive tool with no output schema, the description covers everything an agent needs: what it does, irreversible effect, confirmation requirement, how to obtain the parameter value, and a connectivity prerequisite. The annotations handle the safety profile, and the description fills in usage specifics. Nothing essential is missing for correct and safe 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?

The input schema has 100% coverage with a clear description for postId: 'the full post name from list_google_business_posts (accounts/…/locations/…/localPosts/…)'. The tool description merely repeats this instruction ('Pass the full post name from list_google_business_posts'), adding no new meaning beyond the schema. Per the rubric, with high schema coverage the baseline is 3, and the description does not elevate 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?

The description opens with a clear, specific verb and resource: 'Remove a Post from the brand’s Google Business Profile listing.' It distinguishes this deletion tool from related siblings like post_to_google_business (creation) and list_google_business_posts (listing) by explicitly stating the action and the effect on Search and Maps. There is no ambiguity about what the tool does.

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 practical usage guidance: it instructs to confirm with the user first (implying a destructive call), to pass the full post name from list_google_business_posts (a prerequisite step), and notes that a Google Business Profile connection is required. It does not explicitly name alternatives, but the context implies the tool is used after listing posts and before deleting. This is clear enough for an agent to know when to invoke it, though it could be stronger by explicitly contrasting with non-destructive 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 already declare destructiveHint=true and readOnlyHint=false, but the description goes far beyond: it states there is no archive or undo, that product sets are deleted with the catalog, that live ad sets will keep spending with no products, and that the result is a read-back rather than an acknowledgement. This fully discloses the irreversible consequences and the check-on-result 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 every sentence contributes critical information. It front-loads the destructive nature, then systematically explains prerequisites, the confirmation dance, and the response semantics. No fluff, though slightly verbose — a tighter arrangement might earn a 5, but the density justifies 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 destructive tool with no output schema, the description is complete: it explains the return value, the need for blast radius, the confirmation rules, and the special case of live product sets. An agent has everything needed to call this safely and 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 provides descriptions for all 5 parameters with 100% coverage, so the baseline is 3. The description adds meaningful context beyond the schema: it explains when confirmName is required, what confirmChildren represents, and the danger of allowDeleteWithLiveProductSet. This elevates parameter understanding without redundancy.

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 'PERMANENTLY delete a product catalog' — a specific verb and resource — and goes on to distinguish itself from related tools like update_meta_catalog and list_meta_catalogs. It also references meta_catalog_blast_radius as a complementary tool, making the 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?

The description gives explicit when-to-use and when-not-to-use guidance: 'Call meta_catalog_blast_radius first' and clarifies that an empty catalog is a one-call delete while a non-empty one requires confirmName. It also names the alternative tool (meta_catalog_blast_radius) for assessment, leaving no ambiguity about sequencing.

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 indicate destructiveHint and idempotentHint, but the description adds meaningful context beyond them: the deleted item goes to the recycle bin and is recoverable. It also stresses the need for user confirmation, which is not conveyed by annotations. This extra behavioral detail justifies a 4, not just baseline 3.

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 three concise sentences that pack essential information: purpose, consequence, prerequisite, and safety instruction. No fluff or redundancy; it is front-loaded with the primary action. It achieves maximum brevity without omitting critical details.

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-parameter delete tool with rich annotations (destructive, idempotent) and no output schema, the description covers all relevant aspects: what it does, the effect (recycle bin), how to get the ID, and the required confirmation step. Nothing essential is missing for an agent to invoke 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 covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds value beyond the schema by specifying that fileId should come from list_onedrive_files and that confirm must be true, clarifying the intended source and mandatory value. This enhancement warrants 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 action ('Delete a OneDrive item') and specifies it pertains to OneDrive, distinguishing it from sibling delete tools for other platforms (e.g., delete_drive_file, delete_bluesky_post). It also adds a key consequence (moves to recycle bin) that aids unambiguous selection.

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

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

It provides explicit usage steps: obtain fileId from list_onedrive_files, pass confirm:true, and confirm the exact file with the user. While it doesn't name alternatives, the OneDrive-specific resource and prerequisites clearly guide when to use it. It lacks explicit when-not guidance, so a 4 is appropriate rather than 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?

Beyond annotations (destructiveHint: true, readOnlyHint: false, idempotentHint: true), the description discloses the non-destructive first call, the refusal behavior when permissions are lacking, the exact information the unconfirmed call returns, and the fact that the board, pins, followers, and collaborators are all affected. It also notes credits are 0 and a Pinterest connection is required, fully conveying the behavioral consequences.

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 every sentence adds critical information for a high-stakes destructive operation. It leads with the most important warning (permanent deletion) and then lays out the mandatory two-step process. The structure is logical and front-loaded; there is no filler or redundant wording.

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

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

Given the tool's complexity and irreversible nature, the description covers all necessary context: the confirmation flow, the permission limitation that makes update_pinterest_board a dead end, the exact data returned by the unconfirmed call, the credit cost, and the connection requirement. It leaves no gap for an agent to misuse the 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?

Even though the schema has 100% coverage, the description adds deep meaning: it explains that confirmName must match the exact reported name, confirmChildren must match the reported pin count, and why these echoes exist (proving the caller actually looked at the board). It also explains that the unconfirmed call returns the real name and pin count, making the parameters' purpose and validation logic clear beyond the schema's basic 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 states the specific verb (delete), resource (a Pinterest board), and the consequential scope (every pin on it is permanently deleted). It distinguishes itself from the sibling update_pinterest_board by explicitly warning not to use that tool for hiding the board, making it unmistakable which tool does what.

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 provides an explicit two-step protocol: first call without confirm to retrieve the board's name, pin count, followers, and collaborators; then call with confirm:true, confirmName, and confirmChildren after showing the user. It also steers away from a broken alternative (update_pinterest_board with privacy SECRET) and explains the dead end, giving clear when-to-use and when-not-to-use 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 mark destructiveHint=true but the description goes far beyond: it states 'Pinterest has no undelete and no archive', explains the first call is a dry run that returns real data, notes that the verdict is read from Pinterest and never taken from its 2xx, and details the impact on promoted ads. It also discloses the 'Needs Pinterest connected' prerequisite. This is rich behavioral context 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 lengthy but every sentence serves a purpose — no fluff. It front-loads the permanent nature and then logically walks through the workflow. It could be more skimmable with bullet points, but it's still efficient and well-organized for the critical safety information it must convey.

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, two-step confirmation tool with no output schema, the description is complete: it covers the safe initial call, what to expect from the response, the promoted-ad risk, the exact confirmation requirements, and the verification source. An agent has everything needed to call this correctly and 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%, but the description adds real meaning: it explains pinId comes from list_pinterest_pins, that confirm is 'REQUIRED true' for permanent deletion, and that confirmName is 'required once it has saves or has been promoted'. This clarifies conditional requirements and provenance that the schema alone doesn't 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?

The description opens with 'PERMANENTLY delete a Pin' — a specific verb and resource that immediately distinguishes this from sibling delete tools (e.g., delete_pinterest_board, delete_drive_file). It also clarifies the scope (Pin) and the permanent nature, leaving no ambiguity about what the tool does.

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 an explicit two-call workflow: first call without confirm to retrieve info, get user confirmation, then call with confirm:true and confirmName. It explains why this is needed (confirming deletion of SOMETHING doesn't prove the right Pin) and warns about promoted ads. This is direct, unambiguous usage guidance that an agent can follow step-by-step.

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 and idempotentHint. The description adds valuable context: it records a cross-device delete to prevent resurrection on sync, and explains the no-confirm rationale, going beyond annotation defaults.

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

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

Two compact sentences, front-loaded with the action, and every phrase earns its place—no filler or redundancy.

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 one-parameter delete, the description covers the action, id source, and behavioral nuances (sync, confirmation). It omits error handling, but that is not essential given the tool's simplicity and existing annotations.

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 fully describes the id parameter (100% coverage) with the same wording ('from list_playbooks'). The description reiterates that, adding no new semantics. Baseline 3 applies because the schema handles the documentation.

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 verb 'Delete' and the resource 'playbook' with the id sourced from list_playbooks. This precisely distinguishes it from other delete tools, which target different resources.

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 specifies the id must come from list_playbooks, implying a prerequisite for use. It also explains why no confirmation is needed (minor and re-creatable), but does not explicitly state when not to use the tool or name alternatives, so a slight gap remains.

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 annotations (destructiveHint=true, idempotentHint=true), the description explains critical behaviors: that Reddit returns an empty success for all calls (making verification necessary by re-reading), that comments are not deleted, that no undelete exists, and that credits are consumed. This far exceeds what annotations alone 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?

The description is long but each sentence carries essential safety information for a destructive operation. It is front-loaded with the permanence warning and does not waste words. It sacrifices brevity for completeness, which is appropriate given the irreversible nature.

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?

All necessary context is provided: the destructive nature, the confirmation flow, the conditional confirmName, the empty-response trap, the comment behavior, credit cost, and connection requirement. There is no output schema, so the description fully compensates. Nothing an agent needs 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining when confirm is required (always true) and the conditional need for confirmName ('once it has comments or a real score'). It also clarifies that postId accepts the fullname or permalink, though that is already in the schema. The added nuance for confirmName justifies 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 states a specific verb ('PERMANENTLY delete') and resource ('one of the connected account’s Reddit posts'), and explicitly notes the permanence. It clearly distinguishes from siblings like edit_reddit_post or post_to_reddit by focusing on deletion and the confirmation workflow.

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 an explicit two-step protocol: call without confirm to preview, then call with confirm:true after user consent, plus a conditional requirement for confirmName. It also instructs the agent to warn the user about comments remaining and the need for an unambiguous yes. This is concrete, actionable guidance with no ambiguity.

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 signal destructiveHint=true and idempotentHint=true. The description adds the context that this is a 'Minor + re-creatable' operation, so no confirmation is needed, and clarifies the constraint that built-in skills are excluded. This goes beyond the annotations by explaining the low risk and reversibility, which helps an agent decide when to invoke without confirmations.

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. The primary action and constraint are front-loaded in the first sentence, and the risk/re-confirmation note is efficiently placed in the second. Every clause contributes meaningful information—no fluff or redundancy.

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 delete operation with a single required parameter and no output schema, the description is fully adequate. It tells the agent what id to use, what can't be deleted, and the low risk level (no confirm needed). The inclusion of 're-creatable' addresses concerns about destructiveness. No essential information 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 the single parameter 'id', and its description already states 'the custom skill id (from list_skills)'. The tool description essentially repeats this information without adding new semantic details (e.g., format, constraints, or examples). Thus, the description adds no value beyond the schema, so it sits at 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 description states a specific action ('Delete'), a specific resource (workspace's CUSTOM skills), and clarifies that built-in skills/recipes cannot be deleted. It also references the source of the id (from list_skills), which distinguishes this from other delete_* siblings. This 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?

The description explicitly limits usage to custom skills and notes that built-in skills/recipes can't be deleted, providing a clear condition. It also directs the agent to list_skills to obtain the id. However, it doesn't explicitly name alternative tools or say 'do not use for built-in skills' in a direct command, though the implication is strong.

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 idempotentHint=true, but the description adds substantial detail: the two-step confirm flow, the intentional lack of preview due to Bot API limitations, the return behavior (Telegram's success answer rather than a read-back), and two vendor limits (48-hour window and channel permissions). It also notes 0 credits and connection requirement. This is far beyond annotations and transparent about what happens.

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 longer than typical, but every sentence carries essential information for a destructive tool with unique quirks. It front-loads the core action, then explains the confirm flow, preview limitations, vendor limits, and parameter mapping. It is dense but justified—not fluff. A minor trim could improve it, but it's well-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 destructive, side-effecting operation with no output schema, the description covers all necessary context: the confirm step, why no preview, return behavior, vendor limits, connection prerequisite, and how to obtain parameters. An agent has everything needed to call it correctly and manage user expectations. Nothing critical is missing.

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

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

Schema coverage is 100%, so baselines at 3. The description adds meaningful cross-references: chatId 'same as post_to_telegram', messageId 'the message id post_to_telegram returned', and clarifies the confirm parameter's role ('Call it WITHOUT confirm first') even though confirm is not in the required list in schema. This adds value beyond the schema's own 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 states the exact action: 'PERMANENTLY delete one message the bot posted to a Telegram chat.' This is specific (verb+resource+scope) and clearly distinguishes it from other delete tools like delete_reddit_post or delete_thread, which target different resources. It also mentions the bot-only scope, avoiding ambiguity with human messages.

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 usage context: it must be called without confirm first to get a user-facing sentence, and requires the chatId/messageId from post_to_telegram. It implicitly distinguishes from alternatives by focusing on bot-posted Telegram messages and references vendor limits. However, it doesn't explicitly say 'use this instead of X' or list exclusions, but the context is sufficient for an agent to select it 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 already declare destructiveHint=true and idempotentHint=true, but the description adds crucial context: the irreversibility, the confirmation flow, the quota refusal misinterpretation, and the lack of documentation about reply deletion. It even notes the preview outputs the post's metrics. This rich behavioral disclosure goes well beyond 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?

The description is long, but every sentence carries critical information for a destructive, confirmation-critical tool. It front-loads the irreversible nature and explains the preview-then-confirm flow efficiently. While not terse, the length is warranted by the complexity, 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?

The description is fully complete for this tool: it explains the calling convention, the confirmName condition, the quota limit and how to check it, the preview output, the caveat about replies, and even the credit cost. There is no output schema, but the description conveys what the response contains. No essential operational detail 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% and each parameter already has a clear description. The description adds extra meaning by explaining the rationale behind confirmName (preventing blind deletion of wrong posts) and clarifying that postId comes from list_threads_posts. It also clarifies confirm's strict requirement. This adds value beyond the schema, though the schema already covers the basics, so a 4 is justified.

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 precisely that the tool permanently deletes a Threads post, naming the resource and the destructive action. It clearly differentiates from sibling tools like delete_x_post or delete_bluesky_post by specifying 'Threads'. The purpose is unambiguous and action-oriented.

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 an explicit two-step workflow: call without confirm to preview, then with confirm:true after explicit user consent. It also specifies when confirmName is required and warns about the 100-deletion daily quota, referencing threads_publishing_limit. This is exceptional guidance that leaves no ambiguity about when and how to invoke the 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 declare destructiveHint true and idempotentHint true, but the description goes far beyond: it explains that ads already built keep running, no new ads can be built until a fresh code exists, TikTok outright refuses while any campaign/ad is active, calling without confirm changes nothing and returns a descriptive sentence, and the read-back inversion (proof of success is absence of code; leftover code is reported as 'not confirmed'). This is rich behavioral context that fully complements 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 long but every sentence carries essential information: confirm gating, impact on existing ads, the active-ad refusal, the no-op behavior, the read-back inversion, and the auth requirement. It is front-loaded with the purpose and then details consequences. While dense, it is not padded; the length is justified by the tool's complexity.

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, confirm-gated operation with external dependencies, the description covers the essential context: the confirm requirement, the active-ad precondition, the no-op behavior, the auth requirement (referencing tiktok_account_status), and the read-back inversion. There is no output schema, but the read-back inversion clarifies what to expect. Nothing an agent needs to call this correctly appears to be 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 meaning beyond the schema by explaining the confirm parameter's behavior: it is required true, calling without it is a no-op that returns a descriptive sentence, and it must be true to actually delete. The itemId is self-explanatory but the confirm semantics are significantly clarified.

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 a clear specific verb and resource: 'Delete the Spark-Ads authorization code for a post the authorized account owns.' This precisely identifies the operation and scope, and the name itself distinguishes it from the get/set/extend siblings. There is no ambiguity about what the tool does.

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 concrete usage guidance: it explains the confirm-gating protocol (call without confirm first to see the effect), the prerequisite that active campaigns/ads must be paused first (TikTok refuses otherwise), and the read-back inversion for interpreting results. It does not explicitly name the set_tiktok_post_ad_authorization alternative, but the context makes it obvious and the guidance is strong overall.

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 readOnlyHint=false, but the description adds crucial behavioral details: the all-languages blast radius, the two-step confirm flow, the need for confirmName to avoid targeting the wrong template, and that the actual outcome is verified via a re-read rather than the 200 status. It also mentions the 0-credit cost. The description goes 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?

The description is dense but every sentence carries essential information. It front-loads the permanent deletion and wide blast radius, then logically walks through the two-phase call, the confirmation requirement, and the verification step. No fluff; it earns its length.

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 this is a destructive action with no output schema, the description covers all necessary context: what happens on deletion, how to scope it correctly, what happens if you delete incorrectly, and how to interpret the result (re-read instead of 200). It even notes the cost. Nothing an agent needs 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?

Although schema covers all parameters (100% coverage), the description adds value for confirmName by clarising its purpose: it must be set to the template's exact name and is required alongside confirm. It explains that a generic yes is insufficient, preventing misuse. This is meaningful enhancement beyond the schema's basic 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 clearly states the tool 'PERMANENTLY delete a WhatsApp message template' — a specific verb and resource. It further distinguishes the behavior by noting 'META DELETES EVERY LANGUAGE OF A NAME AT ONCE', which is a unique scope detail. No sibling tool serves this exact function, so it stands alone clearly.

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 step-by-step usage: call without confirm first to preview, get user approval, then call again with confirm:true and confirmName matching the exact name. It warns that a generic confirmation does not prove the right template was targeted. It also notes consequences (messages refused after deletion) and the verification re-read from Meta.

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 include destructiveHint:true and idempotentHint:true, but the description adds crucial context: 'CANNOT be undone' and the need to confirm with the user. It also discloses that credits are charged. This goes beyond the annotations, providing operational details without 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?

The description is extremely concise—two sentences—with the most critical warning (irreversibility and user confirmation) front-loaded. Every sentence earns its place, covering the key operational, cost, and prerequisite information without 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 single-parameter destructive tool with no output schema, this description is quite complete. It covers the action, irreversibility, confirmation need, credit cost, and connection prerequisite. It does not describe error handling or success responses, but that is minor given the simplicity and absence of an output 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?

The schema description coverage is 100% and already explains that 'id' is the numeric post id from the URL. The tool description does not add further parameter-specific details, so the baseline of 3 applies; 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 description states a specific verb ('delete') and resource ('one of the connected account’s posts on X'), clearly distinguishing it from sibling delete tools for other platforms (delete_bluesky_post, delete_reddit_post, etc.). It also clarifies the scope (connected account's own posts), leaving no ambiguity about what it operates on.

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 explicitly instructs the agent to confirm the exact post with the user first due to irreversibility, and mentions the credit cost and prerequisite (needs X connected). This gives clear guidance on when and how to use the tool, including cautions before invoking 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 already mark destructiveHint: true, but the description goes far beyond that by explaining the exact consequence: deleting the job discards every accumulated daily CSV, and a replacement job only backfills 30 days. It also clarifies the non-destructive first call returns real job data. No contradiction with annotations; this adds significant nuance.

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 longer than necessary but every sentence carries weight: purpose, irreversibility warning, confirm flow, and prerequisite. It is front-loaded with the core verb and then layered with essential details. No fluff, though slightly dense.

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

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

Given the destructive nature and two-step confirm, the description covers all needed behavior: the consequence, the confirm sequence, what the first call returns, and the channel requirement. No output schema exists, but the description explains the response of the first call. An agent has everything 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?

Schema covers both parameters (jobId from list_youtube_report_jobs, confirm boolean). The description adds crucial semantics for confirm by explicitly describing the two-step usage, which is not fully captured in the schema. Since schema coverage is 100% and description provides extra context, a score above baseline is warranted.

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 a clear verb+resource: 'Stop a YouTube bulk reporting job.' It distinguishes this from sibling delete tools (like delete_youtube_video) by naming the specific resource type (bulk reporting job) and later clarifies the job is the history, making the scope 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 instructs the two-step confirmation flow: call without confirm to retrieve job details, show the user, then call again with confirm:true. Also notes the required connected YouTube channel. This leaves no ambiguity about when and how to invoke the tool, and implicitly warns against using it without confirmation.

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 goes far beyond annotations (which already note destructiveHint=true) by explaining that YouTube has no trash, that views/comments/links are lost, that the unconfirmed call returns real details, and why confirmTitle is required to prevent blind deletion of the wrong video. No contradiction with annotations; instead it enriches them significantly.

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?

Despite being long, the description is tightly structured: it opens with the core warning, then the confirmation workflow, alternative, source of ID, credits, and prerequisite. Every sentence serves a purpose—no fluff, and the most critical info (irreversibility) 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 tool with conditional parameters and a confirmation flow, the description covers everything an agent needs: the required two-step call, when confirmTitle is needed, the alternative for reversible privacy change, the source of videoId, and the account prerequisite. No information is missing 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 100%, but the description still adds value for each parameter: confirm must be true, confirmTitle is required when the video is public or has views/comments, and videoId comes from list_youtube_videos. It also explains the rationale behind confirmTitle, which is not in the schema.

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

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

The description uses a specific verb ('delete') and resource ('video from the connected YouTube channel') and distinguishes itself from the sibling update_youtube_video by noting the reversible privacy option. It states exactly what the tool does and what it does not do, making it 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 provides when to use this tool (permanent deletion) versus the reversible alternative update_youtube_video(privacy:'private'). It also details the two-step confirmation flow, instructing the agent to call without confirm first, show the user the real details, then call with confirm:true and a conditional confirmTitle. This is clear guidance for correct invocation.

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 readOnlyHint/openWorldHint/destructiveHint, so the description carries the burden — and it delivers richly. It discloses the four refusal guardrails (too early, unmeasured, no baseline, nothing wrong), the platform data limitations (Facebook reach cutoff, Reddit no impressions, Google Business nothing per-post), the crediting/attribution behavior, and the 'nothing here needs fixing' honesty clause. This exceeds what any annotation could 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?

Every sentence carries information — the problem taxonomy, the four refusals, the platform quirks, the converting rule, the 'print summary verbatim' output contract. However, it is a dense wall of all-caps prose; the four refusals are inlined as a numbered run rather than cleanly structured, and the opening hook ('WHAT TO FIX NEXT, post by post — and the tool that fixes it') is somewhat muddled as a lead-in. It earns its length but not its formatting.

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 with this diagnostic complexity — three problem rungs, four refusal cases, cross-platform data quirks, and a conditional offer path — the description is remarkably complete. It covers the decision logic, the input conditions, the output contract (print summary verbatim, attribution in output), and credit cost. With no output schema present, the summary-verbatim instruction partially compensates; a slightly more explicit description of the output shape would push this to 5.

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 each parameter's schema description is already good. But the tool description adds genuine value beyond the schema: it explains the converting:false trigger condition (only when the user explicitly states non-conversion), and clarifies that limit only caps diagnosis count while 'the baseline is always built from EVERY post recorded.' This reinforces and extends the schema rather than merely restating 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?

The description states a specific verb+resource ('tells you what is WRONG with a given post and where the next edit goes') and explicitly contrasts itself with post_performance, which 'tells you which hook is AHEAD.' This gives the agent a precise mental model of the tool's job and how it differs from its closest sibling 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?

The opening frames the tool against post_performance ('this tells you what is WRONG...'), establishing a clear when-to-use context. It also states an explicit conditional: the offer rung 'runs ONLY when the user tells you they are not converting and you pass converting:false.' It doesn't enumerate every sibling exclusion, but the named differentiation and the conditional trigger provide solid guidance for a diagnostic 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?

The description goes far beyond the annotations, disclosing that credentials are always dropped, tools stop immediately, published posts are unaffected, revocation depends on provider, some providers lack revocation endpoints, and reconnecting requires a browser. This rich behavioral context helps the agent set user expectations and avoid promising actions it cannot complete.

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 every sentence contributes essential information—consequences, provider variability, and the undoing limitation. It is front-loaded with the main purpose and effects, and the structure flows logically from effect to caveat to action. While dense, it avoids redundancy.

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?

Despite lacking an output schema, the description covers what the agent needs: the unconfirmed call reports revocation status, the exact provider ID source, and the confirm requirement. It also instructs the agent to relay info verbatim, ensuring correct usage. No critical operational detail 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 meaningful detail: provider must match list_connectors exactly, and confirm must be true because reconnecting needs the user's browser. This clarifies the semantics beyond the schema's terse field 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 explicitly states the action ('Disconnect a third-party account from this workspace') and enumerates the supported providers, distinguishing it clearly from siblings like leave_connector. The verb and resource are 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 provides clear context on when to use the tool, including the prerequisite of calling list_connectors for provider IDs and the need for user confirmation. It does not explicitly exclude alternatives like leave_connector, but it names list_connectors as the supporting tool, which is sufficient guidance for selecting 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 declare openWorldHint=true and non-readOnly, and the description adds valuable behavioral context: the domain resolution pitfall (bala.com example), the '0 ScrapeCreators credits' cost information, the save behavior (default saves only when no brand exists), and the explicit limitation that the tool cannot ask the user. This goes well beyond the annotations, though it doesn't fully describe the drafting mechanics (e.g., how scraping works) or all side effects.

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, followed by the critical warning and verification directive. It is a bit long but every sentence carries weight—there is no fluff. The structure leads with the primary use case, then the risk, then the mitigation. It could be slightly more concise, but the length is justified by the safety warning.

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 no output schema, the description compensates by describing the output shape and the verification step. It covers how to handle the save parameter and the ambiguity of domain resolution. However, it does not explicitly state that at least one of the source inputs (domain, description, socialHandle) is required, even though the schema has zero required parameters. This could leave an agent unsure about what to pass. Otherwise, it is fairly complete for a tool with this complexity.

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 five parameters. The description adds important semantics beyond the schema: it maps the input options (domain/description/socialHandle+platform) to the overall workflow, and explicitly elaborates on the `save` parameter ('pass save:false until confirmed'), which is not just a boolean but has conditional behavior. This enriches the parameter meaning beyond the schema 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 description explicitly states the tool's action ('Onboard a brand profile'), the resource (brand profile), the input sources (website domain, free-text description, or social handle), and the output shape ({name, products, logo,…}). It also mentions downstream usage with plan_ad/generate, making the purpose unambiguous and distinct from sibling brand tools like create_brand or get_brand.

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 on when to use it (onboarding from unstructured sources) and includes a critical verification step: 'Before spending any credits on research or renders, VERIFY the returned name (and summary) match the brand the user meant.' It also advises using save:false until confirmed. However, it does not explicitly name alternative tools like create_brand or update_brand, so the selection guidance is implicit 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?

The description discloses key behavioral facts beyond the annotations: the operation is paid, it automatically transcribes the source audio, it re-voices and lip-syncs onto the same footage, and it returns a served URL. It also notes the script parameter overrides the auto-transcript. Since annotations only indicate a mutating, non-destructive operation, this description adds significant context about cost, process, and output, with no 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?

The description is efficient and front-loaded with the core purpose, then adds usage and cost details. It is a bit dense but every sentence serves a purpose: it explains the process, the automatic transcription, the override, the paid nature, and the return value. It is well-structured, though slightly longer than strictly necessary.

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 with four parameters and no output schema, the description covers the essential usage context: the input requirements (video, language), the automatic transcription, the override option, cost, and return format. It does not mention potential errors or prerequisites like supported video formats, but that is not critical. Overall, it is sufficiently complete for an agent 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 all four parameters well. The description reinforces the automatic transcription behavior and the script override, but this information is already present in the schema for each parameter. The description does not add new meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description states a specific verb ('localize'), resource ('finished video'), and the key distinction ('WITHOUT re-rendering it'), making it clear this is a dubbing tool rather than a general video editor. The mention of

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 for using the tool: it is for localizing a finished video into another language. It instructs the agent to 'just pass the video and the language' and explains when to use the optional script override. It does not explicitly name alternative tools, but the 'WITHOUT re-rendering' phrasing implicitly contrasts it with editing tools, and the paid note adds a cost consideration. This is sufficient for routing, though explicit 'when not to use' guidance would be stronger.

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 indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable behavioral detail: the copy is independent, a genuinely new post, and publishes even where the original already did. These details go beyond the annotations and clarify side effects, though it doesn't cover every potential caveat (e.g., permissions, rate limits).

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 five sentences long but each provides essential information: purpose, attributes copied and overridable, scheduling options, independence of the copy, and the alternative tool. It is well-structured with the most critical details front-loaded, though slightly verbose. For a tool with 18 parameters, this length is justified.

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 covers the core purpose, usage scenarios, behavioral guarantees, overrides, scheduling options, and alternatives. It uses the schema description for parameter details (e.g., id from list_scheduled) and the output is not schema-defined, so return value is not explained but acceptable. Given the tool's complexity, it is nearly complete, with minor gaps like prerequisites or error handling.

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

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

Schema coverage is 72%, so most parameters have descriptions. The description adds value by clarifying that any of the copied fields (caption, media, etc.) can be overridden in the same call, which explains the role of override parameters like `message`, `title`, etc. This is helpful beyond the schema's individual field descriptions, though it doesn't elaborate on all 18 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 clearly states the verb (copy) and the resource (a scheduled or published post into a new queued post). It differentiates from retry_scheduled by specifying that this tool duplicates posts while retry_scheduled re-fires failed channels. The purpose is unambiguous and distinct from sibling tools.

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

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

It explicitly explains when to use this tool (run a creative again, reuse a post, re-send after it went out) and provides a clear exclusion: 'To re-fire only the channels that FAILED, use retry_scheduled instead.' It also explains the `at` and `useQueue` options for scheduling, giving agents context on how to invoke 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 establish non-read-only and non-destructive behavior, but the description adds substantial context: it explains that the result is read back from Reddit so an accepted edit that didn't apply is reported as 'NOT confirmed', it discloses the 0-credit cost and the requirement of a connected Reddit account, and it details the three unsupported scenarios with consequences. This goes well beyond what the annotations alone 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?

The description is long but every sentence carries weight: it front-loads the key restriction (title immutability), then lists the other constraints, and finishes with verification and cost. It is information-dense without redundancy, though slightly verbose for a tool description. Given the number of edge cases, the length is justified, so a 4 is reasonable.

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 is exceptionally complete: it covers prerequisites (connected account, 0 credits), behavioral verification (NOT confirmed), and all three unsupported cases with remedies. The description even explains what happens on failure (delete and resubmit, losing score/age/thread). Nothing an agent needs to call this tool correctly seems 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 describes both parameters at 100% coverage: `postId` accepts the id, fullname, or permalink, and `text` is the replacement markdown. The description does not add new parameter-specific semantics; it reiterates the purpose context (e.g., fixing a dead link) but not additional detail about parameter formats or values. With full schema coverage, a baseline of 3 is appropriate.

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

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

The description opens with a clear, specific verb–resource pair: 'Rewrite the BODY of one of the connected account’s Reddit TEXT posts'. It distinguishes from siblings by explicitly restricting to text posts and by naming the three limitations (title, link posts, deleted posts). The title reinforces the same purpose, leaving no ambiguity about what this tool does.

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 when to use this tool (for text posts needing body corrections) and when not to: title changes, link posts, and deleted posts are all ruled out, with the alternative 'delete and submit again' spelled out. It also notes that an edit might not apply and must be verified, guiding the agent to check the result. No other tool is named, but the constraints make the appropriate use case crystal-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 are sparse (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description carries most of the disclosure burden. It discloses that the operation keeps the original motion/timing, is a paid render, operates best on short clips, and returns the served URL of the result. It could additionally note idempotency or failure behaviors, but the disclosed traits (cost, preservation of motion, length range, output URL) are substantial beyond 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?

The core scoping ('KEEPS original motion, changes subject/setting/style') is front-loaded, followed by usage examples and then a compact series of exclusions. It is long, but this density is justified by the large sibling set it must disambiguate against (post_edit, generate_video, render_ad, dub_video, recast_motion). A few phrases like 'so the edit restores the REAL thing' could be trimmed, but nothing 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?

For a 4-parameter tool with no output schema and sparse annotations, the description provides the key operational context: what the tool preserves, what it changes, best-length constraint, cost implication, and the result URL. It omits explicit pagination/timeout/credit-exactness details and does not restate the return value beyond the URL, but for this tool's complexity the coverage 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 description coverage is 100%, so the schema already documents all four parameters thoroughly, including the elements object's 'frontal' and 'refs' fields and the keepAudio default. The description adds marginal value by explaining the purpose of 'elements' ('so the edit restores the REAL thing') and the silent-return behavior of keepAudio=false, but the heavy lifting is done by the schema — earning the baseline 3.

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

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

Phrased with an explicit verb and resource ('EDIT/transform an existing video clip'), a precise definition of the video-to-video behavior ('KEEPS the original motion, timing and edit, changes the subject/setting/style'), and concrete examples ('change the background to a city', 'restyle it as claymation'). It distinguishes itself unambiguously from generate_video, post_edit, and dub_video, whose names it shares the domain with.

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 at least four alternatives and the exact conditions that select each: post_edit for mechanical cuts/trims (with cost and credit hints), generate_video/render_ad for new videos, dub_video for translation, and recast_motion for face transfer. Also bounds applicability ('Best on 3–10s clips'). No inference is required from the agent.

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 indicate idempotentHint=true and destructiveHint=false, but the description goes further by explaining behavior on different clients (stdio/CLI vs ChatGPT) and how the tool reports outcomes in its reply rather than falsely reporting success. It also clarifies that nothing is turned off and explains why certain groups are held out (size). This adds significant context beyond the annotations without 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?

The description is long but every sentence contributes value: it covers client behavior, default roster, explicit triggers, and group list. It is well-structured with bold calls and clear examples. However, it is verbose enough that a more concise version could convey the same information with less text, though the complexity of the topic justifies the length.

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

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

Given the tool's simple parameter but complex behavior across clients and many groups, the description is thorough. It explains the default roster, why certain groups are excluded, how to handle different client types, and the effect on the reply. No critical information is missing for an agent to correctly invoke 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?

While the schema describes the 'groups' parameter as an array of strings, the description adds full meaning by enumerating valid group names ('core, research, create, channels, analytics, ads, files, workspace — or "all"') and explaining the implications of using specific groups (e.g., ads for ad campaigns). It also notes that unknown names are refused by name, which is behavior not in the schema. This makes the parameter semantics clear and actionable.

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 immediately states the tool's function: 'Switch on a group of tools that is not in this session's roster.' It uses a specific verb and resource, and clearly differentiates itself from siblings by focusing on tool enablement, which is unique among the sibling list. There is no ambiguity about what the tool does.

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 explicit conditions for use, including specific triggers like 'If the user asks to build, budget, target, report on or change an ad campaign... call enable_tools({groups:['ads']})'. It also names an alternative method ('?tools=all' on the server URL) and explains when it doesn't work (hosts that fixed their roster at connect time). This gives full guidance on when to use this tool versus 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?

The description discloses that the tool is read-only and costs 0 credits, and that occurrences are redacted, adding behavioral context beyond the annotations which already set readOnlyHint=true and destructiveHint=false. It does not contradict annotations and provides useful details about data privacy and cost.

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, front-loads the core action ('One error group in full by fingerprint'), and packs essential details (fields, redaction, input echo, read-only, 0 credits) without waste. Every phrase 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, one-parameter read-only tool with no output schema, the description sufficiently conveys what is returned, the provenance of the fingerprint, and cost implications. It lacks only minor details like handling of missing fingerprints, but these are not essential 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?

The schema fully documents the single parameter 'fingerprint' with its source ('the fp value from list_errors'), so schema coverage is 100%. The description only mirrors this by saying 'by fingerprint (from list_errors)' without adding additional meaning, staying at the baseline for high schema coverage.

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 retrieves a single error group by fingerprint, enumerates the content (every field plus redacted occurrences with status, connector, job id, workspace, and input echo), and explicitly references the sibling list_errors as the source. This distinguishes it from listing tools and other detail tools, leaving no ambiguity about its function.

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 by referencing 'from list_errors' and framing the result as 'what makes a bug reproducible', suggesting it is used for debugging after obtaining a fingerprint. However, it does not explicitly state when to use it versus alternatives or mention when not to use it, lacking an explicit routing rule.

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 multiple behavioral traits beyond the annotations: it always creates a NEW deck, it cannot modify user-owned decks due to scope, it gracefully handles expired ad-library links (embeds text instead and reports count), and it returns a presentation id + URL. Annotations only provide binary hints; this description enriches the agent's mental model substantially.

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 somewhat lengthy but each sentence earns its place: the first states the core purpose, the second gives marketing context, the third explains the new-deck limitation, the fourth covers the expired-link edge case, and the fifth states the connection requirement. It is well-structured and front-loaded, though a sentence or two could be trimmed without losing 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 complex tool that creates Google Slides decks, the description covers the return value (presentation id + URL), the behavioral edge cases (expired links, new-deck only), and the prerequisite (Drive connected). No output schema exists, so the description carries the full burden of explaining what the agent receives, and it does so completely.

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 each parameter has a description in the schema (limit range/default, title default, collection by name/id). The tool description restates these facts without adding new meaning beyond what the schema already provides, so it stays at the baseline 3.

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

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

The description opens with a specific verb and resource ('Turn a SWIPEFILE COLLECTION into a real Google Slides deck') and enumerates exactly what each slide carries (creative, brand, copy, run dates, platform). It also contrasts with the prior JSON-only export, making the tool's distinct value clear against siblings like save_to_drive and update_drive_file.

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 clearly frames when to use this tool—for presenting a collection to a client/team, contrasting with the old JSON export—and warns that it cannot touch existing decks due to the drive.file scope, implying when not to use it. It also states the prerequisite (Google Drive connected). It does not name a specific alternative tool, but the context is strong enough for an agent to decide.

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 (non-read-only, open-world, non-destructive), the description discloses critical behavioral traits: days are added not set (with a concrete example), it regenerates the code if deleted, TikTok's response body is empty so it reads back the new window, and it requires existing authorization. This gives the agent a full picture of side effects and nuances.

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 longer than average but every sentence is informative. It front-loads the core purpose, uses capitalization to emphasize the add-not-set rule, and covers prerequisites and response behavior. While slightly verbose, the density of critical warnings justifies the length.

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 with two parameters and no output schema, the description fully equips an agent: it explains the add-not-set semantics, allowed values, prerequisite of existing authorization, the empty-response issue and how the tool compensates, and the need for account authorization. There is no missing information that would cause incorrect 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?

The input schema already provides full coverage (100%) of both parameters, including the 'ADDED to whatever is left' note for authorizationDays and the allowed values. The description reiterates this and even adds an example, but it doesn't introduce new meaning beyond the schema. With high schema coverage, the baseline is 3, and the description only confirms rather than augments.

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 a specific action: extending the Spark-Ad authorization duration for a post, and also regenerates the code if deleted. It distinguishes itself from sibling tools like set_tiktok_post_ad_authorization (which enables auth) and delete_tiktok_post_ad_authorization (which removes it) by clarifying this tool only extends existing authorization.

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 clear usage context: it must be used after authorization is already ON (referencing set_tiktok_post_ad_authorization), and it requires TikTok account authorization (pointing to tiktok_account_status). It does not explicitly contrast with get_tiktok_post_ad_authorization, but the purpose is unambiguous. The 'must be one of 7, 30, 60, 180, 365' constraint is clearly stated.

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

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

Annotations already indicate readOnlyHint=false (mutating), openWorldHint=true (external interaction), and idempotentHint=true. The description adds context beyond these: it's FREE and keyless, requires a CONFIDENT match, returns 0 on ambiguous/unknown apps, saves durable URLs on success, and indicates the agent should relay failures plainly. 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 description is front-loaded with the core action and usage condition, then expands on parameters, cost, and behaviors. It's dense but every sentence carries essential information; a slight trimming of the 'REAL' emphasis could tighten it, but it remains well-structured and not verbose.

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?

Despite no output schema, the description fully explains the tool's behavior: what it returns on success (durable URLs saved), what happens on failure (0 screens, saves nothing), and how the agent should handle that. It also covers the default parameter behavior and prerequisites (brand with 0–1 screens), making it complete for an agent to decide and execute 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 input schema already has 100% coverage with descriptive text for appName ('the app's name to look up on the App Store — defaults to the saved brand's name') and brandId ('a brand id/name from list_brands to save the screens onto; omit to use the active brand'). The description re-states the default but adds no new parameter syntax or details, 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 a clear action with a specific resource: 'Pull an APP brand's REAL App Store screenshots into the workspace brand.' It explicitly mentions the use case with make_template_ad(template:'app-ui-tour') and the user's phrasing, differentiating it from generic asset fetching.

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 explicitly tells when to use: 'Use when the brand has 0–1 app screens on file and you want make_template_ad(template:'app-ui-tour'), or the user asks to pull my app's screenshots.' It also clarifies edge behavior (ambiguous app returns 0 screens) and advises not to retry with guesses, leaving no ambiguity about 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 already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the core behavior of resolving a reference into two URLs, which is useful context beyond the annotations. It clearly communicates the operation without overspecifying, and there is no 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?

The description is a single, front-loaded sentence that states the action and output immediately. There is zero waste, and the critical nuance (accepts /generated/ paths or any URL) is included. It is appropriately sized for the task.

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 no output schema, the description explicitly defines the return values (absolute URL and download URL). The input requirements are covered by the schema, and the annotations establish safety. For a simple resolver, this fully equips an agent to call the tool correctly without missing information.

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 (url and name), so the schema already documents them. The description repeats the purpose but adds no new meaning about parameter formats or usage beyond what the schema states. With full schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Resolve'), a clear resource ('a generated asset reference'), and the exact output ('clickable absolute URL + direct download URL'). It distinguishes itself from the many sibling tools by describing a unique transformation (path/URL resolution) that no other sibling appears to do, so an agent can easily tell it apart.

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 what the tool does but gives no guidance on when to use it over alternatives. There are no explicit conditions, exclusions, or references to sibling tools for similar tasks. In a large set of sibling tools, the agent must infer usage solely from the purpose, which is not sufficient per the rubric.

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 it as read-only and non-destructive. The description adds that it is grounded by web search and costs 0 ScrapeCreators credits, which provides additional behavioral context. However, it does not describe output format or any rate limits.

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 concise, starting with the core purpose, then detailing modes and cost. Each sentence adds value and there is no 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?

Given the tool's simplicity (2 params, no output schema), the description covers the input and modes but does not specify the return format or any potential limitations. It mentions cost but not error handling. It is adequate but not exhaustive.

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 fully describes both parameters (domain and mode) with clear descriptions. The tool description essentially repeats the mode explanation and adds no new parameter semantics. Baseline for high schema coverage is 3, and no additional info is 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 clearly states the tool discovers a brand's competitor/similar/adjacent brands from its domain, and mentions it is grounded by web search. It is specific enough to distinguish from sibling tools like competitor_teardown or pull_competitor_ads, though it does not explicitly name them.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It lists modes but does not clarify when to choose this over competitor_teardown or pull_competitor_ads. The context is implied but not stated.

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