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

Annotations already declare readOnlyHint true, openWorldHint true, and destructiveHint false. The description adds useful behavioral context beyond this: it mentions 'Costs ~a transcription call,' which warns about resource consumption. It also specifies the outputs (transcript, beat list, timestamps) without contradicting any annotation.

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, no fluff. Front-loaded with the core function, then adds usage context and cost. Every sentence earns its place, and the structure is 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 tool with a single parameter and no output schema, the description adequately explains the return value (transcript, beat list, duration, timestamps) and the expected use case. It even mentions cost, which helps the agent plan. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the parameter is already documented ('the video URL...'). The description does not add extra meaning about the parameter itself. Baseline of 3 applies because the schema fully covers 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?

Description states a specific verb ('Break down') and resource ('video ad'), and precisely lists what it produces: verbatim transcript, beat list, duration, and sampled frame timestamps. It clearly distinguishes itself from sibling tools like finish_video or clip_video, which have different purposes.

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 context: 'Use to study a reference/competitor ad before remixing its structure.' This clearly indicates when to use it. It does not mention alternatives or when not to use, but for a single-purpose analysis tool, the guidance 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 readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds the 'Hermoso can reach' limitation and clarifies the non-destructive nature by saying 'append', but doesn't disclose error behavior or side effects. With openWorldHint=true, the description adequately supplements but doesn't go beyond what annotations expect.

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?

Single sentence that front-loads the core action and scope. The phrase 'Hermoso can reach' is slightly verbose but necessary to convey the limitation. Minimal waste; could be trimmed slightly but is 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 two parameters and no output schema, the description covers the essentials: what it does, how to get the ID, and the reachability constraint. Error cases are not described, but given the low complexity and annotations, this is 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 covers 100% of parameters, but the description adds meaning beyond schema. The schema's documentId description only mentions 'from create_doc', while the tool description extends it to include 'list_drive_files', providing a more accurate and complete source. Text description is straightforward.

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?

Clearly states the verb 'append' and resource 'Google Doc', and further narrows scope to docs Hermoso can reach (created or user-provided). Distinguishes from siblings like create_doc, update_doc, and read_doc by focusing on appending to the end and specifying how to obtain the documentId.

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 guidance on when to use: when appending to the end of a reachable doc, and offers two methods to source the documentId (from create_doc or list_drive_files). It does not explicitly exclude alternatives like update_doc, but the scope is clear enough for correct selection.

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

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

Annotations already indicate readOnlyHint=false and idempotentHint=false, signaling a mutating, non-idempotent operation. The description adds the reachability constraint (created vs. user-shared sheets) which is valuable context beyond annotations. No contradiction exists, and it explains the source of valid spreadsheet IDs.

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 fluff. It front-loads the core purpose and then delivers key details about eligibility and the rows format. Every phrase contributes to understanding, making it highly concise 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 append tool with three parameters and no output schema, the description covers the essential information: what it does, which sheets are valid, how to obtain IDs, and the format of rows. The optional range parameter is documented in the schema, so the description need not repeat it. It is complete enough 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% for all parameters, giving a baseline of 3. The description adds meaningful context beyond the schema by explaining that spreadsheetId can come from create_sheet or list_drive_files, which clarifies the allowed values. For 'rows', it repeats the schema description, but the added id-source info 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 'Append rows' and the resource 'Google Sheet', and explicitly defines the set of reachable sheets (created by Hermoso or handed over via file picker). This distinguishes it from sibling tools like update_sheet, clear_sheet_range, and read_sheet, making the tool's 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?

It gives concrete guidance on how to obtain the spreadsheetId — via create_sheet or list_drive_files — and specifies the condition of which sheets are eligible. It does not explicitly state when not to use the tool versus alternatives, but the tool name and purpose make that distinction clear, so the guidance is adequate.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses the dry-run default and confirmation requirement, the cost quoting, the resumability, and the crucial caveat that imported posts are weaker evidence, labelled 'backfilled', with hooks only recovered under specific conditions. It also warns 'Never guess a hook from a caption.' This is rich, honest behavioral disclosure that goes well beyond the structured annotations.

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

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

The description is dense but every sentence earns its place. It front-loads the core purpose, then systematically covers supported channels, exclusions with reasons, the dry-run/confirm/resume workflow, and the evidence caveat. No filler or repetition; the length is justified by the tool's complexity. The structure uses punctuation effectively to keep it readable.

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 5 parameters, no output schema, and nuanced behavior, the description provides everything an agent needs to call it correctly: what it does, which channels work, why others don't, the default dry-run behavior, how to confirm, how to resume with a cursor, and what happens to imported posts regarding evidence. Even the return value is hinted at ('tells you how many posts it found and what reading them will cost'). Nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. However, the description adds essential contextual meaning: it explains that limit caps the page size (default 50, max 200), that cursor is for resuming, and that confirm:true is the flag to actually import while omitting it triggers a dry run. It also clarifies accountRef for multiple accounts. This is meaningful added value beyond the schema fields.

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 pair: 'Import this brand's PAST posts from a channel into the performance record.' It names the exact purpose (feeding 'which hook works' with history) and lists all supported channels, which distinguishes it from posting, insight, and metrics tools in the sibling set. There is no ambiguity about what this tool accomplishes.

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 workflow guidance: it runs as a DRY RUN by default, requires confirm:true to import, and uses the returned cursor to resume. It also states the intended scenario ('draw on history rather than only on what was published since Hermoso started recording'), and even explains why certain channels are excluded, which prevents inappropriate attempts. This is far above the minimum.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, free'. It adds critical behavioral context beyond annotations: the price field nuance (billing per plan.period, not monthlyUsd), the member-specific visibility limitation (billingScope:'member'), and the instruction to never tell a member there is no card because it cannot be seen. This is exactly the kind of hidden behavior agents need to know.

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 earns its place: it leads with the core purpose, then details the specific fields, then the critical usage caveats. The shared-workspace warning and the instruction about not misreporting card status are essential to correct agent behavior. It is structured front-loaded and thorough 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?

Given zero required parameters and no output schema, the description must fully explain what the tool returns and any caveats. It covers the plan, balance, auto-reload, card, admin rights, and the nuanced member view. It also explains when to use it relative to other tools. Nothing an agent needs to call it correctly is missing.

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

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

There are zero parameters, so the schema carries no parameter documentation. Per the rubric, 0 params gives a baseline of 4. The description does not need to add parameter meaning since there are none, and it correctly focuses on the output and usage context 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 clear verb and resource: 'Show this account's billing at a glance' and enumerates the specific data returned (plan id/label/price, credit balance, auto-reload, card on file, admin rights). It explicitly distinguishes itself from sibling tools by saying to call it before upgrade_plan / set_auto_reload, 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 explicitly tells the agent when to use it: 'Call it before upgrade_plan / set_auto_reload' and explains that members have read-only billing, so they cannot change billing. It also provides conditional guidance for shared team workspaces, telling the agent exactly what a member sees and how to answer honestly. This is explicit 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 goes far beyond the annotations' readOnlyHint=false and idempotentHint=false: it discloses the two-step quote-then-confirm flow, the 10-minute quote_token validity, that the charge hits the saved card instantly with no redirect, that a first purchase saves the card, the requirement of billing-admin rights, and the HTTP 402 MPP challenge on the machine lane. The 'retried confirm idempotent' note refines (rather than contradicts) idempotentHint=false, since it specifies that only the token-bound confirm step is idempotent while the tool overall is not.

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 it is front-loaded with the simplest entry point ('Call with no argument to list the available packs') and flows logically through the three purchase paths plus the auto-reload alternative. Every sentence carries distinct information needed to avoid wrongly charging a human's card or selecting the wrong payment lane; the density is justified by the payment-flow 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?

There is no output schema, so the description carries the full burden of conveying return values — and it does: the pack listing format (id · credits · price), the quote returning a quote_token, the Stripe checkout URL, and the HTTP 402 MPP challenge. It also covers prerequisites (saved card, billing-admin rights, machine credential availability) and the fallback (set_auto_reload). Nothing an agent needs to invoke this tool correctly or choose a path 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 and the schema already documents each parameter's individual meaning. The description adds orchestration semantics beyond the schema: omit `pack` to list, `confirm:true` alone is insufficient without the `quote_token` from the quote step, `quote_token` is ignored on the checkout-link path, and it binds the exact pack+price quoted with a 10-minute validity window. This sequencing and lifecycle info is real added value, though each parameter's core definition remains 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 names a specific action (top up / buy a credit PACK) and a resource, and enumerates the distinct behaviors: list packs, quote, one-click charge, checkout link, and machine-payment. It differentiates itself from billing-adjacent siblings like billing_status, upgrade_plan, and set_auto_reload without requiring the agent to open any other tool.

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

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

The description explicitly routes the agent: 'the checkout link above remains the normal path' for most agents, the machine-payment path only for agents holding their own payment credential, and subscriptions are explicitly out of scope ('managed by a person in Settings → Billing'). It also names the alternative for the underlying problem: 'turn on auto-reload with set_auto_reload (admin)'. When-to-use, when-not-to-use, and alternatives are all 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?

Beyond the annotations, the description discloses that invoking through call_tool uses the same permissions, account, and result as a direct call; that arguments are validated against the target tool's schema; that invalid arguments return the expected parameters rather than silently defaulting; and that tools requiring unavailable connectors or withheld by host policy are refused by name with an actionable way out. This is rich, non-obvious 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?

Every sentence earns its place: purpose, source of parameter values, host-specific rationale, validation behavior, and refusal conditions. The most important action and scope are front-loaded, and the length is justified by the complexity and risk of a generic tool dispatcher.

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 as a dynamic dispatcher and the absence of an output schema, the description fully covers how to invoke it, how to source parameters, what validation behavior to expect, and when/why it may refuse. The statement that results match a direct call also informs the agent about return behavior without needing 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?

