VidGuy

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

Annotations give readOnlyHint=false and idempotentHint=false, but the description adds the critical non-obvious behavior: the source must be uploaded via this path and its key prefix is validated, plus the 2GB size cap. It doesn't cover URL expiration, so not a full 5.

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

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

Two dense sentences, front-loaded with the action and the exact field names to use (uploadUrl, r2Key), with the caveat parenthetical in the right place. No waste.

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

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

No output schema exists, so the description correctly names the return values an agent must use (uploadUrl and r2Key). It links to the next tool in the workflow. Missing details like URL TTL or failure behavior, but the essential handoff is 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 33%, and the description adds the practical 2GB size ceiling that constrains fileSize. It does not clarify fileName/fileType semantics beyond what the schema shows. Baseline for partially documented params, with one useful added constraint.

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

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

States a specific verb and resource: get a presigned PUT URL for an AI Edit source video. Names the downstream sibling create_ai_edit and its own upload flow, distinguishing it from generic upload siblings like create_upload or swap_upload.

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 sequence: get URL, PUT bytes to uploadUrl, then pass returned r2Key to create_ai_edit. Also gives a constraint (source must be uploaded this way; key prefix validated) that tells the agent when not to bypass 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 cover safety profile (readOnlyHint=false, destructiveHint=false). Description adds pricing ('FREE') and critical downstream usage ('pass as seedImageAssetId to generate_influencer_look or build_influencer_vault'), which the annotations don't provide. Doesn't describe failure modes for non-stable URLs, keeping it from 5.

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

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

Front-loaded purpose, then cost, then prerequisites, then workflow. Every sentence carries useful information. Four sentences with some density but no fluff.

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

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

No output schema, but description explicitly states the return value (vault asset id) and how to consume it downstream. Covers prerequisites, cost, and integration path. Nearly complete for a mutation tool.

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

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