Schema coverage is 100%, so the baseline is 3. The description adds operational meaning by directing the agent to obtain the exact name and args from find_tools and by explaining that args must match the target tool's own schema, with validation errors surfacing expected parameters. This goes slightly beyond the schema's bare 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 opens with a specific verb and resource: 'Run ANY Hermoso tool by name', and immediately clarifies its unique scope—it can invoke tools not in the session's starting list, including paid-campaign, analytics, and channel-admin tools. This clearly distinguishes it from the many specific sibling tools and from enable_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?

The description gives explicit when-to-use guidance: it is the route on hosts like claude.ai and ChatGPT that cannot reload their tool list mid-conversation. It also names the alternative (enable_tools) and explains why that alternative fails on such hosts, plus instructs the agent to get the exact name and args from find_tools first.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the queued-state precondition and the alternative for published posts, which is useful beyond annotations. It does not contradict 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 dense sentences with zero waste. The action is front-loaded, followed by source, precondition, and alternative—each 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 one-parameter tool with no output schema and annotations covering destructive/idempotent behavior, the description provides everything an agent needs: what, when, where to get the id, and what to do if it's too late. Nothing essential is missing.

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

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

Schema coverage is 100% (the 'id' description already says 'the scheduled post id from list_scheduled'). The description reinforces the exact source of the id, adding practical retrieval guidance beyond the schema.

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

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

States a specific verb ('Remove') and resource ('a queued post') with a clear boundary condition ('before it goes out'). It distinguishes itself from list_scheduled and manage_meta_post, making it unambiguous among 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?

Explicitly instructs where to get the id ('Get the id from list_scheduled'), states the valid condition ('while it is still queued'), and names the alternative for published posts ('use manage_meta_post'). This fully routes 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 cover the safety profile (not read-only, not destructive, not idempotent), and the description adds context beyond them: the operation is 'Paid,' it preserves 'the performance, lip-sync, and background sound,' and it 'returns the served URL.' This is meaningful behavioral disclosure consistent with 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?

Three sentences with zero waste: purpose, usage guidance, and cost/return detail. The core scoping constraint is front-loaded ahead of the alternative and cost notes.

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 tool with full schema coverage and no output schema, the description covers purpose, selection criteria, cost, preservation guarantees, and return value. Only a minor gap: it does not state whether the tool is synchronous or produces a new render rather than mutating the original video.

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

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

Schema description coverage is 100%, so the baseline is 3; both 'video' and 'voice' are already documented with examples and a default. The description adds no parameter-level detail beyond what the schema provides.

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

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

The description opens with a specific verb and resource: 'Swap the narration of a finished video into a different voice.' It distinguishes itself from the closest sibling by stating 'use dub_video only for language translation,' so an agent can tell the two apart 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?

Gives an explicit trigger condition — 'Use when the user likes the video but wants a different narrator voice' — and names the alternative with its exclusive condition: 'use dub_video only for language translation.' Both when-to-use and when-not-to-use are stated with nothing left to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is known. The description adds valuable behavioral details beyond this: it pulls live Meta policy pages, returns verbatim quotes, provides compliant rewrites, never edits creative, and charges a flat 1 credit. These details enrich the agent's understanding 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 front-loaded with the core purpose, then explains the method, differentiates it from editing, and gives usage guidance. Every sentence contributes value without excessive verbosity. It is reasonably concise given the amount of contextual information (cost, output format, use cases). Slightly longer than strictly necessary but well-organized.

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 (live external data, verdicts, verbatim quotes, rewrites) and lack of output schema, the description covers the key operational aspects: return format (verdict, quotes, rewrite), non-destructive behavior, cost, and when to prioritize it. It does not mention rate limits or prerequisites, but these are not critical for basic invocation. The description is complete enough for an agent to use the tool correctly in most scenarios.

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

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

Schema description coverage is 100%, so all parameters are adequately described in the schema. The tool description does not add any param-specific meaning beyond mentioning 'copy' implicitly and referencing categories in the usage guidance. It does not explain how to format or what to include for each parameter beyond the schema, so it does not exceed 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 clearly states a specific action ('Pre-flight ad copy against Meta's REAL, live Advertising Standards'), identifies the resource (ad copy) and outcome (verdict pass/fix/block). It explicitly differentiates from editing tools by stating 'It's a check, not an edit', which helps distinguish from potential siblings like edit-oriented tools. The purpose is unambiguous and directly actionable.

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 it: 'before you run it' and for specific regulated-adjacent categories or strong claims. It does not explicitly mention when NOT to use it or name alternative tools, but the guidance is sufficiently contextual to guide an agent. Missing an explicit when-not clause prevents a 5.

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

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

Annotations already mark destructiveHint=true and idempotentHint=true, but the description goes far beyond annotations by disclosing the two-call confirmation mechanism, the 'nothing is cleared' behavior without confirm, the confirmCells echo purpose, and the post-clear readback verification. This is rich behavioral context that annotations alone do not convey.

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

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

The description is lengthy but every sentence carries essential operational information: the destructive warning, the confirmation flow, the echo rationale, and the alternative. It is structured logically, starting with the action, then the destructive warning, then the workflow. While not terse, it avoids redundancy and 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?

Even without an output schema, the description explains what the user gets back (the number of filled cells on the unconfirmed call, and a confirmation only if the range is truly empty). It also warns about the common range-mistake scenario. This is sufficient for an agent to correctly perform the two-step destructive operation, though it does not describe error cases or edge conditions beyond that.

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

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

With only 40% schema description coverage, the description compensates substantially. It explains the confirm workflow, the confirmCells parameter ('echo back the filled-cell count'), and gives an A1:Z1000 example for range. It does not detail sheetUrl/spreadsheetId, but those are common and not critical for a destructive tool whose main parameters are well 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 states a specific action ('Empty a range of cells') on a specific resource ('a Google Sheet') and explicitly differentiates from a sibling ('To remove a whole tab instead, use manage_sheet_tabs'). It also clarifies that rows remain in place, leaving no ambiguity about what clearing entails.

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 detailed when-to-use and when-not-to-use guide. It explains the mandatory two-step confirmation workflow, warns about the no-default-range policy, and explicitly names the alternative tool for removing whole tabs. This leaves no inference needed for safe 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?

With annotations present (readOnlyHint:false, destructiveHint:false), the bar is lower, but this description adds exceptional behavioral context: the ~7-credit hold and settlement, the subject-aware reframe algorithm ('a SINGLE crop offset that is held for that clip's whole length'), refund-on-failure behavior, default burned-in subtitles, and the explicit warning that timing is approximate ('never promise that'). It even tells the agent to read reframedToSubject/reframeWhy/captionsBurned rather than assume. Nothing contradicts 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 long, but nearly every sentence earns its place: each segment maps to a real agent decision (input choice, exclusion handling, cost awareness, reframe behavior, captions toggle, timing caveat, result-field reading). The core purpose is front-loaded in the first sentence, followed by mechanism, then operational details. It could be tightened slightly, but for a tool with this many edge cases the density 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?

Since there is no output schema, the description carries the full burden of explaining returns, and it does: 'RETURNS clips[] — each with its OWN served mp4 URL, title, hook, ready-to-post caption, 0-100 score and source timecode — not a single video', plus the interpretable fields reframedToSubject, reframeWhy, captionsBurned, captionNote, and truncated. Inputs, outputs, constraints, cost, and edge-case behavior are all covered, leaving no critical gap 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 100% and the schema's own parameter descriptions are already rich (video lists all accepted URL types; captions explains the mute-watching rationale; aspectRatio covers defaults and 'keep'). The description adds complementary behavioral context around parameters — the ~600MB/size gate for `video`, the no-speech-window rule for `captions`, and the read-back fields that interpret results. Value is additive but partially duplicative of the schema, so 4 rather than 5.

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

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

The description states a specific verb+resource+outcome: 'Cut ONE long video into several RANKED, ready-to-post short clips', immediately followed by concrete use cases (podcast, webinar, interview, conference talk, long ad → Reels/Shorts/TikTok). It clearly differentiates from video siblings — reframe_video (reframes), dub_video (audio), stitch_video (concatenates), edit_video — by centering on the 'cut into ranked clips' operation.

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 strong context on accepted input formats and explicit exclusions: 'NOT supported: TikTok / Instagram / Facebook links, and anything age-restricted, private, members-only, geo-blocked or still LIVE', plus actionable advice ('ask for a direct file or an upload rather than retrying'). It also states hard constraints (min ~15s, ~600MB, ~40min window). It stops short of naming sibling tools as explicit alternatives for non-clipping tasks, so it loses a point.

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 idempotentHint=true and destructiveHint=false, but the description goes far beyond them: it explains accrual and skipping, how missing metrics are recorded as ABSENT (never zero), how failures become 'could not tell', the default skipping of X due to billing, and the requirement to inform the user about credits. This rich disclosure about side effects, cost, and data handling is exactly what an agent needs and exceeds annotation coverage.

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

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

The description is longer than average but every sentence carries necessary information: accrual schedule, skip behavior, ABSENT vs zero, failure handling, billing for X, and the reporting of skips. It is structured with punctuation and a clear flow. It could be slightly tighter, but the density is justified for a tool with multiple behavioral nuances. Front-loads the core action.

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 no output schema and moderate complexity, the description is remarkably complete. It tells the agent what it does, when to call it (due readings), how it handles data quirks (ABSENT, 'could not tell'), billing implications (X costs credits), and the need to inform the user. It also notes that skips are always reported, preventing misinterpretation. Nothing critical for selecting or invoking the tool is missing.

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

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

Schema description coverage is 100%, so both 'max' and 'includeMetered' already have clear descriptions in the schema. The tool description reinforces the billing aspect of includeMetered ('tell the user it costs credits BEFORE you do') but does not add fundamentally new parameter semantics beyond what the schema 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 opens with a clear, specific verb+resource: 'Fetch fresh performance numbers for this brand's recorded posts and store them as a time-series.' It precisely defines scope ('this brand's recorded posts') and the accrual model (24h and 7d readings), making it distinct from per-platform metrics tools like x_post_metrics or bluesky_post_metrics. Even without naming siblings, the behavior clearly separates it.

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

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

The description implies when to use it—when metrics are due per the accrual schedule—but does not explicitly contrast it with alternatives or state when not to use it. It says 'this collects whichever readings are due and skips the ones already taken,' which gives a condition, but no explicit route to sibling tools or exclusions. This is adequate but not 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 credit costs ('spends credits, free when you pass ads'), the conditional data source (auto-pulls Meta ads when `ads` omitted), and that it auto-tailors outputs to the saved brand. These go beyond the annotations (readOnlyHint, destructiveHint) which only cover safety. No contradiction; the tool is read-only yet consumes credits, and this is clearly stated.

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 carries operational information: outputs in caps, the contract, the credit behavior, and auto-tailoring. It front-loads the core purpose and uses structural markers (CONTRACT) for clarity. Minor redundancy (spending mention twice) but nothing trivial. Efficiency is high given 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 tool with no output schema and only safety annotations, the description is remarkably complete. It specifies inputs, the conditional behavior, cost implications, and the nature of outputs (playbook components). The only missing piece is exact output format, but the enumerated deliverables suffice for an agent to know what to expect.

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 three parameters. The description enriches meaning: for `ads`, it explains the two modes (supply or omit) and the consequence of omission; for `competitor`, it adds that domain sharpens page match. This adds contract-level semantics not present in the field descriptions, justifying above the baseline of 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 by stating a specific verb-resource pair ('Tear a competitor's ad strategy down into an actionable playbook') and enumerates concrete outputs (opening-hook MIX, longest-running THEMES, WHITE SPACE, COUNTER-PLAYS). It clearly distinguishes itself from sibling research tools like research_ads or search_meta_ads by focusing on a strategic teardown rather than raw data retrieval.

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

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

The 'CONTRACT' section explicitly tells an agent when to pass `ads` (after a pull_competitor_ads / search_meta_ads call) versus when to omit it (auto-pull, spending credits). It implies the tool is for creating a playbook, contrasting with pure research tools. It could name alternatives more explicitly, but the usage context is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavior: conversion happens on Microsoft's servers (no local re-encoding), no data is lost, output is stored at a durable Hermoso URL, and the Microsoft-provided link expires in minutes. This goes beyond annotations and covers essential 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 long but each sentence serves a purpose: it explains the mechanism, enumerates supported formats, gives examples, states a hard constraint (JPG dimensions), and describes output and permissions. It is front-loaded with the core function, and while detailed, it avoids fluff. Slightly overlong for a 4-5, but very 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?

Given no output schema, the description does a good job describing what the tool produces (a durable URL) and how to use the result ('pass straight to a render or a post'). It covers prerequisites, output behavior, and a key pitfall (expiring link). It omits explicit response structure (e.g., whether it returns just the URL or an object), but the guidance is sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that JPG conversion requires both width and height because Microsoft refuses the call without them, and it clarifies that fileId comes from list_onedrive_files. This exceeds the schema by providing rationale and origin context, justifying a score above 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 (convert), a clear resource (OneDrive file), and output formats (PDF or JPG). It also distinguishes itself from siblings by highlighting the broad input format support (e.g., PSD, AI, raw camera formats) that other tools in the product cannot open. This makes the tool's purpose unmistakable and separate from read/get/list 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?

The description provides explicit use cases ('turn a client's deck into images', 'get a usable JPG out of a designer's PSD', 'hand someone a PDF of a spreadsheet') and a critical warning about avoiding the expiring Microsoft link. It also notes the prerequisite of OneDrive being connected. This clearly guides when and why to use the tool, and even hints at the source for the fileId (list_onedrive_files).

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 switches to the new workspace, that it is free but triggers a ~50-credit research cascade only when draft_brand is run, and that re-running with the same name returns the existing workspace. These details go beyond the annotations (idempotentHint, destructiveHint) and add meaningful 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 five sentences and each adds value, front-loading the core action and expanding with scope, usage, and cost. It is slightly long but well-structured, efficiently packing information 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?

Given the tool's complexity and lack of output schema, the description covers all necessary aspects: workspace isolation, typical usage, idempotence, and cost implications. An agent has enough information to invoke it correctly without further clarification.

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 describes both parameters (name and activate) with 100% coverage, so the description adds no parameter-specific meaning beyond the schema. It mentions workspace isolation and switching, which indirectly relates to 'activate', but not explicitly; this meets the baseline for full-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 the tool adds a new brand workspace and switches to it, enumerating the isolated contents (brand profile, memory, swipefile, etc.). It also explicitly distinguishes from sibling tools draft_brand and update_brand, leaving no ambiguity about the 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?

It explicitly states when to use this tool ('for a second brand or a new client') and when to use alternatives ('draft_brand to FILL a workspace, and update_brand to edit one'). It also clarifies the idempotent re-run behavior, which helps an agent decide 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?

The description goes beyond the annotations by disclosing the required Drive connection, noting that one connection covers Drive, Sheets, and Docs, and stating that the tool returns the document id and URL. This adds behavioral context (prerequisites, output) that annotations do not provide. No contradiction with the annotations (readOnlyHint=false, destructiveHint=false) is present.

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 redundancy. It front-loads the main action and scope, includes valuable examples, and tucks the prerequisite and return-value information into a compact second sentence. Every word earns its place.

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

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

For a simple two-parameter creation tool, the description covers the core essentials: what, examples, return value, and prerequisites. It lacks explicit clarification on whether a title is mandatory (schema has no required parameters, but the description implies title is needed), which would be a minor gap. Overall, it's sufficient for an agent to invoke successfully.

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 (text as 'body text to insert', title as 'document title') with 100% coverage. The description adds minor clarification by restating that title is for the document title and text is optional body text, but it doesn't introduce new parameter-specific details beyond what's in the schema. The baseline of 3 is appropriate given 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 states the specific verb-resource pair ('Create a new Google Doc') with clear scope (in the user's Drive) and provides concrete examples (export ad copy, creative brief, report). It clearly distinguishes this creation tool from sibling tools like append_to_doc, read_doc, and update_doc, which handle different operations on existing docs.

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 makes the primary use case explicit by describing what the tool accomplishes and giving example scenarios. While it doesn't explicitly state when NOT to use it (e.g., for editing existing docs), the clear scoping to 'new' docs implicitly differentiates it from update/append tools, and the prerequisite note about Drive connection adds practical 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 indicate mutation (readOnlyHint=false). Description adds valuable behavioral context: return value (folder id + webViewLink) and the distinction between the returned ID and the NAME used by save_to_drive. While it doesn't cover error handling or permissions, it goes beyond 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?

Three sentences, each adding distinct value: purpose, return value, and usage warnings. No fluff; information is front-loaded and logically ordered. The critical save_to_drive clarification is placed at the end, which is acceptable.

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 tool with full schema coverage and relevant annotations, the description covers purpose, return value, usage pattern, and potential confusion with sibling tools. Nothing an agent needs to call it correctly is missing.

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

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

Schema already documents both parameters (100% coverage). Description adds meaning by explaining parentId's role ('parent folder id for a nested folder, default: Drive root') and clarifies the id/name distinction for name usage. This enriches the schema's baseline 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?

Description states a specific verb ('Create') and resource ('folder in the user’s Google Drive') with optional nesting under parentId, clearly distinguishing it from siblings like save_to_drive and update_drive_file. The purpose is immediately clear without ambiguity.

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

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

Provides explicit when-to-use guidance: 'Use that ID as update_drive_file’s moveToFolderId or as parentId for a nested folder.' Also warns about save_to_drive's folder being a NAME not an id, and advises passing the NAME there or omitting it. This fully routes the agent to correct 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 indicate a non-read-only, non-destructive write operation. The description adds value by disclosing the return format (folder id + webViewLink), the optional nesting behavior, and the semantic distinction from save_to_onedrive's folder name. It does not contradict annotations and covers the key behavioral aspects beyond the structured metadata.

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, front-loaded with the core purpose, then return value, then usage and a caveat. Every sentence earns its place with no redundancy or filler. It is efficient and well-organized.

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 tool with full schema coverage and clear annotations, this description is complete. It explains the return value (compensating for the lack of an output schema), provides usage guidance, and disambiguates from a similar sibling. Nothing essential 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%, with both 'name' and 'parentId' already described in the input schema. The description reiterates the nesting behavior but does not add new parameter-level meaning beyond what the schema provides. Since the schema covers parameter semantics, the description's additional context is useful but not required, landing at the baseline of 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 states a specific verb and resource ('Create a folder in the user's OneDrive'), explains its purpose ('to organize saved files'), and distinguishes itself from close siblings like save_to_onedrive and create_drive_folder by explicit naming and context. It also mentions the return value, making the tool's role unambiguous.

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

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

The description provides clear usage guidance: it explains how to use the returned id (as moveToFolderId for update_onedrive_file or as parentId for nesting) and explicitly warns about the difference from save_to_onedrive's folder name. While it doesn't enumerate all alternatives, it effectively prevents common misuse and gives actionable next steps.

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 and openWorldHint=true, so the write nature is known. The description adds the requirement of a Google Drive connection (one connection covers Drive, Sheets, Docs) and clarifies that rows are optional, which goes beyond the schema. 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?

Three sentences with no filler. The purpose is front-loaded, followed by usage details and a prerequisite. Every sentence contributes meaningful information for the agent.

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 two optional parameters and no output schema, the description covers everything needed: purpose, row format, return value (id + URL), and a connection prerequisite. The examples help the agent understand common use cases. 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% with descriptions for both parameters. The description adds value by clarifying that rows are optional, providing examples of what rows might contain, and noting that the first row is treated as headers. This complements the schema 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 states a specific verb and resource ('Create a new Google Spreadsheet in the user's Drive') and provides concrete examples (export a swipefile, ad list, performance report). It clearly differentiates from siblings like append_to_sheet and update_sheet by focusing on creation of a new spreadsheet.

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 (creating a new sheet, optionally with rows) and includes a prerequisite (Google Drive connected). It does not explicitly name alternative tools or when not to use it, but the purpose is unambiguous enough that an agent can infer when to use it vs. modifying existing sheets.

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

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

Annotations already mark destructiveHint=true, but the description adds crucial behavioral context: the operation is irreversible, affects all shared users, requires a confirmation protocol, and the first call without confirm serves as a dry-run inventory. It explains the rationale for the confirmation fields, going 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 necessary safety information. It is front-loaded with the most critical warning (irreversible) and then flows logically into the confirmation protocol. Though it is a long paragraph, it is structured in a cause-and-effect manner that justifies its length. Could be broken into shorter sections, but it is 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?

For a destructive, high-stakes operation, the description covers the full behavioral contract: what is deleted, irreversibility, impact on shared users, the two-phase confirmation with exact parameters, and the anchor-brand exception. Nothing essential for an agent to call it correctly is missing.

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

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

Schema coverage is 100% and each parameter already has a description. The description adds value by explaining why confirmName and confirmConnectors exist: to prove the correct workspace was targeted, preventing accidental destruction of a live brand. This clarifies the intent and requirement 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 a specific verb and resource: "PERMANENTLY delete a brand workspace and EVERYTHING in it." It enumerates what is included and explicitly distinguishes this from other delete tools by naming the anchor-brand exception. The purpose 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 gives an explicit two-phase workflow: call without confirm to get an inventory, show the user, get unambiguous yes, then call with confirm:true and necessary verification fields. It also states when NOT to use it (anchor brand) and how that case is handled. This is exemplary 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?

The description adds key behavioral details beyond annotations: it records a cross-device delete to prevent reappearance, clarifies that ads rendered with the person remain untouched, and notes that the portrait can be saved again. These are not covered by annotations (which only mark destructive/idempotent), so they add significant 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?

Two sentences, front-loaded with the action, then efficient details about scope and re-save. No wasted words.

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 delete tool with annotations covering destructive/idempotent, the description covers cross-device behavior, side effects (ads untouched), and reversibility (save_creator). There is no output schema, so return values are not a concern. An agent has all needed info 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?

The schema already describes the 'id' parameter as the creator id from list_creators, and the description repeats that without adding new details. Since coverage is 100%, the description adds no extra semantic 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 states a specific verb ('Remove') and resource ('saved creator from this workspace’s cast'), and identifies the id source ('from list_creators'). It clearly differentiates from siblings like save_creator by focusing on deletion and scope.

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

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

The description says the deletion only drops the roster entry and that the same portrait can be saved again with save_creator, implying the alternative for re-adding. It also notes no confirm is needed, providing a usage cue. It could be more explicit about when not to use it (e.g., if wanting to fully remove permanently), but it gives clear context.

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

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

Annotations already mark destructiveHint=true, but the description adds critical behavioral nuance: default goes to Trash (recoverable), permanent is irreversible, and confirmation with the user is required. This goes well beyond annotations by explaining the recovery path and the need for explicit user consent, covering the key behavioral aspect of 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 three sentences, front-loaded with the core action, then details irreversible behavior and usage steps. Every sentence adds value without redundancy. 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 delete tool with no output schema, the description is complete: it explains what happens by default, how to make it permanent, which parameters to pass, and the safety caution. It covers all essential information an agent needs to call this tool correctly, even among many similar delete tools.

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 each parameter. The description adds value by instructing to pass fileId from list_drive_files and emphasizing confirm:true, which clarifies that confirm is effectively required even though the schema's required array only lists fileId. This bridges a gap between schema and actual usage.

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 Drive file.' It specifies the resource and the verb, and distinguishes from siblings like update_drive_file, get_drive_file, and list_drive_files. It also adds nuance about trash vs permanent deletion, 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 practical usage hints: 'Pass fileId (from list_drive_files) + confirm:true' and explains the permanent option. It implicitly signals when to use this tool (when deleting a Drive file), though it doesn't explicitly contrast with alternatives. The context is clear and actionable, but lacks an explicit 'when not to use' statement.

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, idempotent, and open-world behavior, and the description adds crucial scoping: only the webhook is removed, while leads remain intact. 'Read back from LinkedIn' also discloses the external side effect, and there is no contradiction with 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?

Three short sentences front-load the core action and immediately clarify the destructive scope. Every sentence earns its place: the action, the non-destructive effect on leads, and the external synchronization/cost note.

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

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

Even without an output schema, the description covers what the call does, what it affects, and where to get the required parameter. The idempotent and open-world hints come from annotations, making this complete enough for an agent to select and invoke the tool correctly.

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

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

The schema already documents pageId and adAccountId, and the description adds meaning for the required subscriptionId by tying it directly to list_linkedin_lead_subscriptions. Since 67% of parameters are schema-described, the description meaningfully compensates for the remaining undocumented parameter.

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 the specific verb 'Remove' and the exact resource, 'a lead notification webhook', and anchors the required subscriptionId to its source, list_linkedin_lead_subscriptions. It also explicitly scopes what is not affected ('Leads themselves are unaffected'), which distinguishes it from any lead-deletion or subscription-creation tool.

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

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

The description tells the agent where to obtain the subscriptionId and makes the intended use case clear: stop real-time delivery while keeping leads readable. It does not explicitly enumerate exclusions versus every sibling tool, but the context is sufficient for selection.

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

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

Adds recoverability ('moves to the OneDrive recycle bin') and a confirmation requirement beyond what annotations already state (destructiveHint=true). This gives the agent important behavioral context for a mutation, meeting the lowered bar set by 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, zero waste, with the action and critical safety note front-loaded. The structure is clean: what it does, where it goes, how to call it, and a safety directive.

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 delete operation with destructiveHint, it covers the essentials: the action, recoverability, how to get the ID, and the confirmation requirement. No output schema is present, but delete typically returns minimal info, so this is adequate. Missing edge cases like non-existent files aren't critical.

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 params, but the description enriches them: it specifies fileId comes from list_onedrive_files and that confirm:true is required (aligning with the schema's 'REQUIRED true' description). This helps the agent construct valid calls.

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

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

States a specific verb+resource: 'Delete a OneDrive item' with the key behavior of moving to the recycle bin. Clearly distinguishes from siblings like delete_drive_file by specifying OneDrive specifically, so an agent can immediately know what it's for.

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 instructions: 'Pass fileId (from list_onedrive_files) + confirm:true' and emphasizes confirming with the user first. While it doesn't name alternatives or when-not-to-use, the guidance is clear and actionable for this destructive operation.

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. The description adds valuable behavioral context: it records a cross-device delete to prevent reappearance on sync, and explains it is 'minor + re-creatable' so no confirmation is needed. This goes beyond the annotations and gives an agent insight into side effects. 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?

Two succinct sentences: the first states the action and id source, the second explains cross-device behavior and the lack of confirmation. No extraneous words, and important details are 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 single-parameter, no-output-schema tool, this description is fully adequate. It covers how to get the id, the side effect (cross-device delete), and why no confirmation is needed. Combined with annotations for destructive/idempotent hints, 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?

The schema already fully describes the id parameter (type, required, description). The tool description repeats the instruction 'from list_playbooks', which adds a small hint about provenance but does not substantially augment the schema. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the action ('Delete a saved playbook by id'), specifies the resource (playbook), and tells the agent exactly where to get the id ('from list_playbooks'). It distinguishes this tool from other delete operations (e.g., delete_creator) by naming the resource type. This is specific and unambiguous.

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

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

The description implies usage context: you must first call list_playbooks to obtain the id. It does not explicitly name alternatives or state when not to use it, but the resource specificity is high and the id source instruction is a clear prerequisite. A slight gap is absence of explicit comparison to sibling delete tools, but the resource target makes it obvious.

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 useful context: it is 'Minor + re-creatable' and explicitly states no confirm is needed. It also discloses the constraint that built-in skills cannot be deleted, which is behavioral info beyond the annotations. There's no contradiction with 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?

Two sentences with no fluff. The primary action and scope are front-loaded, followed by the exclusion and confirmation guidance. Every sentence adds value.

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

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

For a single-parameter delete tool with no output schema and annotations covering safety, the description is sufficient. It covers what is deleted, how to identify it, what's excluded, and the confirmation behavior. Nothing essential is missing.

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

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

Schema coverage is 100%, with the id parameter already described as 'the custom skill id (from list_skills)'. The description essentially repeats this source reference, adding no new semantic detail beyond what the schema provides. Baseline 3 is appropriate given the 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 the verb ('Delete'), the resource ('workspace's CUSTOM skills'), and the scope ('by id (from list_skills)'). It also distinguishes custom skills from built-in skills/recipes, which are explicitly excluded. This differentiates it from any other delete operations in the sibling list.

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 context: delete custom skills, not built-in ones. It also gives the source of the id (list_skills) and explains that no confirmation is needed due to the minor, re-creatable nature, guiding the agent on when it's safe to proceed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces with 'Read-only, 0 credits.' It adds valuable behavioral context not in annotations: that it may return 'nothing here needs fixing' as a real answer, that it cannot see organic post conversions, and that the baseline is built from ALL recorded posts. These details meaningfully improve call quality.

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 long, the description is front-loaded with purpose, uses clear section markers (headers, numbered refusals), and every sentence carries unique information. The structure makes it easy to skim for key rules. The length is justified by the complexity of the diagnostic logic. No 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?

Given the tool's complexity, the description is thorough: it covers purpose, usage conditions, the four refusal cases, the converting behavior, output instruction ('Print summary verbatim'), and its read-only nature. There is no output schema, so the description compensates by specifying the call to action. An agent has everything needed to decide when to call and what to expect.

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 each parameter with descriptions, so baseline is 3. The description adds extra meaning: for limit, it states the baseline always uses every post, not just the limited set, preventing a bad month from becoming its own normal; for converting, it clarifies the condition under which converting:false should be passed and that it should be omitted when unknown. This adds 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: 'tells you what is WRONG with a given post and where the next edit goes.' It distinguishes itself from sibling post_performance by contrasting 'which hook is AHEAD' vs 'what is WRONG'. This is a specific verb+resource with clear differentiation from similarly named 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?

The description explicitly explains when to use this tool versus alternatives. It references post_performance for hook comparison, prescribes the sequence 'mine_angles, then list_hooks, then plan_variations' for hook problems, and details the four refusal conditions that tell the agent when NOT to call the tool. It also specifies when the offer rung runs (only with converting:false). This is exemplary.

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

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

Beyond the destructiveHint and readOnlyHint annotations, the description discloses concrete behavioral details: credentials are always dropped, provider tools stop immediately, published posts are not affected, revocation is provider-dependent (Threads/Microsoft do not revoke), and the unconfirmed call reports revokesAtProvider. It also states the agent cannot undo reconnection, which is critical operational context.

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

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

The description is dense and front-loaded with the most important facts (destructive action, immediate effect, published content unaffected). It is longer than necessary due to the extensive provider list and repeated emphasis, but each sentence carries actionable guidance rather than filler.

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

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

The description covers prerequisites, provider-id sourcing, provider-dependent revocation behavior, confirmation workflow, and irreversibility. For a destructive connector tool with no output schema, this is sufficient context for an agent to call it correctly and relay accurate caveats to the user.

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 the baseline is 3, but the description adds practical meaning by explaining why confirm:true is mandatory (reconnection needs a browser) and telling the agent to source provider ids from list_connectors. The account parameter is left to the schema, but that is acceptable given the 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 opens with a specific verb-resource pair ('Disconnect a third-party account from this workspace') and scopes it to credential-bearing connectors, which clearly separates it from list-only siblings. It further explains the consequences of disconnecting, so there is no ambiguity about what action is being performed.

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 obtain exact provider ids from list_connectors, to name the provider to the user, and to call with confirm:true only after user confirmation. The warning that reconnecting requires a browser and cannot be undone serves as an explicit when-not-to-call signal.

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=false and destructiveHint=false, and the description adds meaningful context beyond that: it's 0 credits, it cannot ask the user (caller owns verification), and it warns that a domain can resolve to a different company than intended (bala.com vs shopbala.com). This discloses a real failure mode and the save:false workflow, which no annotation conveys.

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 purpose is front-loaded in the first sentence, and the IMPORTANT paragraph is justified because it flags a critical verification pitfall that materially affects correct invocation. Slightly long, but each segment (purpose, credit cost, domain-mismatch warning, save semantics) 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 5-parameter tool with no output schema and minimal annotations, the description covers the input sources, the ambiguous-domain risk, the save semantics, and the credit cost. It could add the exact return shape beyond the partial {name, products, logo, …}, but what's needed to call it correctly and safely is present.

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

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

Schema description coverage is 100%, so all five parameters (save, domain, platform, description, socialHandle) are already documented in the schema. The description names the three input sources and references save:false, which lightly reinforces parameter meaning, but adds little beyond what the schema provides — the baseline 3 for high coverage applies.

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

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

The description states a specific verb ('onboard a brand profile'), the resource (brand), three input sources (domain, free-text description, social handle), and the output shape ({name, products, logo, …} object). It clearly distinguishes itself from sibling brand tools (create_brand, update_brand, get_brand) by describing the draft-from-source behavior, so an agent can tell it apart without opening sibling schemas.

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

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

The description gives workflow guidance — results can be passed to plan_ad/generate, and the caller should verify name/summary and re-draft with save:false until confirmed. However, it never explicitly contrasts draft_brand with the sibling create_brand/update_brand tools or states when to pick one over the other, so the 'when to use vs alternative' guidance is 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?

Annotations are neutral (readOnlyHint: false, destructiveHint: false), so the description carries the burden of disclosing behavior. It clearly states that it does NOT re-render, preserves visuals/timing/edit, transcribes/translates/re-voices/lip-syncs, and returns the served URL. It also discloses that it is paid. This adds significant behavioral context beyond annotations, though it omits potential limitations like processing time or input format constraints.

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

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

The description is moderately long but every sentence earns its place: it explains the mechanism, the simple invocation, the script override nuance, and the cost/return. Key facts (no re-render, pass video+language, paid, returns URL) are front-loaded, making it skimmable. A slight trim could tighten it, but it remains focused.

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 correctly specifies that it returns 'the served URL of the localized video.' It covers all four parameters, the cost, and the behavioral specifics. Missing details like asynchronous processing or video size limits are non-essential for basic usage, so the description is virtually 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 description coverage is 100%, so each parameter already has a description. The tool description enhances this by explaining the script parameter's override purpose ('pass script only to override what it heard') and adding nuance about the voice parameter's default selection. This goes beyond mere schema repetition, adding practical guidance without being redundant.

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') and resource ('finished video') with a clear outcome (transcribed, translated, re-voiced, lip-synced back onto the same footage). It distinctly differentiates from siblings like clip_video or edit_video by focusing on language localization without re-rendering, 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 explicitly tells the agent to 'Just pass the video and the language', making the core usage obvious. It also provides a conditional for the script parameter (use only when auto-transcript fails) and mentions the tool is paid, which is a cost guideline. However, it does not explicitly contrast with alternative tools, though no direct sibling exists that performs dubbing, so the context is sufficiently 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description adds crucial behavioral details: 'The copy is INDEPENDENT — editing or cancelling it never touches the original — and it is a genuinely new post rather than a re-send, so it publishes even where the original already did.' This clarifies side effects and independence, which annotations do not convey. No contradiction with annotations exists.

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

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

The description is a single dense paragraph that front-loads the core purpose and then adds context. It is not overly verbose given the tool's complexity (18 parameters), and every sentence adds value, from use cases to independence to the retry_scheduled contrast. It could be broken into bullet points for readability, but it is structured logically and remains comprehensible.

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 (18 parameters, nested objects, many channel-specific fields), the description covers the essential behavior, scheduling options, independence, and the difference from retry_scheduled. It does not need to explain every parameter because the schema already does, and no output schema exists so return values are not required. The description provides enough for an agent to call it correctly without missing key context.

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% (many parameters have descriptions), and the description adds meaningful context beyond those. It explains that all copied fields 'can be overridden in the same call' and clarifies the scheduling distinction between 'at' and 'useQueue:true'. It also mentions the default time ('an hour from now') implicitly via 'at' description in schema, but the description does not list every parameter. It augment the schema without fully compensating for the 28% undocumented parameters, so a 4 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 specific verb and resource: 'Copy an existing scheduled or already-published post into a NEW queued post.' It clearly states the action, the object, and the result, and distinguishes it from the sibling tool retry_scheduled by noting 'To re-fire only the channels that FAILED, use retry_scheduled instead.' This leaves no ambiguity about what the tool does and when to differentiate it.

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 lists use cases ('run a creative again, reuse a post that worked as the starting point for the next one, or re-send something after it went out') and provides a direct alternative: 'To re-fire only the channels that FAILED, use retry_scheduled instead.' It also explains the two scheduling modes (at vs useQueue), giving the agent clear conditions for each. No gaps remain 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 all false (readOnlyHint, destructiveHint, etc.), so the description carries the full burden. It clearly discloses key behaviors: the edit preserves original motion/timing, it is a paid render, and it returns a served URL. It also explains how the elements parameter affects behavior (restores real identity/product vs. plain restyle). 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 dense yet every sentence earns its place: purpose is front-loaded, followed by concrete use cases, the recommended clip length, a clear 'NOT for' section naming five alternatives, and a final note on cost and output. The structure guides an agent from selection to invocation 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?

Given the tool's complexity (video editing, multiple parameters, no output schema), the description covers purpose, usage, exclusions, cost, output URL, and best practices. It doesn't mention error scenarios or hard maximum video length, but the 'Best on 3–10s clips' is a reasonable heuristic. The schema covers source URL provenance. Overall, an agent has everything needed to decide and call the tool correctly.

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

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

Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description adds meaningful context for the 'elements' parameter, explaining its purpose (identity/product grounding), the max count (≤4), and when to omit it (plain restyle). It also clarifies the 'instruction' parameter as 'in the user’s own words'. This goes beyond the schema's literal descriptions and aids correct usage.

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 ('EDIT/transform') and resource ('an existing video clip') and immediately defines the scope: keeps motion/timing, changes subject/setting/style. It provides concrete examples ('change the background to a city', 'restyle it as claymation'). It also distinguishes itself from five named sibling tools, so an agent can reliably tell edit_video apart from post_edit, generate_video, render_ad, dub_video, and recast_motion.

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 states when to use (for style/subject/setting changes) and when NOT to use, listing specific alternatives for each excluded case (mechanical cuts → post_edit, new video → generate_video/render_ad, translation → dub_video, face swap → recast_motion). It also adds a practical recommendation ('Best on 3–10s clips') and flags the paid nature. This leaves no ambiguity about tool selection.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, but the description adds valuable behavioral context: it only works on clients that re-read the tool list, it reports 'not a success you cannot use' in its reply when the host won't show new tools, it is 'free, instant, and it never turns anything off.' This goes well beyond the annotations and helps the agent set correct expectations.

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

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

The description is long but information-dense and well-structured. It front-loads the core action, then the important caveat, then the default-roster explanation, and ends with actionable triggers. Some repetition (e.g., the group list appears twice in different forms) could be trimmed, but every section earns its place for an agent making a decision.

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 one required parameter and no output schema, the description is exceptionally complete: it covers when to call, which groups exist, why some groups are hidden by default, the limitation with connect-time-only hosts, and the alternative route. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and the schema parameter description already explains the groups array and unknown-name behavior. The tool description further enriches this by listing all valid group names ('core, research, create, channels, channel_admin, analytics, ads, files, workspace — or all') and giving concrete usage examples. This is meaningful added value over 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 states a specific verb and resource: 'Switch on a group of tools that is not in this session's roster.' It clearly distinguishes itself from siblings by being the meta-tool that enables other tools, and it explicitly names the groups and examples. This is unambiguous and not a tautology.

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 instructions: 'CALL THIS THE MOMENT YOU NEED ONE.' It provides concrete triggers for ads and analytics ('If the user asks to build, budget, target... call enable_tools({groups:['ads']}) first') and even names the alternative connect-time route (`?tools=all`). It also explains the limitation with hosts that fixed their roster, so the agent knows what to expect.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, 0 credits,' adding cost information. More importantly, it discloses that occurrences are 'redacted' and inputs are only a 'shape-only echo,' setting accurate expectations about the response — behavioral traits not present in 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?

Three short sentences, front-loaded with the core purpose before enumerating the returned content. The closing 'This is what makes a bug reproducible' adds value framing without fluff. Compact and well-ordered, with only minor density in the field enumeration.

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, read-only tool with no output schema, the description gives ample context: how to obtain the key, what content to expect, redaction behavior, and cost. One could wish for explicit output structure given the absence of an output schema, but the field listing partially covers this. Quite complete for the tool's 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% with the single 'fingerprint' parameter documented as 'the fp value from list_errors.' The description repeats this source relationship ('by fingerprint (from list_errors)') but adds no new syntactic or format detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb (retrieve) and resource (one error group) keyed by fingerprint, explicitly naming its sourcing tool list_errors. It distinguishes itself from list_errors by describing the expanded content — full fields plus redacted occurrences — so an agent understands this is the detail complement to the listing tool.

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

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

The description makes the prerequisite explicit: the fingerprint comes from list_errors, implying the workflow of listing first and then drilling into a specific group. It does not name exclusions or explicitly state when not to use it, but the source relationship and the 'makes a bug reproducible' framing give clear usage context.

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 thoroughly discloses behavioral mechanics beyond the annotations: it explains the drive.file scope limitation (why it cannot modify existing decks), the handling of expired ad-library links (falls back to textual description, reports count), returns presentation id+URL, and the connector prerequisite. Annotations only indicate readOnly=false, openWorld=true, idempotent=false, destructive=false; the description adds substantial operational depth that an agent needs to call it correctly.

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

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

The description is well-structured and front-loaded with the core purpose, then progresses to behavioral constraints and prerequisites. It is longer than strictly necessary (~150 words) but every sentence serves a distinct function (purpose, return value, new-deck behavior, expiry handling, connector requirement). Slight over-explanation of the expiry edge case could be trimmed, but overall 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?

For a tool with no output schema, it explicitly states the return value (presentation id + URL). It covers failure modes (expired links), scope limitations, and the required connector setup. It also handles the fact that all parameters are optional by stating defaults. Nothing an agent needs to call this tool 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% — each parameter (limit, title, collection) already has explicit descriptions including defaults. The main description adds no additional meaning about parameters beyond what the schema provides. Per the rubric, with high schema coverage the baseline is 3; the description doesn't elevate it further.

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+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 differentiates from siblings by noting 'until now the swipefile’s only export was JSON', making it clear this is the dedicated Slides export. 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?

It states the clear use case ('the thing a marketer actually presents') and provides critical constraints: creates a NEW deck every time, cannot add to an existing deck due to drive.file scope, and requires Drive connected (with explicit settings path). It implicitly contrasts with JSON export and other Drive file tools (e.g., create_doc, create_sheet) by positioning it as the presentation-specific exporter, though it does not name alternatives explicitly. That is sufficient context for an agent to decide when to use 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?

The description discloses it modifies the brand by saving screens (consistent with readOnlyHint false), is free and keyless, and requires a confident match. It clearly explains failure behavior ('returns 0 and saves nothing') and instructs to relay plainly. This adds significant context beyond the annotations, which already state idempotent and non-destructive.

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 and efficient. It front-loads purpose, then gives usage, failure, and success details. Some marketing emphasis (e.g., 'REAL', 'FREE') adds flavor but each sentence contributes value. Slightly verbose in tone, but overall well-structured and not wasteful.

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

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

For a tool with only two optional parameters and no output schema, the description fully covers when to use it, what happens on success and failure, and where data is saved. It also mentions that screens are immediately usable. Nothing an agent needs to call it correctly is missing.

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

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

Both parameters (appName and brandId) are fully described in the schema (100% coverage). The description minimally repeats appName's default but does not introduce new semantics. Since the schema already carries the parameters' meaning, a baseline score of 3 is appropriate.

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

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

Clearly states it pulls App Store screenshots into the workspace brand, with a specific verb and resource. Mentions the use case (app-ui-tour template) which helps disambiguate from other asset tools. The definition is specific about the source (App Store) and destination (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?

Explicitly provides conditions for use: when the brand has 0–1 app screens and the user wants make_template_ad(template:'app-ui-tour') or asks to 'pull my app's screenshots'. Also advises against retrying on ambiguous matches, giving both positive and negative guidance. This leaves no ambiguity about when 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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows this operation is safe and non-mutating. The description adds the behavioral detail that it returns two URL forms (clickable and download), which is helpful. However, it doesn't mention potential failure modes (e.g., invalid reference, auth) or any rate limits. Given the low annotation bar, a 3 is appropriate.

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

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

A single, information-dense sentence that leads with the core purpose and specifies input constraints. There is zero fluff; every part of the sentence earns its place. The structure is exemplary for a simple utility 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 tool is simple (2 params, 1 required) and the description fully explains the output (both URL types). Since there is no output schema, the description carries the responsibility for return values, and it does so clearly. It also defines the accepted input format, so an agent has everything needed to invoke it correctly. Complete for its 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 description coverage is 100%, both 'url' and 'name' are described in the schema. The tool description doesn't add parameter-specific detail beyond what the schema provides (e.g., no format examples or edge cases). Since the schema carries the full load, baseline 3 is correct.

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 ('Resolve'), the resource ('a generated asset reference'), and the exact outcome (clickable absolute URL + download URL). It even specifies the accepted input forms (/generated/ path or any URL), making the purpose unambiguous. No sibling tool performs this action, so no differentiation is needed.

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

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

The description implies the use case: whenever an agent has an asset reference that needs to be converted to usable URLs. It doesn't explicitly state when not to use it or list alternatives, but given the absence of any similar sibling tool, this is clear context. The lack of exclusions is acceptable because there are no obvious competing 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 declare readOnlyHint=true and openWorldHint=true, and the description is consistent (fetching data is read-only). Beyond the annotations, the description discloses that it returns RAW provider JSON — large and messy — and that it spends credits. These are meaningful behavioral traits that help the agent anticipate side effects and output format without contradicting any annotation.

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 earns its place: purpose, example, allowlisted platforms, parameter naming conventions, the warning about raw output, and the credit cost. The most important info is front-loaded, and there is no filler or repetition of schema 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?

Given the tool's open-ended nature (generic endpoint, no output schema), the description is complete enough for an agent to decide whether to use it and how to invoke it. It lists the platform families, explains the path/params structure, warns about the raw output, and notes credit consumption. It does not attempt to enumerate every endpoint, which would be unrealistic, but it equips the agent with the necessary guardrails.

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% (both path and params have descriptions). The description adds practical semantic value by explaining that param names vary per endpoint and providing concrete examples (handle for profiles, query for keyword searches, subreddit for Reddit). This goes beyond the generic schema descriptions and helps the agent construct valid params correctly.

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 purpose: a generic escape hatch for any ALLOWLISTED long-tail social/web endpoint not covered by the dedicated search_* tools. It provides a concrete example ({path:'/v1/instagram/profile', params:{handle:'nike'}}) and explicitly distinguishes itself from the search_* siblings, so an agent can tell when to reach for it.

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 guidance: use it only for long-tail endpoints not covered by the dedicated search_* tools, and explicitly says 'prefer the dedicated search_* tools' and warns that it 'spends credits.' This clearly states when to use it, when not to, and names the alternative category.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond that: it mentions the tool is 'Claude grounded by web search' (indicating web-based grounding) and clarifies the behavior of each mode. However, it does not elaborate on the 'company' mode's exact output, leaving a minor gap in transparency.

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 and front-loaded: it opens with the core purpose, then efficiently covers modes and cost in a few short sentences. Every sentence adds useful information—purpose, grounding, mode details, and cost—with no redundancy or filler.

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

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

For a tool with no output schema, the description does not describe the return format (e.g., list of brand names/domains) or any prerequisites like domain formatting. The 'company' mode is mentioned but its behavior is not explained. Given the tool's moderate complexity (2 params, modes), the description is somewhat incomplete, though the core purpose is clear.

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 parameters are fully documented in the schema. The description adds meaning by explicitly stating the default mode ('competitors (default)') and the exclusion behavior ('excludes the searched company'), which goes slightly beyond the schema's enum descriptions. This adds value but does not dramatically compensate for any missing param details.

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 function: 'Discover a brand's competitor / similar / adjacent brands from its domain.' It names the specific resource (brands) and the input (domain), and differentiates from sibling tools like pull_competitor_ads or competitor_teardown by focusing on brand discovery rather than ads or analysis. The modes are also mentioned, adding specificity.

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 usage context by explaining the three modes and their behavior (competitors excludes searched company, inspiration includes it, company presumably returns the company itself), and notes the cost ('0 credits'). However, it does not explicitly state when to use this tool versus related siblings (e.g., competitor_teardown) or when not to use it, leaving some room for inference.

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

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

Beyond the readOnly/openWorld/destructive annotations, the description discloses credit economics ('one credit per search call (platforms × queries, default 3 × 3) plus one per enriched profile; repeats inside 20 minutes are free'), enrichment behavior, and the data-quality guarantee 'Real people, not AI actors'. This gives an agent clear expectations about cost, output contents, and reliability.

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 paragraph is long but information-dense: scanning behavior, ranking criteria, contact data, use cases, credit costs, and follow-up tools are all present. It is front-loaded with the core function before moving to cost and workflow. It could be broken into clearer sentences or bullets, but there is no filler.

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

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

With 7 parameters, no output schema, and a paid search tool, the description covers the essentials: output contents ('the top rows get follower counts AND public contact info'), credit cost, and intended workflow. The main completeness gap is the undocumented minAvgViews parameter, which neither the schema nor the description explains clearly, leaving a small but real ambiguity for an agent.

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 high (86%), so the baseline is 3; the description adds value by tying queries and platforms to credit costs and explaining that enrich yields 'follower counts AND public contact info'. It also connects ranking to 'median views, engagement rate and how often they show up,' informing parameters like minAvgViews and minEngagement. One gap remains: minAvgViews has no schema description and the tool description never explains its units, so it does not reach a 5.

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

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

The description names a specific verb ('Scan organic TikTok, Instagram Reels and YouTube'), a concrete resource (creators matched to a niche), and a clear outcome (ranked creators with followers and public contact info). It also distinguishes itself from raw search or saved-creator siblings by saying 'fold the posts into creators' and 'Real people, not AI actors.'

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?

Use cases are explicit: 'for influencer sourcing, UGC casting and partnership prospecting' and 'who should we send product to?'. It also names follow-up tools like save_to_swipefile, fetch_social_data, generate_text, and manage_meta_partnership_creator, giving an agent the downstream workflow. It stops short of an explicit when-not-to-use warning versus content-search siblings, so it earns a 4 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?

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description adds context beyond them: the search spans tools outside the session's starting list, it is free, and it returns one-line parameter summaries. These traits align with the annotations, so 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?

Four sentences and roughly 90 words, with the core purpose front-loaded and every sentence carrying distinct information: scope, trigger, decision rule, follow-up, and cost. It is dense, but appropriately so for a discovery tool that must override the agent's default assumption that its list is complete.

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

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

With no output schema, the description carries the burden of explaining return values, and it does ('parameters in one line'). For a discovery tool with zero required parameters, it covers scope, when-to-use, output shape, follow-up action, and cost; limit defaults and enum values live in the schema where they belong.

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%, putting the baseline at 3, but the description adds value by showing query formulation examples ('lead form', 'whatsapp', 'google ads keyword', 'meta insights') and naming concrete group values (`ads`, `analytics`, `channel_admin`) that map directly to the group parameter.

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

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

The opening sentence states a specific verb+resource ('Search EVERY Hermoso tool'), names the three search dimensions (name, task, group), and specifies the output ('each one's parameters in one line'). It clearly distinguishes itself from siblings like call_tool and hermoso_capabilities by explicitly flagging the hidden `ads`, `analytics`, and `channel_admin` groups.

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 trigger ('Use it the moment the user asks for something you do not see a tool for') with concrete examples (campaign, ad set, lead form, click-to-WhatsApp ad). It reinforces the decision rule with a strong negative framing ('a tool missing from your list is NEVER proof the feature is missing') and names the follow-up action ('Then run the tool with call_tool'), effectively drawing the boundary against execution 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?

With annotations all set to false (readOnlyHint, destructiveHint, idempotentHint), the description carries the full behavioral burden and does so thoroughly. It discloses that the original is untouched (non-destructive), gives time and cost estimates (~30s, a couple of credits), explains the aesthetic effect of grain ('less AI'), and warns against fabricated stats. This is rich, specific behavioral context that goes far 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 a single dense paragraph, but every sentence carries information: purpose, modes, constraints, and side effects. It front-loads the core action and the result (new video, original untouched). It could be slightly more streamlined, but 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?

For a tool with 7 parameters and no output schema, the description covers the essential context: it explains both modes, how they interact, the return behavior ('Returns a NEW video'), and the non-destructive guarantee. It does not specify the exact output format (e.g., URL object), but for a post-processing tool that returns a video, that level of detail is likely sufficient. Minor gaps like error handling are not critical given the clarity elsewhere.

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 100% of parameters with descriptions, so the baseline is 3. The description adds value by explaining the visual and strategic purpose of pills and grain, clarifying that the agent authors the copy with character limits (repeated from schema but reinforced), and describing how grain works alone or with pills. This complements the schema 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 a specific verb ('Post-process') and a precise resource ('EXISTING rendered video (its served mp4 URL)'), immediately distinguishing this from generation or editing tools. It names the two modes (reviewer finish and grain pass) and the visual elements (header, sub-pill, proof pills), 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 explicitly constrains when to use it: it requires an existing rendered video URL from a previous render/job, and states it is a post-processing step ('no AI model'). It does not explicitly name sibling alternatives like edit_video or upscale_video, but the strong precondition and the mention of 'proven direct-response reviewer finish' effectively distinguish it. The guidance is clear enough for an agent to route correctly.

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

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

Annotations provide minimal safety hints (all false), so the description carries the full burden. It discloses that the tool modifies the video track only, keeps audio byte-identical, bills only the replacement seconds (~1/3 of full render), and warns about lip-sync issues under dialogue. This is thorough behavioral disclosure beyond the schema.

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

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

The description is a compact paragraph with a clear logical flow: core action, use cases, billing impact, and a critical warning. No fluff; every sentence serves a purpose and the most important constraint (video-only splice) 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?

The tool is complex (6 params, nested array, specific constraints) and the description covers its purpose, constraints, and billing implications well. It misses the output format (e.g., returns a job ID or new video URL) and error conditions, but the core use cases are fully addressed.

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%, giving baseline 3, but the description adds context: the 1.5-8s window constraint, the meaning of prompt relative to master style, and the importance of speechWindows in avoiding dialogue overlap. This elevates understanding beyond bare parameter names.

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-resource pair: 're-render ONE time window' of an existing video, and further distinguishes itself by specifying VIDEO TRACK ONLY with byte-identical preservation of the rest. It clearly separates from siblings like full re-render or clip_video by emphasizing surgical splicing.

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 ('when one beat/shot is broken'), when not to (avoid dialogue windows), and names the alternative (full re-render) with reasoning. Also gives a concrete negative condition and instructs to pass speechWindows to enforce that constraint.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds critical context beyond these: it records a cross-device delete (so it won't reappear), and explains the action is minor/re-creatable and thus requires no confirmation. This materially enriches the behavioral model for an agent.

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, no fluff. The first sentence states the core action and source of id; the second explains side effects and the no-confirm rationale. Information is front-loaded and every word earns its place.

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

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

For a simple, single-parameter tool with no output schema, this description covers the action, the id source, cross-device persistence, reversibility, and why no confirmation is needed. Nothing essential is missing 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% and both the schema and description state the id is from list_memory. The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

States the exact verb 'Delete' and resource 'saved Memory item', and explicitly references the id source (list_memory). Clearly distinguishes from sibling tools like remember and list_memory by identifying the delete operation.

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?

Conveys clear usage context: use this when you have a memory id (from list_memory) and want to remove it. It does not explicitly mention when not to use it or alternatives, but the context is unambiguous enough 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?

The description adds behavioral context beyond annotations: it states it changes formatting but not cell values, and explains how to skip individual operations via parameters. Annotations already declare idempotent and non-destructive, and the description enriches this with specifics about freezing and auto-size.

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 adds value. It front-loads the purpose and then explains usage and parameter specifics. The rhetorical flourish about 'the difference between a spreadsheet someone reads and one they close' is not wasteful, but could be trimmed without loss.

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 formatting tool with no output schema, the description covers the core use case, parameter semantics, and behavioral details. It does not mention error handling or authorization, but those are covered by annotations (idempotent, non-destructive) and are 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?

Schema coverage is only 33% (only tab and freezeRows have descriptions). The description compensates by explaining the defaults and how to override each operation (tab, freezeRows, boldHeader, autoResize). It does not detail sheetUrl/spreadsheetId, but those are conventional identifiers.

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 specific actions (bold header, freeze, auto-size) and the resource (exported sheet). It also distinguishes itself from create_sheet by describing it as a follow-up formatting step, not a creation or data mutation tool.

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

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

It provides a concrete trigger ('Worth calling right after create_sheet') and explains why (raw export with unsized columns). It also notes that it changes no cell value and is never gated, implying non-destructive use. However, it does not explicitly name alternatives for editing values or when not to use 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?

The description discloses important behavioral traits not covered by annotations: it blocks for 1–3 minutes, spends credits, and requires a specific capability flag. These are significant for an agent to plan execution. However, it does not mention what the tool returns (e.g., a URL, file path) or any side effects beyond spending credits, so a 4 reflects good but not exhaustive transparency.

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 filler. The primary action is front-loaded, and the critical constraints (blocking, credits, capability) are stated compactly. Every clause adds value.

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

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

For a generation tool with no output schema, the description covers the core purpose, blocking duration, credit cost, and capability prerequisite. The main gap is the absence of any mention of the output format (e.g., returns a media URL or file), which an agent needs to handle the result. Given the complexity, it is mostly complete but missing that return detail.

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

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

Schema description coverage is 100% and each parameter already has a clear description (e.g., image is a portrait, script is the spoken words, resolution lists options). The tool description adds minimal extra meaning beyond restating 'portrait image + script'. The baseline of 3 is appropriate since 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 clearly states the tool renders a talking avatar / creator lip-sync clip from a portrait image and a script. It is specific enough to distinguish from siblings like generate_voice (audio only) or generate_video (generic video) by naming 'talking-avatar' and 'lip-sync'.

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

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

The description implies when to use (need a talking avatar) but does not explicitly contrast with alternatives or state when NOT to use it. The capability requirement (canAvatar) and blocking behavior suggest a specific use case, but no exclusions or comparative routing to other content-generation tools are provided.

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

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

All four annotation hints are false, so the description carries the full disclosure burden and meets it. It discloses that the tool spends credits, that saved-brand hydration can silently swap the engine to the compositing model, that raw:true sends the prompt byte-identical with no rewriting/guidance/negative-prompt, and that delivery and validation are unchanged. This is deep, honest behavioral disclosure far 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?

Front-loaded with the core purpose and output, and every sentence carries distinct value (engine behavior, multi-brand caution, raw semantics, cost, timing). It is slightly dense and run-on in the engine/multi-brand passages, but contains zero filler, so it earns a high score despite the parsing effort.

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 7 parameters, subtle mode interactions, cost implications, and no output schema, the description is remarkably complete. It covers the deliverable (served URL), engine-selection behavior, brand hydration caution, raw mode, cost (credits), durability, and the capabilities catalog for model ids. 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%, but the description adds genuine cross-parameter semantics the schema cannot express alone: the interaction between refImages, useBrand, model, and raw (e.g., 'a model you named is only honoured when no references ride — pass raw:true (or useBrand:false)'). It also clarifies that model is 'a catalog id from hermoso_capabilities (omit for the default),' connecting to a sibling capability tool. This is additive meaning, not duplication.

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

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

The opening sentence states a specific verb, resource, and output: 'Render a finished ad IMAGE and return its served URL.' This clearly distinguishes generate_image from video/voice/text siblings (generate_video, generate_voice, generate_text) and names the core deliverable. It also lays out distinct modes (compositing vs raw) that define the tool's scope.

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

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

Provides rich, actionable usage context: when to pass refImages for product-accurate compositing, the explicit MULTI-BRAND CAUTION instructing to pass the fresh brand's productImages and set useBrand:false, and when to use raw:true to guarantee the named model renders. Lacks only an explicit routing against sibling image tools like render_ad or make_template_ad, which keeps it a 4 rather than a 5.

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

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

Annotations are all false, offering no behavioral hints, so the description carries the full burden. It discloses the default copywriter system prompt, the raw:true escape hatch to bypass it, and that the tool is paid by length—valuable behavioral context not in the schema. It doesn't contradict annotations, though it omits error handling and response format.

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

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

A single, information-dense paragraph where each sentence earns its place: purpose, scope, exclusions, default behavior, parameter tips, and cost. No redundancy or filler; the most critical scoping info is front-loaded before the parameter notes.

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 prompt-based generation tool, the description covers purpose, usage boundaries, default behavior, and cost. It omits an explicit return-type description and error cases, but these are well-implied for text generation, and the schema handles parameter documentation. The tool's complexity is low enough that this is nearly complete.

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

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

Schema coverage is 100% with detailed parameter descriptions for prompt, model, and raw. The description adds only minor reinforcement (e.g., 'Claude orchestrator' for model) but doesn't introduce new semantic meaning beyond the schema. Baseline 3 is appropriate because the schema already 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 names the verb 'generate' and resource 'text' against a specific writing-model catalog, and enumerates concrete use cases (ad copy, hooks, scripts, rewrites, brainstorms). It explicitly distinguishes itself from ad-assembly tools (plan_ad → render_ad) and other generation siblings (image, voice, video), making its purpose unmistakable.

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

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

The description gives direct when-to-use (prompt-only text generation) and when-not-to-use (for a finished on-brand creative use plan_ad → render_ad) guidance. It also explains the raw:true option for non-marketing copy, providing clear selection criteria against 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?

All annotations are false (no readOnly/idempotent/destructive hints), so the description carries the full burden — and it carries it exceptionally. It discloses billing charges ('AUDIO IS NOT FREE... the bed can cost as much as the clip', 'Spends credits'), prompt rewriting by default with raw:true as the byte-identical escape, refusal over truncation ('a longer ask is REFUSED with nothing rendered and nothing charged'), silent resolution downgrades ('rendered at that model's best available tier instead, with nothing in the reply saying so'), and 1–3 min latency. This is far 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?

Every sentence earns its place given the tool's genuine complexity (12 params, billing, raw access, edit mode, routing) — nothing is filler. However, it is a single dense wall of text (~350+ words) with heavy ALL-CAPS emphasis, dashes and parentheticals that hurt scannability. Substantial but poorly structured for an agent to parse quickly.

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 12-parameter tool with zero annotations and no output schema, the description is essentially complete. It covers the return value (served mp4 URL), the single-clip duration ceiling with refusal behavior, the audio billing trap, credit spend, the raw bypass, edit-mode semantics, and model-routing pitfalls. Nothing an agent needs to call this tool correctly and avoid hidden costs 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 the schema's own per-parameter descriptions are unusually rich (durationSeconds, musicMood, resolution, raw are all deeply explained), so the baseline is 3. The description adds cross-parameter value by connecting the dots: it ties durationSeconds to model choice and the narrower auto-pool, links audio to musicMood and the automatic charge, and explains how refVideo nullifies aspectRatio/durationSeconds — synthesis the schema alone doesn't provide. The description complements rather than repeats 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?

Opening sentence states a specific verb and resource: 'Render a RAW video clip from your own prompt and return its served mp4 URL.' It further differentiates from render_ad ('use this for raw/experimental clips or precise manual control') and names the sibling it is not (render_ad runs the Studio quality pipeline). An agent can cleanly separate the two tools without inspecting either schema.

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

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

Explicit routing guidance: 'For finished brand ADS prefer render_ad... use this for raw/experimental clips or precise manual control.' It also gives concrete when-to conditions for editing (refVideo), for raw access (raw:true when you want the model itself rather than Hermoso's craft), and for naming a model (when you need the longest/highest-resolution tiers). The description explains not just what but when, with named alternatives.

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

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

Annotations only provide flags (readOnlyHint=false, etc.), which are neutral. The description goes far beyond by disclosing: cost implications ('Paid (a couple of credits by length; ≤900 characters)'), refusal behavior ('a name that engine does not have is REFUSED for free with its real list'), and the fact that some engines generate their own voice and ignore presets, with the reply indicating which voice actually spoke. This adds 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?

Though the description is long, every sentence carries actionable information. It leads with the core purpose and output, then defines scope exclusions, then details parameters, then covers edge cases and cost. There is no fluff, and the structure flows naturally from what to when to how. The density is appropriate for 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?

With no output schema, the description must convey the return value, which it does ('return the served MP3 URL'). It covers parameter semantics, defaults, refusals, cost, and character limits. It also references a sibling tool (hermoso_capabilities) for authoritative voice lists. An agent has everything needed to call this tool correctly in all scenarios.

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

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

Schema coverage is 100%, meaning all parameters are described in the schema. The description adds substantial meaning: engine defaults and valid values (seed-audio default, plus others), the relationship between engine and voice presets (preset must belong to engine), and directs the agent to hermoso_capabilities for the full voice list. It also clarifies the character limit and cost model. This goes well beyond the schema's basic 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 states a clear, specific purpose: 'RAW text-to-speech from the voice-model catalog: speak a script in a chosen voice and return the served MP3 URL.' It defines the resource (voice-model catalog), the action (speak a script), and the output (MP3 URL). It also explicitly distinguishes itself from sibling tools (render_ad, generate_video, change_voice) by stating what it is NOT for, leaving no ambiguity about its role.

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

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

Usage guidance is explicit: 'For a standalone voiceover / narration clip — NOT for adding audio to a video (render_ad and generate_video voice their own spots; change_voice re-voices a finished clip).' It also describes the engine choices with a default, mentions voice preset behavior, handles edge cases (engines that ignore presets and generate their own voice), and notes the character limit. This gives an agent clear conditions for 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?

Annotations already declare readOnlyHint: true, but the description adds value by detailing the content returned (products, logos, palette, positioning, learned memory), the hasBrand indicator, and the fact that it costs 0 credits. It also clarifies the tool's role relative to create tools, which is behavioral context not present in 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 three sentences, front-loaded with the primary purpose, then usage guidance, then a caveat. There is zero filler or redundancy. Every sentence earns its place, providing essential information in a compact form.

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

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

Given the tool has no parameters and no output schema, the description needs to cover return semantics and usage context—which it does thoroughly. It states the returned elements (products, logos, palette, positioning, memory), the hasBrand flag, the cost (0 credits), and the relationship to create tools. Nothing an agent needs to call it correctly is missing.

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

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

The tool has 0 parameters, and the schema is empty with 100% coverage. Per the rubric, 0 params gives a baseline of 4. The description doesn't discuss parameters (there are none), but it does clarify what the output contains, which is irrelevant to parameter semantics. Since there are no inputs to document, the score aligns with 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 explicitly states that this tool returns the saved brand profile (products, logos, palette, positioning) and learned memory for the account/workspace. It clearly differentiates from siblings like list_brands (which lists brands) and draft_brand (onboarding) by focusing on the current saved brand and the hasBrand flag. The verb 'get' is implicit via title, but the description makes the resource and 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?

Provides explicit when-to-use guidance: call it to check if a brand is on file, with clear branching (if hasBrand true, omit brand; if false, onboard with draft_brand). Also states when not to use it: not required before a render because create tools read the saved brand automatically. This is strong, actionable usage guidance that distinguishes from 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, and the description explicitly restates 'Read-only' (consistent, not contradictory). It adds value beyond annotations by listing the metadata fields returned, which helps the agent anticipate the response shape even without an output schema.

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

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

Two sentences with zero filler: the first states the action and return fields, the second gives the parameter source and read-only nature. It is front-loaded 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 read tool with one parameter and no output schema, the description fully covers the return fields and parameter origin. Annotations handle the safety profile. Nothing the agent needs to call it correctly is missing.

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

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

The schema already provides a description for fileId, and the description adds the crucial origin hint ('from list_drive_files'), which is not in the schema. This gives the agent actionable context for obtaining a valid 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 states a specific verb ('Fetch') and resource ('one Drive file's metadata'), and enumerates the exact fields returned (name, type, size, modified time, webViewLink, webContentLink). It clearly distinguishes from siblings like list_drive_files (which lists many) and update/delete_drive_file (which mutate).

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 a clear source for the parameter ('Pass fileId (from list_drive_files)'), which acts as an explicit usage hint. It doesn't explicitly list when not to use, but the purpose is unambiguous and there is no competing sibling for single-file retrieval.

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

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

Beyond the annotations (readOnlyHint, destructiveHint), the description adds crucial behavioral context: expected render duration (1–3 minutes), the polling loop, and the finality of the 'not_found' status including the cost implication of re-firing. This is operational nuance not covered by annotations and directly informs agent behavior.

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

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

The description is compact and front-loaded: it opens with the core action and return values, then provides timing and termination guidance. Every sentence earns its place, with 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?

Given the tool's simplicity (single parameter, no output schema), the description covers all necessary information: statuses, progress, URL on completion, polling expectations, and the not_found edge case. An agent can call this tool correctly without additional 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 coverage is 100% with a description for the id parameter ('the job id, e.g. job_xxx'). The tool description refers to the id but adds no additional semantic detail beyond confirming it targets a render job. Since the schema already captures the parameter meaning, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Poll a render job by id' and lists what it returns (status, progress, served media URL). This uses a specific verb (poll) and resource (render job), and distinguishes it from other get_* tools that retrieve different resources (e.g., get_brand, get_drive_file).

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