Schema description coverage is 100%, so baseline 3. Description adds the constraint that imageUrl must be a stable public/hosted URL and that influencerId comes from create_influencer, and describes role via 'identity reference'. Slight value add above 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 (Attach) and resource (user's own image as identity reference for an influencer). Clearly distinguishes from sibling create_influencer and generate_influencer_look.

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

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

Explicitly names import_asset_from_url and create_upload as prerequisite paths depending on source (URL vs raw bytes). Also tells the agent when to skip the paid look preview. Strong routing 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?

Goes well beyond the annotations by disclosing that the operation SPENDS CREDITS (≈25 per b-roll clip plus a flat premium when starterBundle=true), that the exact amount returns as creditsReserved, that it is refunded automatically on failure, and that builds take several minutes. Annotations only flag destructive/openWorld; the cost, refund, and latency behavior is the real added value.

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

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

Front-loads the core purpose and the credit warning, and every sentence carries information (async, cost, polling, duration, starter bundle). The caps emphasis and stacked clauses make it slightly dense, 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 no output schema, the description carries the return contract adequately: it returns a build job immediately with an id to poll. Cost, refund, latency, and the polling channel are all covered, so an agent has everything needed to invoke and follow up 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 82%, so the schema already documents most parameters. The description still adds meaning beyond it by explaining starterBundle's first-build pricing semantics and reinforcing the per-clip credit cost of brollCount, though turbo, resolution, and prompt get no extra description-level context.

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 (kick off an async build) and resource (influencer's vault), and enumerates exactly what the vault contains (character/reference sheet, on-camera stills, faceless b-roll, short clips). It also names the sibling polling tool get_influencer_vault_build, letting an agent distinguish it from generate_influencer_look or generate_influencer_studio_image without opening schemas.

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

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

Gives explicit conditions: poll get_influencer_vault_build until status 'completed', and pass starterBundle=true for the very first build after create_influencer. It warns not to poll as if instant. It does not, however, contrast usage against adjacent generation siblings (generate_influencer_look, generate_influencer_snack), so exclusions are only partial.

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

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

Annotations already declare readOnly/non-destructive, and the description corroborates rather than contradicts ('Read-only; this tool itself never moves money'). It adds substantial context annotations cannot convey: the 402 challenge flow, the exact payment headers (PAYMENT-REQUIRED, WWW-Authenticate), that the same request is retried with a payment header, and that credits land on settlement and never expire.

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 dense paragraph, but it is front-loaded with the highest-value fact (what the offer returns) and each subsequent clause carries actionable payment-flow detail. Slightly long and list-free for a multi-step flow that would benefit from structure.

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 payment-negotiation tool with an output schema (so return shape need not be restated), the description covers everything an agent needs: what is returned, which rails exist, how to trigger the challenge, how to settle, and when the credit arrives.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics beyond the schema: `required` originates from an insufficient-credits error and selects the smallest covering offer size, which clarifies the intended data source for that value.

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

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

States a specific verb and resource ('Get the offer for a pay-as-you-go credit top-up') and enumerates exactly what the offer contains: the POST URL, the USD price, and the accepted rails. It is clearly distinguishable from sibling account tools like get_credits because it returns a payment offer rather than a balance.

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

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

Gives clear triggering conditions: pass `required` when an insufficient-credits error blocks an action, or pass `credits` for a specific size. It never names an alternative sibling tool (e.g. get_credits) to route between, so it stops short of explicit when-not guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: the 409 failure condition, the downstream side effect that scheduled posts are also cancelled on the publishing provider, and the cost ('Free'). It does not describe what happens to the row post-call, keeping it out of the top band.

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 action and post states, then the failure condition and side effect. No sentence is padding; even 'Free' carries cost information an agent may need.

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 rich annotations and a fully described single-parameter schema, the remaining burden on the description is behavioral, and it covers the error case, side effects, and cost. The only gap is the post-call state of the row (deleted vs. marked cancelled), which is minor for a cancel operation with no 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?

Only one parameter (postId) exists and schema description coverage is 100%, so the schema already documents it as a social post UUID. The description adds no format, sourcing, or lookup guidance beyond that, making the baseline 3 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 states a specific verb (cancel/remove) and resource (social post) and enumerates the exact post states it handles: scheduled, draft, failed, cancelled. That state enumeration, plus the publishing exclusion, lets an agent distinguish it from siblings like retry_social_post or get_social_post without opening a schema.

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

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

It clearly states when the tool applies (scheduled/draft/failed/cancelled posts) and when it does not (posts already 'publishing' return 409). It stops short of naming an alternative for the publishing case or routing failed posts to retry_social_post, so it is strong context without explicit alternative routing.

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

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

The description discloses important behavioral traits beyond the annotations: statefulness ('the SAME persistent thread and memory'), side effects on future posting, synchronous latency (15–90s, up to 4 min), and the restriction that it cannot publish. These traits are not inferable from the annotations alone. 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 but efficiently organized: purpose, statefulness, constraints, latency, and the alternative tool are each covered in a few sentences. No filler or repetition; the most decision-relevant information is front-loaded.

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

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

Despite having no output schema, the description provides enough context for correct invocation: it explains behavior, latency, one-call-at-a-time semantics, the inability to publish, and the sibling alternative. An agent can confidently decide whether to call this tool and how to handle the response.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it only implies that 'message' is a single conversational turn and does not explain influencerId or message semantics beyond field names. The names are somewhat self-explanatory, but this is still a clear gap.

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

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

The description uses a specific verb and resource: 'have a live conversation with the influencer's agent brain.' It clearly distinguishes this tool from siblings by emphasizing the persistent thread/memory shared with the dashboard Chat tab and the advice-only, no-publishing constraint.

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

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

The description explicitly says when to use this tool (live, synchronous conversation) and when not to ('For fire-and-forget direction, prefer send_influencer_message'). It also gives concrete usage guidance: send ONE message per call and wait for the slow reply.

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 substantial behavior beyond annotations: asynchronous execution returning a projectId, the polling requirement via get_job, an explicit credit spend with a per-30s formula and a broll surcharge, and the default-off b-roll flag. This is exactly the kind of cost and lifecycle disclosure a destructive, non-idempotent tool needs.

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

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

Three tight sentences front-load the capability first, then async behavior, then cost, then prerequisite. The telegraphic parenthetical style is efficient but slightly dense; nothing is wasted.

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

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

With no output schema and an async lifecycle, the description supplies the missing pieces an agent needs: return contract (projectId), polling path (get_job), cost model, and prerequisite upload. Enum value meanings, the largest remaining gap, are not covered.

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

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

Schema description coverage is only 25% across 12 params, so the description must compensate and it partially does: it explains sourceR2Key's origin, broll's default and cost, and that sourceDurationSeconds drives cost. However, the six enum parameters (recipe, editStyle, captionStyle, outputFormat, sfxIntensity, captionPosition) and name/notes remain unexplained, leaving notable gaps.

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

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

States a specific verb and resource ('Polish uploaded footage') and enumerates the actual output features (captions, punch-ins, b-roll, SFX), which distinguishes it from generic create_video/create_ai_story siblings. It does not explicitly name a competing sibling, but the described capability is specific enough to route on.

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

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

Gives clear preconditions (requires an r2Key from ai_edit_upload) and the follow-up action (poll get_job), plus the credit cost of running it. It does not state when to prefer this over other video-creation siblings, so it falls short of 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 cover the safety profile (destructive=true, non-idempotent, openWorld), and the description adds material context beyond them: the async job pattern with a get_job polling loop and the credit cost (50 short / 80 medium). That cost and the required public URL are exactly the side-effect facts an agent needs before spending credits.

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

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

Three tight clauses, front-loaded with the core purpose, then async behavior, then cost/prerequisite. No filler; every sentence carries needed information.

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

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

With no output schema, the description correctly discloses the return shape (jobId, poll via get_job) and the credit cost. Remaining gaps are minor — it doesn't say what the finished artifact is (a video) or clarify the platform enum's effect, but it is sufficient to 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?

Schema coverage is 71%, so most parameters are already documented (prompt, duration, styleTemplateId, referenceImageUrl, styleReferenceImageUrl). The description reinforces referenceImageUrl must be public and ties 'short'/'medium' to scene counts, but adds little for the undocumented platform and name fields. 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 a specific verb and resource: 'Generate a dialogue-first short drama from a single reference image', with concrete scope (5-scene short / 9-scene medium). This is distinctive against generic siblings like create_video or seedance_generate_video, but it never names an alternative, so the differentiation is inferable rather than explicit.

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

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

It gives operational context — 'ASYNC — returns a jobId; poll get_job until completed' and 'Requires a public referenceImageUrl' — which implies usage. However, it gives no when-to-use guidance against the many other creation tools (create_video, create_ai_edit, seedance_generate_video), leaving the agent to guess which generator to pick.

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

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

Annotations already declare the mutation profile (not readOnly, not idempotent, not destructive), so the description's job is lighter. It still adds real behavior: no credit cost ('Free'), the defaulted targetAudience when omitted, and the returned id used for chaining.

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 tight sentences, purpose front-loaded, each carrying distinct information (when to use, param advice, cost, return/next step). Slightly dense but no wasted filler.

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

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

With no output schema, the return-value note is valuable, and the mutation intent is covered by annotations. However, for a 10-parameter creation tool with zero schema description coverage, over half the parameters give an agent no guidance at all, which is a meaningful gap.

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

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

Schema description coverage is 0%, so the description must compensate. It only addresses two of ten parameters — guidance on description length ('a few sentences') and the derivable targetAudience — leaving name, industry, websiteUrl, logoUrl, appDemo(s), screenshots and language entirely undocumented anywhere.

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

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

States a specific verb and resource ('Register a new brand') and disambiguates the resource by defining it as 'one of your end-customers', which separates it cleanly from create_influencer, create_character and similar creation 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?

'when none of the existing brands fit' gives an explicit precondition that implicitly routes the agent to list_brands/get_brand first, and 'pass that to generate_snacks' names the downstream step. It stops short of explicitly naming the alternative (update_brand) for existing brands.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false, implying mutation. The description goes beyond annotations by clearly stating the cost implications: cloning and image URL are free, while prompt generation spends 1 credit. It also reveals that library presets can be used directly, avoiding unnecessary clones, and that the return value is a characterId. This adds critical context for an agent deciding whether to call 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 dense but organized: it starts with the core purpose, then lists the three modes in a clear structure, and ends with a usage caveat. It is a bit long but each sentence adds value; the only minor inefficiency is repeating 'saved for FREE' which could be tightened.

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

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

Given the tool's complexity (three alternative inputs, cost implications, integration with other tools), the description is comprehensive. It covers prerequisites (import_asset_from_url), return value (characterId), and downstream usage (create_video). With no output schema, the description adequately explains the return value, and the annotations cover mutation/safety, so 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 covers all parameters with descriptions, but the description adds significant meaning by explaining the parameter relationships (e.g., fromLibraryId defaults name/voice, imageUrl requires hosting, prompt requires a 9:16 portrait and costs a credit). It clarifies that name is optional in cloning context, which is not fully explicit 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 clearly states the tool creates a saved character/actor for UGC video, distinguishes it from sibling tools like create_character_swap and list_character_library, and specifies the three input modes. It also explains the output (characterId) and its downstream use in create_video.

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: it details three mutually exclusive input methods (fromLibraryId, imageUrl, prompt), notes when to use import_asset_from_url for raw bytes, and warns against unnecessary cloning of library presets unless the user wants an editable copy, correctly routing to 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 mark it non-readonly, destructive, open-world, non-idempotent. The description adds material context the annotations don't: ASYNC with projectId + polling, credit cost (min 25, ×2 at 1080p, +5 for voice change), and reuse semantics for the driving key. This exceeds the annotation bar substantially.

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

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

Dense but every sentence earns its place: cost, async flow, prerequisites, batching tip, replay tip. Front-loaded with the core operation, 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?

For a 12-param async credit-spending tool with no output schema, the description covers cost, async behavior, prereqs, and reuse. It doesn't cover the half of params undocumented in the schema (name, prompt, sceneMatch), so an agent relying on the description alone would need the schema for those.

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

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

Schema coverage is 50%, so about half the params are undocumented in the schema. The description names the key inputs (characterR2Key, drivingVideoR2Key, r2Key from swap_upload) but doesn't explain name, prompt, sceneMatch, resolution, or the required file-name/duration pairs. Partial compensation, but gaps remain.

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 (swap) + resource (character image onto driving video) with a differentiating scope detail (optional range restoration). The reference to swap_import_character and swap_upload makes clear it's the downstream compositing step, distinguishing it from sibling import/upload 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?

Explicit prerequisites (character r2Key via swap_import_character or swap_upload, driving-video r2Key from swap_upload), polling flow (poll get_job), and a concrete batching strategy (upload once, call repeatedly with different characters). The replay pathway via get_video is named. This is unusually complete routing guidance.

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

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

Annotations declare it is not read-only and not destructive, so the bar is lower. The description adds crucial context beyond annotations: it is free, plan-gated with specific limits (starter 1, pro 5, enterprise 10, free 0), returns the new influencer id, and cannot be idempotent as each call creates a new profile. This is rich 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 dense but well-structured, front-loading the core purpose and cost. It uses multiple sentences efficiently, though the second sentence about attach_influencer_reference is slightly tangential to the creation act and could be separated as a 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?

Given 7 parameters with 86% schema coverage, no output schema, and annotations covering mutability, the description completes the picture by stating cost, plan limits, return value, and next-step workflow. An agent has everything needed to invoke correctly and plan subsequent calls.

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 high at 86%, so the baseline is 3. The description implies the required 'name' parameter but adds no syntax or format details beyond what the schema provides. It does clarify the return value (influencer id) but that is not parameter semantics.

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 ('Create a new persistent AI influencer identity') and maps it to the dashboard equivalent. It clearly distinguishes itself from siblings like generate_influencer_look and build_influencer_vault by noting those are the credit-spending steps.

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

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

Explicitly states when to use this tool ('FREE — this just creates the profile row') and names the alternative steps when the user wants the look or vault. It also provides a clear conditional workflow: 'To start from the user's own photo, call attach_influencer_reference next'.

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

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

Goes well beyond the annotations: discloses ASYNC execution, that a jobId is returned, that get_job must be polled, that per-slide assets come via get_video, and that it spends ~20 credits. It does not explain what the destructiveHint implies operationally, but the async/cost/polling detail is strong added value.

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

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

Three dense sentences with zero filler, front-loading what it produces before the operational details. Every clause earns its place, including the cost and polling instructions.

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

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

With no output schema, the description carries the return-path burden and does so (jobId → get_job → get_video). For a 4-param, credit-spending generation tool the async flow, cost, and input prerequisite are covered; only the platform/name params are left to the schema.

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

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

Schema coverage is 50% and the schema already documents prompt and referenceImageUrl. The description reinforces the reference-image requirement ('public referenceImageUrl', 'single reference image') but adds nothing for name or platform, so it stays at baseline.

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

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

States a specific verb (generate), a precise resource (portrait 5-slide deck), and a scoping constraint (varied from a single reference image). This is distinguishable from siblings like create_video and studio_generate_image without opening any schema.

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

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

Gives clear prerequisites (requires a public referenceImageUrl) and cost guidance, but never names an alternative or states when-not to use it. The agent can infer prerequisites but not how to choose this over the other creation tools.

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

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

Annotations already declare destructive/openWorld/non-idempotent, but the description adds substantial context beyond them: 'not retried server-side', 'pass distinct content per call', the 402 entitlement failure mode, and the free-cost model (no credits, provider seat applies). This is exactly the kind of live-side-effect warning an agent needs before invoking.

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 action and asset requirements before timing and caveats; every sentence carries distinct information and nothing is redundant. It is dense and a bit long, but the length is justified by the tool's 15-param 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 15-param, nested-object tool with no output schema this covers the critical call-path decisions (assets, timing, entitlement, side effects) well. It falls short only on the optional fields (per-account variants, platform overrides, visibility/draft), which remain undocumented.

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 0% across 15 parameters, so the description carries the burden. It well explains assetKind conditionality (video→videoUrl, photo/carousel→photoUrls, 2+ = carousel), scheduledAt, and addToQueue, but says nothing about tags, title, caption, visibility, saveAsDraft, thumbnailUrl, accountVariants, or platformOverrides (including the first_comment override). High-value partial compensation, but clear remaining gaps.

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

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

States a specific verb and resource ('Publish or schedule a post') plus scope ('one or more connected accounts on a brand ... multi-platform fan-out in a single call'). An agent can immediately distinguish this fan-out publish from siblings like cancel_social_post, retry_social_post, or publish_to_managed_account.

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

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

Gives explicit routing for the three timing modes (omit both = publish now; scheduledAt = specific time; addToQueue = auto-slot) and flags them as mutually exclusive. It also names the upstream alternatives (get_video outputUrl, import_asset_from_url, create_upload) for sourcing the asset URL.

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 the write/destructive/open-world profile, and the description goes well beyond them: credit cost per carousel, async job lifecycle and where slide URLs land, the fact that copy is real text rather than rendered pixels, and the non-obvious behavior that unknown `values` keys are reported in ignoredKeys instead of rejected. That ignoredKeys detail is exactly the kind of silent-failure context an agent cannot get from structured fields.

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

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

Front-loaded with the core purpose, then constraints (async, credits, max rows), then the optional image-generation recipe. It is long, and the embedded studio_generate_image prompt example is the one passage that reads as instruction rather than tool definition, but nearly every clause carries operational value.

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

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

For a high-complexity, credit-spending, destructive, async tool with no output schema, the description covers the return contract (jobId plus slide URLs on the job), cost, limits, key validation behavior, and the image-slot formats. Nothing an agent needs before invoking it 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 80%, so the baseline is 3; the description adds genuine semantic meaning on top — `values` keys must originate from list_carousel_templates (schema only says 'Keyed by the template's rowSchema keys'), image slots accept either a `collection:<pool>` reference or a direct URL, and the 12-row cap is restated. Seed and noRepeatScope are left to the schema, hence not a 5.

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

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

Opens with a specific verb and resource: 'Render a batch of TikTok photo carousels from a template', then narrows the artifact ('swipeable 1080x1920 slides, real library photos, copy composited as REAL text'). This is clearly distinguishable from siblings like create_slides, create_video and create_social_post without opening any schema.

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

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

Explicitly states the async workflow ('returns a jobId; poll get_job until completed'), names the prerequisite tool for key discovery (list_carousel_templates), names the alternative generation path for backgrounds (studio_generate_image with specific modelKey and prompt recipe), and gives hard limits (max 12 per call). When/when-not and alternatives are all present.

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

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

Annotations already declare the non-readonly, non-idempotent, non-destructive profile. The description adds real behavioral value beyond them: the two-step HTTP PUT workflow, both return values (uploadUrl and publicUrl), and the intended downstream use. It omits URL expiry, size limits, and auth requirements, which keeps it from a 5.

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

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

Three sentences, front-loaded with the core action, followed by the workflow and the alternative routing. Every sentence carries distinct information with zero padding.

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

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

With no output schema, the description usefully names both returned URLs and explains how to consume them. It is largely complete for a two-parameter tool, though URL lifetime and payload constraints would round it out.

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

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

Schema coverage is 50% — contentType is documented in the schema while filename is not. The description implies content type ('image/video') and the artifact being uploaded but adds no format or constraint detail beyond the schema, so the 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 a specific verb and resource ('Get a presigned PUT URL to upload an image/video') and precisely distinguishes the tool from a named sibling ('Prefer import_asset_from_url when you already have a URL'). An agent can identify the tool's role without opening the schema.

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

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

Provides explicit when-to-use ('upload an image/video directly'), when-not with alternative ('Prefer import_asset_from_url when you already have a URL'), and the downstream workflow ('pass publicUrl to a generation call'). Nothing about selection is left to inference.

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

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

Goes well beyond the annotations: discloses that it spends credits (~50–200, dynamic by duration/type), names creditsReserved as the return field, explains the async pattern (jobId → poll get_job), states refunds on failure, and gives the UGC input precondition. Annotations only say destructive/non-idempotent/open-world; the description supplies the actionable 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?

Tight, front-loaded block: async nature, cost, return/poll, and UGC precondition are all in three compact sentences with zero filler. Credit cost and refund behavior are stated before the UGC caveat, matching importance order.

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 an 8-param async job tool with no output schema, the description covers what the agent needs: cost, async/polling follow-up, failure refund, and the input preconditions for UGC branches. 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 63%, so the schema documents topic, script, characterId, scenePrompt, durationSeconds. The description adds cross-cutting meaning the schema lacks: which videoTypes are UGC ('ugc','brainrot','ugc-broll','ugc-demo') and that those require characterId + script, plus where characterId comes from. Doesn't cover platform/additionalInstructions meaning, so not a 5.

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

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

States a specific verb+resource ('kick off an ASYNC full video production job') and names the exact flow ('Quick Create'), distinguishing it from siblings like create_ai_edit, create_ai_story, or seedance_generate_video. An agent can pick this tool apart from the other ~70 creation/upload tools without opening the schema.

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

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

Gives strong context: it's the Quick Create flow, UGC types require characterId + script (with pointers to list_characters/list_character_library). However it doesn't explicitly state when NOT to use it vs. its many sibling video-generation tools (create_ai_edit, seedance_generate_video, studio_generate_video), leaving routing inferred.

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 destructive/openWorld, but the description adds the crucial substance: approving publishes REAL posts to live accounts, reject also vetoes approved-but-unpublished scheduled drafts, and reason feeds learning. These side-effect details go well beyond the annotation flags.

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

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

The critical consequence (APPROVING PUBLISHES) is front-loaded in caps, followed by the gating rule and edge cases. Dense but every sentence carries non-redundant information.

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

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

For a destructive publish gate with no output schema, the description covers the side effects, the required human authorization, the reject semantics, and the scheduledAt constraint. Nothing needed 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?

With only 40% schema coverage, the description compensates well: it explains decision semantics (reject teaches via reason), the scheduledAt ISO-8601 override and its single-draftId constraint, and the single-draft restriction. Only influencerId is left unexplained, a minor gap for an obvious scoping id.

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

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

States a specific verb pair (approve/reject) and the exact resource (an influencer agent's proposed content drafts). An agent can distinguish this from siblings like get_influencer_agent or publish_to_managed_account without opening any schema.

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

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

Explicitly names the prerequisite (user has seen the drafts via get_influencer_agent and said which to approve), the prohibition (never bulk-approve on your own judgment), and the human-in-the-loop gating condition. When-to-use, when-not-to-use, and the alternative read tool are all present.

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, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description nonetheless adds genuinely useful cascade behavior beyond the annotations: referencing snack posts survive and their brandId is nulled. It could still say whether the operation fails if the brand is in use or what the response contains.

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 action and immediately followed by the two facts an agent most needs (cascade behavior, irreversibility). 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 one-parameter destructive tool with full annotation coverage and no output schema, the description supplies everything material: what is deleted, what happens to dependent data, and that it cannot be undone. 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 description coverage is 100% and there is a single required parameter already documented as 'Brand UUID' in the schema, so the description adds no parameter meaning. Baseline 3 for a fully documented single-param 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 (delete) and resource (brand) unambiguously, distinguishing it from sibling deletes like delete_managed_post and delete_influencer_studio_image by resource. The follow-up sentences clarify the scope of the deletion's side effects.

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

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

Usage is only implied: the description makes clear this is a destructive, irreversible removal, but it never says when to prefer delete_brand over alternatives such as update_brand or simply leaving the brand intact, nor does it mention prerequisites like ownership or permissions.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false. The description adds genuinely useful context beyond those: only the gallery row is removed while the underlying file and any promoted vault copy survive, which materially changes how an agent should reason about the delete's blast radius.

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

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

One front-loaded sentence that states the action, the keys, and the scoping caveat with 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 destructive single-row delete with no output schema, the description adequately covers what is removed and what is preserved. Minor omissions (auth/permission needs, behavior if the id matches nothing) keep it short of full completeness.

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 0%, so the description must carry parameter meaning. It adds that generationId is preferred over url as the lookup key, which is real guidance, but it says nothing about the required influencerId or any value formats, leaving a meaningful gap.

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

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

States a specific verb (remove/delete) and resource (influencer studio gallery row) and identifies the two lookup keys. It is clearly distinguishable from siblings like list_influencer_studio_images and generate_influencer_studio_image.

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 preference between parameters ('generationId (preferred) or url') which implicitly guides invocation, but never states when to use this tool versus alternatives or any preconditions. Usage is implied rather than spelled out.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds preconditions and failure semantics the annotations cannot express: published posts return 400, hosted-account posts return 409 with support instructions, and the operation is 'Free'. This is materially useful context for a destructive call.

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

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

Three tight sentences, front-loaded with the core constraint (scheduled-only) before the edge cases. Every sentence carries a distinct, load-bearing fact with 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?

For a two-parameter destructive tool with no output schema, the description covers the preconditions, the two distinct error outcomes, and the account-type nuance. Nothing an agent needs to invoke this correctly or interpret failure is missing.

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

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

Schema coverage is 100% — both accountId and postId are documented in the schema, including the pointer to list_managed_posts. The description adds no new syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Delete a managed post') and narrows the scope precisely to one that 'is still scheduled (queued, not yet live)'. This distinguishes it from siblings like cancel_social_post and delete_brand without requiring the schema to be opened.

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 gives the when ('still scheduled'), the when-not ('Once a post has published it can no longer be removed'), and the account-specific exclusion ('On hosted accounts a submitted post is already a work order... cannot be withdrawn through the API'). It even routes the agent to the correct fallback ('contact support').

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?

Delivers rich behavioral context beyond annotations: async nature with a returned dubbingId, the polling follow-up, and the 10-credit cost. This is exactly the operational detail annotations (destructiveHint, openWorldHint) cannot 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?

Front-loaded with the core action, then async behavior, cost, and enum codes in a compact span. Every clause carries information, though the trailing code list is somewhat dense.

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

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

For a 2-param async tool with no output schema, the description supplies the missing pieces an agent needs: async pattern, follow-up tool, cost, and valid inputs. Nothing critical is absent.

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

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

Schema coverage is 100% and both parameters are fully described in the schema, so the description's enum listing of targetLang codes merely repeats structured data. 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 a specific verb (dub) and resource (a COMPLETED project's video into another language), plus the provider (ElevenLabs). Distinguishes itself from siblings like get_dub_status and create_video.

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 constrains usage to COMPLETED projects and directs the agent to poll get_dub_status afterward, which is clear operational guidance. It does not name when not to use it versus alternatives, but the workflow routing is strong.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds important behavioral context: 'No credits spent, no I/O' and a pricing model. It does not mention auth requirements or rate limits, but the added side-effect clarity is valuable.

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 and pricing formula. Every sentence adds useful information without waste.

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 has an output schema, so return values need not be explained. The description provides the base cost, key adjustments, and no-side-effect assurance. It is nearly complete, though it does not fully document all exclude enum values or default parameter behavior.

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

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

Schema description coverage is 0%, so the description partially compensates by explaining that excluding 'ai-ugc' saves 5 credits and server-side render adds 3. It does not explain the full exclude enum or default behavior for either parameter, leaving gaps.

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 (estimate) and resource (credit cost of snack generation) with clear scope (before running it). It distinguishes this tool from generation siblings like generate_snacks by emphasizing estimation rather than execution.

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

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

The phrase 'BEFORE running it' clearly signals when to use the tool: prior to generation. However, it does not explicitly name alternatives or state when-not to use it, leaving the routing to inference from sibling names.

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 information annotations don't carry: it costs 1 credit, credits are refunded on failure, and it returns both a preview image and a vault asset id. This meaningfully supplements the destructive/non-idempotent/openWorld hints. It stops short of disclosing any rate limits, auth requirements, or generation latency.

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

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

Four sentences, each carrying distinct payload: purpose/ordering, cost/refund, return shape, and the reference-photo workflow. The key scoping constraint is front-loaded and nothing is redundant.

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

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

With no output schema, the description still names what comes back (preview image plus vault asset id), and it covers the pre-build approval intent, credit behavior, and the reference-anchoring prerequisite. An agent has everything needed to sequence and invoke it correctly.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds workflow meaning: seedImageAssetId comes from attach_influencer_reference and anchors identity to the user's own photo. That is value beyond the schema's field-level 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?

States a precise verb+resource ('generate a single cheap look preview portrait for an influencer') and explicitly scopes it as a pre-approval step distinct from the full vault build. Repeating that the vault later seeds from this look makes the tool's role unmistakable.

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

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

Explicitly says to use it BEFORE the full vault build so the user can approve the face, and gives a concrete prerequisite chain: call attach_influencer_reference first, then pass its returned asset id as seedImageAssetId. Both when-to-use and the alternative (vault build) are named.

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

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

Discloses many behaviors beyond annotations: async job with jobId, ~2 min minimum generation time, credit spend with creditsReserved and failure refund, and a 10 packs/hour rate limit. Doesn't fully explain what destructiveHint=true means in this context beyond credit spend, but the async/rate-limit/credit disclosure is strong.

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

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

Very dense and informative, but poorly structured—parentheticals and stray clauses ('(It only errors...' etc.) make it a wall of text rather than front-loaded points.

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?

Complete for a 5-param async generation tool: covers credit cost, rate limit, polling via get_influencer_snack, expected latency, brand fallback logic, and sibling differentiation.

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

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

Schema coverage is 100% with all five parameters documented, so the schema carries parameter semantics. The description adds the meaning of the async output (jobId) but no new per-parameter detail beyond the schema.

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

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

States a specific verb (Kick off/Generate), resource (snack content pack), scope (in the voice of a specific influencer), and explicitly names its sibling generate_snacks as the brand-scoped alternative.

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

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

Explicit when-to-use ('+ New content' action on the influencer's Content tab), states brand context is automatic so no brand attachment is needed, names the failure condition (no brand at all), and clearly distinguishes from generate_snacks.

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

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

Goes well beyond annotations by disclosing the model (Nano Banana 2 Lite), cost (1 credit), synchronous execution with typical ~10–30s latency, that the asset URL is returned in the result, that results land in the studio gallery, and how keepers reach the vault. This is exactly the operational context annotations cannot 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?

Front-loaded with the key operation, model, cost, and sync behavior before the usage guidance. Dense but nearly every clause carries signal; only the vault-promotion note is somewhat peripheral to calling the tool.

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

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

No output schema exists, and the description compensates by saying the asset URL is in the result and where the asset is stored. Combined with annotations covering the mutation profile, an agent has enough to invoke correctly, though aspectRatio guidance would complete it.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does this well for prompt and referenceImages (up to 4, https or data URLs, suggested uses), but aspectRatio's enum and influencerId's UUID format/role get no explanation, leaving two of four params undocumented anywhere.

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 ('Generate ONE on-identity image of an influencer') and implicitly separates itself from siblings like studio_generate_image or seedance_generate_image by calling out the server-side character reference injection that makes the output on-identity. An agent can tell this is the influencer-scoped generator.

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 strong intra-tool guidance ('describe the SCENE, outfit, or action, not the person') and clarifies how referenceImages are used, but never states when to prefer this over adjacent tools such as generate_influencer_look or studio_generate_image. Usage context is implied rather than compared 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?

Adds substantial behavior beyond the annotations: async jobId return, ~1-3 minute latency, per-type credit costs, automatic refunds on failure, and silent per-slot skipping. The destructiveHint=true is sensibly explained by the credit-charging language, though the description never explicitly frames credit spend as the destructive aspect, leaving that inference to the reader.

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?

Opens with the core action, then layers modes, cost, optionality, and async caveats in a single dense paragraph. Despite its length, every clause conveys operational information an agent needs, and non-obvious pitfalls (silent skips, refunds) are front-loaded where relevant.

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

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

For a 4-parameter, async, credit-consuming, open-world generation tool this leaves nothing material unstated: it covers mode selection, cost, refund behavior, polling, latency, and partial-result risk. With an output schema present, the description does not need to document return fields and rightly skips them.

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

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

Schema coverage is already 100%, yet the description still adds real meaning: count is bounded 1-5 and cautioned that fewer may land, brandId's omit-vs-pass semantics are spelled out, each enum value carries a credit cost and behavior, and prompt is illustrated with concrete source examples (changelog line, blog title, launch note).

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

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

States a specific verb (create) and resource (memes) plus the input modality (plain-language prompt) and enumerates the three distinct modes. An agent can immediately tell this apart from studio_generate_image, seedance_generate_image, and create_slides, which are the nearest media-generation 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 describes when to choose each memeType (edit vs greenscreen vs comic), when to include brandId (with a pointer to list_brands) versus omit it, and how to operate the async flow (poll get_job). It even pre-empts the common confusion that the caller must supply the joke.

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?

Discloses credit spend (18–26), async semantics and minimum ~2–3 min latency, automatic credit refund on failure, and the render outcome split. Annotations (destructiveHint, openWorldHint, idempotentHint=false) are all consistent and reinforced by the description.

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

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

Dense but every sentence carries a distinct operational fact (cost, prerequisite, async timing, render flag, refund policy). Front-loads the async + credit cost before 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 7 params, a rich output schema, mutation annotations, and a crowded sibling set, the description covers the full lifecycle: cost estimate → prerequisite resolution → async submission → polling workflow → render option → refund safety net. Nothing material 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 86%, so the baseline is 3, but the description adds non-obvious cross-parameter interactions: render adds viewable assets inline, without render it's a manifest, and excluding 'ai-ugc' saves 5 credits — costs the schema itself doesn't communicate.

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?

Specific verb+resource+scope: 'Kick off an ASYNC snack generation job for a brand.' Distinguishes itself from siblings by naming estimate_snack_cost, list_brands, create_brand, get_job, and the dashboard viewUrl flow.

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 prerequisites ('call estimate_snack_cost first', 'call list_brands first, or create_brand'), the alternative for rendering (render=true vs manifest), and the follow-up tool (poll get_job). No other tool in this namespace does this.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds nothing beyond the annotations – no note on what happens if the id is missing (error? empty?), no auth context. With annotations carrying the safety burden, some added value would be expected, but none 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?

One front-loaded sentence, no waste. Appropriately sized for a simple single-fetch 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?

For a 1-param read tool with full schema coverage and annotations, a minimal description is largely sufficient. However, no output schema exists, and the description doesn't describe what a brand contains, so an agent doesn't know the return shape.

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 documents brandId as a UUID. The description doesn't add syntax or format details beyond the schema. Baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb (Fetch) and resource (brand) with scope (single, by id). Clear enough to distinguish from list_brands and get_influencer, though it doesn't explicitly name those 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?

Implied usage: fetch one brand when you have its id. No explicit when-to-use vs list_brands or pointers to alternatives. Adequate but minimal guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered; the closing sentence ('never changes the agent or its work') largely restates that. The real added value is the inventory of what the payload contains (tasks, runtime/budget, recent runs, messages, knowledge, source files, review clips, Editor projects, Spy signals), which is meaningful given no 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?

Front-loaded with the verb+resource, then the prerequisite, then the read-only guarantee. The long enumeration of returned data is dense but earns its place since there is no output schema; only the near-redundant restatement of the read-only hint is filler.

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

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

With no output schema, the description usefully characterizes the return payload and the id-resolution path, which is enough to call this read tool correctly. It could go one step further by distinguishing itself from get_influencer_agent, which is the main remaining gap.

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

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

Schema coverage is 100% and the schema already documents agentId as a UUID from list_content_agents. The description repeats the same provenance, adding no format or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (fetch) and resource (content-team agent) plus scope (by id, with full read-only dashboard context). It also enumerates the returned surface areas and distinguishes itself from list_content_agents, so an agent can identify it without opening the schema.

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

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

Explicitly instructs 'Call list_content_agents first to resolve the id', which is concrete prerequisite guidance. It does not, however, address when to prefer this over the sibling get_influencer_agent, so the when-not case is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, and the description's 'Read-only; no credits spent' largely restates that. It adds little behavioral detail beyond annotations, though it does indicate the response includes plan allotment and recent transactions, which is useful framing.

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 filler: the first defines the payload, the second gives the triggering condition. The scoping and safety note are front-loaded rather than buried.

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?

Annotations cover the safety profile and an output schema exists, so the description doesn't need to explain return values. For a zero-required-parameter read tool, 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 description coverage is 100% and the single optional 'limit' parameter is fully documented in the schema, so the description need not restate it. It adds no syntax or default guidance beyond what the schema supplies, matching 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?

States a specific verb and resource ('Check the account's current credit balance, plan allotment, and recent credit transactions'), which cleanly separates it from siblings like buy_credits and estimate_snack_cost. An agent knows exactly what it retrieves without opening the schema.

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

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

Explicitly says when to call it ('before a credit-spending generation') and names the specific spending tools it should precede (create_video, generate_snacks, studio_*, seedance_*, etc.). This is a model routing instruction rather than vague 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 indicate a destructive, non-read-only action. The description adds meaningful side effects: contacting the provider, storing the dub, replacing the project asset reference, and potentially refunding the original charge. 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 concise sentences, front-loaded with the core purpose and followed by the important side effects and output behavior. No filler or redundant wording.

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

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

The description covers the important output states and the post-completion videoUrl behavior, and explains both completion and failure side effects. It is complete enough for an agent to invoke the tool, though it does not describe the exact response shape.

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 low at 33%: only dubbingId has a description and it is minimal. The tool description does not meaningfully explain projectId or targetLang, and does not compensate for the missing parameter documentation.

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

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

The description states a specific action (poll and finalize) and resource (a language-dub job), enumerates completion/failure behavior, and explicitly says it does not start a new dub, which distinguishes it from dub_video.

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

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

The description implies this tool is used after a dub has started and clarifies it will not start a new one. However, it does not explicitly name the alternative tool or state additional conditions such as 'do not use if you need to create a dub.'

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the shape of the returned profile (persona, visual identity, voice, status, metadata), which is useful since there is no output schema, but it discloses no further behavioral traits such as error conditions or permissions.

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

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

Two short sentences, front-loaded with the action and resource, followed by the routing prerequisite. No filler and nothing redundant.

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

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

For a single-parameter read-only getter, this is complete: annotations cover safety, the schema covers the id, and the description covers the returned fields in lieu of an output schema and points to the discovery tool.

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

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

Schema description coverage is 100% and the single influencerId parameter is already documented in the schema as coming from list_influencers. The description's 'by id' and provenance note therefore add no meaning beyond what the schema 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?

States a specific verb (fetch) and resource (one influencer profile by id) and enumerates the profile contents (persona, visual identity, voice, status, metadata). This clearly separates it from sibling list_influencers, which returns collections rather than a single profile.

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

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

Explicitly tells the agent the prerequisite workflow and the alternative source of the id: 'Call list_influencers first to get the id.' An agent knows both when this tool applies and where to obtain the required input without opening another schema.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered; the description's restatement of 'Read-only' is redundant. What adds value is the disclosure of computed, non-obvious return contents (trust scorecards, learned playbook, today's trend brief, live metrics on published drafts) that aren't inferable from the schema.

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

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

Front-loads the core action and sequencing instruction ('Call this FIRST') while the long enumeration of returned data earns its place by aiding discovery. It is dense but not padded, and the key directive is not buried.

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 burden of explaining the return, which it does thoroughly by listing every returned artifact. Combined with the when-to-call guidance and annotation-covered safety, only minor detail (e.g., pagination or sizing of runs/drafts) is absent.

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

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

Schema coverage is 100%, so the single influencerId parameter is fully documented in the schema itself, which even names list_influencers as the source of the id. The description adds no parameter-level detail, which is acceptable at this coverage level but yields the baseline 3.

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

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

States a specific verb (Fetch) and resource (the autonomous posting agent attached to an influencer), then enumerates its exact payload: settings, runs, drafts, scorecards, playbook, trend brief, and knowledge base. This clearly distinguishes it from the sibling get_influencer and from update_influencer_agent without requiring the schema.

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

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

Explicitly instructs 'Call this FIRST — before updating settings, deciding drafts, or answering its questions,' naming the exact conditions and the sibling operations (update_influencer_agent, decide_influencer_drafts, chat_with_influencer) that this tool should precede. Sequencing guidance leaves nothing 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 cover safety (readOnly, non-destructive, closed-world). The description adds real behavioral context beyond annotations: it's a polling tool, it returns status/progress, completed state attaches rendered assets as resource links, and the result carries a dashboard viewUrl. It doesn't state any polling interval or terminal error states, but the completion behavior is well disclosed.

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

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

Three tightly packed sentences, each earning its place: what it does, what completion yields, and the follow-up sibling. Front-loaded with the action and zero 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 2-param polling tool with a full schema and annotations covering safety, the description supplies the lifecycle, completion payload description, and downstream linkage. No output schema exists, and the description conveys the key return concepts (status/progress, asset links, viewUrl), which is sufficient; a bit more on failure/in-progress polling guidance would make it a 5.

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

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

Schema coverage is 100%, and both parameters are documented in the schema (jobId explicitly notes it comes from generate_influencer_snack). The description restates the jobId lineage but adds no syntax or format detail beyond the schema, 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?

States a specific verb+resource (poll a snack pack job) and explicitly ties the lifecycle to the sibling that creates it (generate_influencer_snack) and the sibling that lists the finished result (list_influencer_snacks). An agent can distinguish this from get_snack and get_job without opening 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?

Explicitly names the prerequisite (started by generate_influencer_snack) and the downstream action (list_influencer_snacks will then include the finished pack). The lifecycle sequence makes when-to-use vs. siblings unambiguous.

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

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

Annotations cover the safety profile (readOnly, non-destructive), so the bar is lower. The description still adds genuine behavioral context: it names the polled tool, lists the progress fields returned (status, progressPercent, creditsReserved/credits, error), and gives the completion transition. It does not state a polling interval/frequency, which is a minor gap.

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

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

Three tight sentences, front-loaded with the core action, then the return shape, then the next step. No waste; 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 2-param polling tool with annotations covering safety, the description supplies everything needed: the originating tool, the returned progress fields, the error channel, and the completion workflow. No output schema exists, yet the description compensates by enumerating the return fields.

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 meaningful linkage beyond the schema by tying jobId to 'started by build_influencer_vault' and describing it as a returned build job id, reinforcing the parent-child relationship between the two tools.

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 (poll status), resource (vault build), and names the originating tool build_influencer_vault. An agent can immediately distinguish it from build_influencer_vault or list_influencer_assets.

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 identifies itself as a polling tool for a build started by build_influencer_vault, and routes the agent forward: when status is 'completed', call list_influencer_assets. Clear when-to-use and next-step guidance.

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

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

Annotations already declare readOnly=true and destructive=false, and the description adds valuable runtime behavior: status token variants ('succeeded' in Studio/SeedDance), minimum job duration (≥2 minutes), the exception for TikTok Carousels, and the fact that completed outputs are attached as inline resource links. This is exactly the behavioral context the annotations do not provide.

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

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

The description is long but every sentence carries decision-relevant information: scope, coverage, statuses, timing, output links, and exceptions. It front-loads the universal purpose and then packs specifics without filler, earning 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 universal poller that spans many generation tools, the description tells an agent exactly what to poll, which status strings to expect, how long to wait, and which sibling pollers to use instead. The presence of an output schema makes detailed return-type documentation unnecessary, so nothing needed to call it correctly is missing.

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

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

The schema already describes jobId as accepting jobId or projectId, so coverage is 100%. The description adds value by enumerating which source calls produce jobIds versus projectId (e.g., AI Edit / Character Swap), helping the agent map the correct id form to the originating call. This enrichment justifies above-baseline scoring.

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 precise verb-object pair ('Poll ANY async VidGuy job by its id') and immediately labels it 'the universal poller.' It enumerates the covered source tools and explicitly names dedicated siblings for exceptions, so an agent can distinguish it from get_video, get_dub_status, and others without opening their schemas.

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

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

It states clearly when to use the tool (any async generation) and when not (influencer vault builds / snack packs and dubs have dedicated pollers, named explicitly). It also provides concrete polling cadence guidance (~10s for generations, ~3s for TikTok Carousels) and warns against treating early 'processing' as failure. This is full usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description usefully adds that the call is 'Free' and enumerates the returned fields, but says nothing about what happens for an unknown id or any rate-limiting 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?

One tightly-packed sentence that front-loads the verb and key scoping detail. The field enumeration is dense but earns its place as the only documentation of what the tool returns.

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, enumerating the returned fields (status, postable flag, platform, handle, profile, warming progress, cached analytics, posting rules) is genuinely necessary and largely covers the return surface. Only error/not-found behavior is absent.

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

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

Schema coverage is 100% and the single accountId parameter is documented as a 'Managed account UUID'. The description's 'by id' adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Fetch) and resource (one managed account) scoped by id. The 'one' implicitly contrasts with list_managed_accounts, but no sibling is named explicitly, so differentiation relies on inference.

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

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

No guidance on when to use this versus get_managed_account_capacity, get_managed_accounts_pulse, or list_managed_accounts. The 'by id' phrasing implies direct lookup, but alternatives and prerequisites are never mentioned.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, not open world). The description adds real behavioral context beyond them: the 60-day horizon, the warm-up gating rule, the notice-days requirement, and that the call is free. It stops short of pagination/error behavior, but for a read-only helper this is strong.

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

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

Front-loads the core question, then packs constraints, return fields, usage guidance, and cost into a tight block. The mid-sentence enumeration of return fields is dense but every clause carries information; nothing is redundant with the schema.

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

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

No output schema exists, so enumerating earliestQueueDate, firstOpenDay, dailyCap, creditsPerPost, countsByDay/fullDays and warm-up progress is necessary and done well. Combined with the when-to-call guidance, an agent has everything needed to invoke and interpret the result.

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

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

Schema description coverage is 100% for the single accountId parameter (UUID), so the schema already carries the semantics. The description adds no further syntax or format detail for the parameter, so the baseline 3 applies.

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

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

The opening sentence gives a specific verb+resource — determining which days a managed account can accept posts — and immediately distinguishes it from the sibling list/publish tools. An agent can tell it answers a capacity/eligibility question, not a generic account lookup.

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 the trigger condition and the alternative: 'Call this before publish_to_managed_account to pick a legal queueFor day.' It names the consuming tool and the downstream decision, which is exactly the routing guidance an agent needs.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered. The description still adds real operational context beyond them: metrics are cached and refreshed about daily, the call is cheap, it is free, and accountsWithMetrics/accountsTotal plus capturedAt disclose that coverage may be partial or stale.

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 what the tool returns and scoped by cost/caching before the alternative route. The long metric enumeration is dense but each element is informative; no filler sentences.

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

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

With no output schema, the description takes on the full burden and discharges it by naming the return fields (views/likes/comments/shares/posts/followers, delta, per-day and cumulative series, coverage counters). An agent has enough to decide to call it and interpret the result.

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

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

Schema description coverage is 0%, so the description must carry the single parameter, and it does enumerate the valid windows ('last 7, 30 or 90 days'). It does not state the default of 30 that the schema supplies, so it is good but not fully compensating.

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

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

The first sentence names a specific verb+resource ('Roll-up of ALL your hosted / managed accounts' performance') and enumerates the exact metrics returned, so scope is unmistakable. It also draws an explicit boundary against get_social_analytics for single-account breakdowns, letting an agent distinguish it from siblings without opening schemas.

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

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

It states the period options, that it is served from cached metrics and cheap, and that it is free, plus an explicit alternative with a named parameter ('For one account's breakdown use get_social_analytics with source managed_account'). That is a complete when-to-use/when-to-use-something-else 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?

With annotations indicating readOnlyHint=true, openWorldHint=false, and destructiveHint=false, the safety profile is clear. The description adds valuable behavioral context: it returns a dashboard viewUrl and attaches scene visuals as resource links, and clarifies that these are source clips/images with text overlays and greenscreen applied at render time, directing users to open the viewUrl for the final result.

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

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

The description is two sentences, front-loading the core purpose and then detailing the return behavior. It is reasonably concise, though slightly dense with technical details about resource links and rendering, but every sentence contributes.

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 there is no output schema, the description provides crucial information about the return value: a viewUrl and resource links for scene visuals, with an explanation of rendering differences. It is nearly complete, though it could mention pagination or error cases, but for a single-item fetch, it covers the essentials.

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 only parameter (snackId) is fully described in the schema as 'Snack post UUID'. The description adds no additional parameter details 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?

The description clearly states a specific verb (Fetch) and resource (a single snack post with its manifest) by id. It distinguishes from list_snacks by specifying it fetches one by id, but doesn't explicitly name the sibling alternatives like get_influencer_snack or list_snacks.

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

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

The description implies usage by stating 'by id', which suggests it should be used when you have a snackId. However, there are no explicit when-to-use or when-not-to-use statements, nor any mention of 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, destructiveHint=false, and openWorldHint=true. The description adds real value beyond that: it enumerates the exact returned fields (totals, deltas, engagement rate, platform/content breakdowns, series, data-quality flags, top posts) and flags 'Free' cost. This is meaningful behavioral context that annotations alone would 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?

Front-loaded with purpose, followed by a compact enumeration of return contents, then usage guidance and cost. No filler sentences, though the return-field list is dense and could be tightened.

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

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

With no output schema, the description does the work of describing the return shape via its field enumeration, which is the key missing structured data. Combined with the usage cue and cost note, it is nearly complete for an analytics read tool. Slightly less than full because the days window semantics (7/30/90) and source-specific behavior are not explained.

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

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

Schema coverage is only 33%, but the enum for source and the const values for days are self-documenting in the schema, and targetId carries its own pattern and description. The description adds the semantic distinction that the target can be either a connected brand or a managed account, which is useful but modest. Baseline 3 given the partial 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?

States a specific verb (return) and resource (analytics snapshot) with the two valid target types (Social Brand or hosted managed account). Distinguishes itself from siblings like get_social_post or list_social_posts by scope, though it never explicitly names an alternative.

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

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

Explicitly says 'Use this before making performance claims or content recommendations,' which gives clear context for invocation. No when-not-to-use conditions or named alternatives, so it stops short of the top score.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds value beyond that: it discloses what data is returned (status, scheduledAt/publishedAt, provider URL once live, error message) and that the call is free — no credit spend. It omits any auth or error-handling behavior, keeping it short of a 5.

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

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

One sentence, front-loaded with the verb and resource, with the return payload and cost note packed into a tight em-dash clause. 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?

With no output schema, the description carries the return-value burden and does so by naming the key fields an agent would need. Combined with annotations covering safety and the explicit 'Free' cost signal, an agent has enough to call it correctly; only pagination/auth edge cases are unaddressed, which is minor for a single-record fetch.

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 there is a single parameter (postId, a social post UUID), so the schema fully documents the input. The description adds only 'by id', which conveys no extra syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (Fetch) plus resource (one connected-account post) and narrows scope to lookup by id, which separates it from list_social_posts. It enumerates the returned fields, so the agent knows exactly what it gets. It does not explicitly name the sibling to use for listing, so it falls just short of a 5.

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

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

Usage is implied by 'by id' — the agent infers this is for retrieving a known post rather than discovering posts. There is no explicit when/when-not statement or pointer to list_social_posts for enumeration. The trailing 'Free' hints at a cost consideration but is not framed as 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 cover the safety profile (readOnly, non-destructive), and the description adds real behavioral context beyond them: the output video is surfaced as a resource link when available, and Character Swap projects include replayable settings (r2Keys, keepOriginalVisualRanges, resolution, sceneMatch, saveAudio) plus signed previews. This is meaningful disclosure an annotation cannot carry.

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

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

Front-loaded with the core action and return set, then layers the Character Swap special case. Two dense sentences with no wasted filler, though the second sentence is somewhat long.

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 appropriately enumerates the return payload (status, outputUrl, brief, per-format asset tiles) and the Character Swap extension. An agent knows what it will get back and how the resource link behaves.

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

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

Schema description coverage is 100% and the single videoId param is already documented as a 'Project UUID from list_videos'. The description restates 'by its id' but adds no format, sourcing, or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Fetch one video project by its id') and enumerates what is returned, which distinguishes it cleanly from the sibling list_videos. An agent can tell this is the singular retrieval counterpart to the list operation without opening the schema.

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

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

Usage is implied (fetch a single project by an id obtained from list_videos, per the schema text), and the Character Swap note hints at a replay workflow, but there is no explicit when-to-use/when-not guidance or comparison against alternatives such as get_job.

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

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

Annotations already signal a non-read-only, open-world, non-idempotent, non-destructive operation, so the safety profile is covered. The description adds genuinely useful traits beyond that: returns a stable hosted URL, is free, and has a 50MB size ceiling — none of which are in the annotations or schema.

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

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

Front-loads the core action and the return value, then adds when-to-use and constraints. Three tight sentences with no filler; the example referenceImageUrl anchors the output without bloating the text.

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

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

No output schema exists, and the description explicitly explains the return (a stable hosted URL usable as a reference image), plus cost and size constraints. The only material gap is the undocumented filename parameter, but overall the definition is sufficient to 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 50%: url is documented and filename is not. The description reiterates that the URL must be public http(s) image/video (matching the schema), but says nothing about the filename parameter or how it affects the stored asset, leaving half the parameters undocumented in both description and 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+resource: fetch a public image/video URL and store it on VidGuy, returning a hosted URL. It also distinguishes itself from the upload siblings by scoping to URLs the asset isn't already hosted at, so an agent can tell it apart from create_upload/ai_edit_upload/swap_upload.

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 this when you have a URL but the asset isn't already hosted with us" gives a clear selection condition. It doesn't name the specific alternative tool to use when the asset IS already hosted, but the when-to-use 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results are paginated, which is useful un-annotated behavior, but says nothing about result volume, ordering, or failure modes.

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 resource definition, followed by pagination and workflow ordering. Every sentence earns its place with 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 an output schema present, return values need no explanation, and the description covers purpose, pagination, and the recommended call ordering. The only real gap is the undocumented pagination parameters, which is minor for such a simple list tool.

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

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

Schema coverage is 0% and neither limit nor offset is explained in the description. The single word 'Paginated' hints that the two integer parameters control paging, but their semantics, defaults, and the 200 max are left entirely to inference.

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 (list), resource (brands), scope (registered under your account), and even disambiguates the term by equating it with 'end-customers'. An agent can distinguish this from get_brand, create_brand, and delete_brand immediately.

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

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

Gives explicit forward-looking guidance: 'Call this first to find a brandId before generating snacks', tying it to the downstream generation workflow. It lacks any when-not guidance or named alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds beyond that by disclosing the return content shape (row schema, variable keys, text vs image, an example per key) and the cost ('FREE'). It omits pagination/rate-limit behavior, keeping it short of a 5.

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

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

Three tight sentences: purpose, contents, then the usage instruction and cost flag. Every sentence earns its place and the routing advice 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?

There is no output schema, so the description correctly steps in to describe what is returned. Combined with the annotations covering safety, an agent has everything needed to call this tool and use its output.

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

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

The tool takes zero parameters (empty schema), so the baseline is 4 and there is nothing for the description to disambiguate. No parameter confusion is possible.

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 (List) and resource (carousel layouts on this account), and clarifies what each listed item contains (variable keys, text vs image, example per key). The counterpart sibling create_tiktok_carousel is named directly, so an agent can place this tool without opening any schema.

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

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

Explicitly instructs 'Call this before create_tiktok_carousel — the row keys come from here, never from guesswork', giving both the trigger condition and the reason. It also flags the cost profile ('FREE'), which further routes usage decisions. Nothing is left to inference.

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

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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description adds that entries include tags and thumbnails and how the id is consumed downstream, but says nothing about pagination, result size, or return format beyond the field hints.

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

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

Two tight sentences with the core purpose and the actionable next step front-loaded. 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?

For a no-param list tool with annotations covering safety and no output schema, the description provides what's needed: what the library is, when to reach for it, and how to use results. Minor gap: no naming of the seam versus other list_* character 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?

Zero parameters, so the baseline is 4. There is nothing to document and the description appropriately offers no parameter guidance.

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

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

States a specific verb and resource (list VidGuy's preset character/actor library) and adds differentiating detail: it's a preset library with tags and thumbnails for UGC video. However, it doesn't explicitly distinguish itself from siblings like list_characters or list_seedance_library, so an agent must infer the boundary.

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 a clear condition for use: 'when you don't have your own character,' and instructs how to use a result ('Use a library entry's id as the UGC character'). It doesn't name alternative tools (e.g., list_characters) or state when NOT to use it, but the context is strong.

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

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

Annotations already declare the safe read-only, non-destructive, non-open-world profile, so the description adds genuine value by disclosing return behavior: each item carries an id usable as the UGC character and thumbnails are attached. This return-format detail is exactly the kind of context annotations don't cover, though it stops short of mentioning ordering, limits, or empty-state 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?

Three short sentences, fully front-loaded with the purpose before the output/usage hints, with no redundant or filler content. 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?

With no output schema present, the description must carry return-value information, and it does so by noting the id and attached thumbnails. Combined with annotations covering the safety profile, this is nearly complete for a simple list tool, missing only minor details like ordering or result count.

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 baseline is 4. The description appropriately spends no words on parameter syntax and instead focuses on outputs, which is the correct choice for a no-arg list tool.

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 (List) and resource (saved characters/actors) with a clear domain qualifier ('for UGC video'), so the agent knows exactly what is being returned. It implicitly distinguishes itself from lookalike siblings like list_character_library and list_seedance_actors via 'your saved characters,' but never names them explicitly, keeping it short of a 5.

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

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

Usage is implied rather than stated: 'Each has an id to pass as the UGC character' tells the agent what the output is for, which suggests this is the pre-step before a UGC generation call. However, there is no explicit when-to-use, when-not-to-use, or named alternative versus list_character_library/list_seedance_actors, so it remains at the minimum-viable level.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered (the phrase 'Read-only' is somewhat redundant). The description does add real behavioral value by disclosing the return surface, notably 'tasks that currently need owner attention,' which tells the agent this call surfaces actionable state, not just a roster.

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, front-loaded with the purpose, then return contents, then the sibling routing. Efficient overall, though the standalone 'Read-only.' sentence duplicates the readOnlyHint annotation and could be folded in or dropped.

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

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

No parameters and no output schema, so the description must carry the return-value burden itself — and it does, enumerating the per-agent fields plus the attention-required tasks. An agent has enough to call this and know what it gets back.

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 takes zero parameters, so the baseline for this dimension is 4. There is no parameter semantics for the description to add or omit, and the empty schema is consistent with the described behavior.

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

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

States a specific verb and resource ('List the authenticated user's deployed Companion teammates') and immediately enumerates what each entry carries (id, role, status, configuration, stats, latest task). This is clearly distinguishable from the sibling get_content_agent, which fetches a single agent.

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 routes to the alternative: 'Use get_content_agent with a returned id when the user asks about one agent's work, runtime, history, messages, knowledge, clips, or signals.' The condition that selects the sibling is spelled out, and the plural listing scope is implied for the overview case.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful output context ('Thumbnails are attached') but does not disclose pagination behavior for limit/offset, so it adds only modest value beyond the structured fields.

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

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

Two tight sentences, front-loaded with the action and resource, with parenthetical asset types and a note on thumbnails. No wasted wording.

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

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

For a read-only listing tool with annotations carrying the safety profile and no output schema, the description covers scope, asset types, and the thumbnail return detail. The only gap is implicit pagination via undocumented limit/offset, which is minor for a straightforward list operation.

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

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

Schema coverage is 50%: influencerId and role are documented in the schema (role with example values like static_ugc, carousel_slide, character_sheet), while limit and offset are not. The description only restates the optional role filter and adds no syntax or pagination semantics, so it does not compensate for the coverage gap.

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

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

States a specific verb (List) and resource (generated assets in an influencer's vault), and enumerates the asset kinds (portraits, stills, b-roll, video clips), which lets an agent distinguish it from siblings like list_influencer_studio_images. It does not explicitly name which sibling to prefer, keeping it just short of a 5.

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

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

The only usage guidance is 'Optionally filter by role,' which implies the role parameter is optional but gives no when-to-use/when-not framing or alternatives against the many sibling list_* tools. Usage 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 declare readOnlyHint and non-destructive, so the safety profile is covered. The description adds valuable domain-specific behavior: oldest-first ordering, limit of last 100, the meaning of 'unread' status for both owner messages and unanswered agent questions, and that owner messages are consumed on next wake. This is rich context beyond annotations, though it doesn't detail pagination or return 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?

Three dense sentences that front-load the core definition. It is appropriately sized for the domain complexity, though some allocation of detail could be slightly tighter.

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 a single parameter, readOnly annotations, and no output schema, the description covers the essential semantics of the inbox and its lifecycle. It omits some minor details like pagination or error cases, but is largely complete for safe invocation.

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

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

Schema coverage is 0% for the single parameter influencerId, but the parameter name is self-explanatory and its type/format is defined in the schema. The description doesn't add syntax or meaning beyond what the name implies. With one parameter and no output schema, baseline 3 is appropriate.

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

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

States a specific verb and resource ('the two-way owner ↔ agent inbox for one influencer') with precise scope. It is clearly distinguishable from sibling send_influencer_message and other influencer tools by naming the inbox context.

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

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

Explains the purpose of reading the inbox and routes the agent to the alternative for a related action ('answer them via send_influencer_message with answerToMessageId'). However, it doesn't explicitly state when-not to use this tool vs other read tools, so it's not a full 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context by enumerating returned fields (id, name, status, coverUrl) and the status values, which helps interpretation. It does not cover pagination behavior despite limit/offset params.

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

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

Three tight sentences, front-loaded with the core purpose, followed by sibling disambiguation, return shape, and downstream usage. 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?

No output schema, so the description reasonably enumerates returned fields and status values, and routes the agent to consumer tools. It omits pagination guidance for the limit/offset parameters, which is the main remaining gap for a list tool.

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

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

Schema description coverage is only 33% — limit and offset are bare integers with no description, and brandId is documented in the schema. The description does not explain pagination semantics or the brandId filter, leaving the limit/offset parameters undocumented in both places.

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 ('List your saved AI influencers') and explicitly distinguishes from the closest sibling, list_characters, by characterizing the influencer as a persistent identity owning a persona, voice, and asset vault. An agent can differentiate without opening 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?

Provides a clear distinction from list_characters and points to downstream tools (get_influencer, build_influencer_vault, list_influencer_assets) that consume the returned id. However, it does not state when NOT to use this tool or give alternative listing tools (e.g., list_influencer_assets for a different resource type).

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

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

Annotations already declare readOnly, non-destructive, closed-world. The description adds that entries include a 'validated, media-normalized manifest', which is useful behavioral context about return content. It doesn't discuss pagination behavior or rate limits, so it meets the lower bar 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, front-loaded with the core action, then a detail about output content, then a routing hint. 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 read-only list tool with annotations and no output schema, the description covers purpose, output content nature, and routing to get_snack. It doesn't explain pagination defaults or maximum limits, but the schema provides numeric bounds. Mostly complete given the simplicity.

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%: influencerId has a description ('Influencer id from list_influencers'), but limit and offset have no descriptions in schema. The description doesn't compensate by explaining limit/offset semantics. Baseline 3 since the required parameter is documented, but the optional ones are not.

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

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

States a specific verb (List) and resource (snack content packs for one influencer), and names the dashboard location ('Content' tab) for disambiguation. It clearly differs from list_snacks (all snacks) and get_snack (single detail).

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

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

Explicitly tells the agent to use get_snack for full detail on any returned id, which is a clear alternative. It doesn't state when NOT to use this tool (e.g., for other influencers or bulk listing without influencer filter), 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?

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the description earns credit for adding real context: newest-first ordering, a ≤60 result cap, the fields per item, and that thumbnails arrive as resource links. It does not explain how (or whether) older items beyond 60 can be retrieved.

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 front-loaded sentence that packs scope, ordering, limit, return fields, and the resource-link behavior with no filler.

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

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

With no output schema present, the description carries the return-value burden and does it well (url, prompt, saved flag, thumbnail resource links) while disclosing the ordering and result cap. The only gap is any guidance on retrieving generations beyond the 60-item window.

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?

Only one parameter (influencerId) with 0% schema description coverage, so the description must compensate but only does so indirectly via 'This influencer's'. It never says the id must be a UUID from list_influencers or otherwise clarifies the identifier's origin.

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

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

States a specific resource and scope: 'This influencer's past studio generations', with ordering and a hard cap. It clearly reads as a read/list operation distinct from generate_influencer_studio_image and delete_influencer_studio_image, though it never names a sibling explicitly to route the agent.

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

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

Usage is only implied by the phrase 'past studio generations' — an agent can infer it is the retrieval counterpart to generation, but there is no explicit when-to-use, no comparison to list_influencer_assets or get_influencer_vault_build, and no statement of prerequisites.

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

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

Annotations already mark this as a read-only, non-destructive, non-open-world tool. The description adds substantial behavioral context beyond that: lifecycle status semantics, the postable/active posting rule, warming fields, cached analytics with refresh cadence, posting constraints, and that the tool is free.

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 what the tool lists, then adds necessary return-shape detail because no output schema exists. Every sentence contributes useful information, and the single dense paragraph remains 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?

With no output schema and only read-only annotations, the description carries the load well: it explains account lifecycle, postability, warming progress, cached analytics, posting metadata, and cost. An agent has enough context to call and interpret the tool correctly.

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

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

There are zero input parameters, so the description appropriately adds no parameter semantics. Baseline for a no-parameter tool is 4; the detail instead explains return fields, not call parameters.

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

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

States a specific verb and resource: list managed accounts, and clarifies these are accounts VidGuy operates on the user's behalf. It does not explicitly distinguish itself from close siblings like get_managed_account or get_managed_accounts_pulse, so it is clear but not fully sibling-differentiating.

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

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

The description implies usage by explaining that only accounts with postable=true can receive posts, which helps an agent decide when the list matters. However, it gives no explicit when-to-use guidance or alternatives such as get_managed_account or get_managed_accounts_pulse, so usage is only implied.

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