MockClip

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

With annotations only declaring readOnly/destructive/idempotent/openWorld, the description adds real behavioral context: free-plan exports carry a MockClip watermark, the free plan allows 2 MCP renders, watermark-free/commercial use needs the Studio plan, and the caller is told to mention /pricing. That is meaningful disclosure beyond annotations, though it stops short of export timing or failure 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?

Purpose is front-loaded, followed by brand-parameter semantics and then plan caveats, all in a compact paragraph. The upgrade-message sentence is somewhat sales-oriented but is actionable for the agent, so little is wasted.

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

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

For an 18-param tool with a nested messages object and no output schema, the description establishes purpose, branding semantics and plan limits, but leaves selection guidance and roughly half the params unaddressed. The structured schema carries the rest, so it is adequate but not complete.

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

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

Schema coverage is only 44%, so the description must compensate, and it does define the two most identity-critical params: brandName (assistant name in header and composer) and accentColor (logo, bubbles, send button). However, many params (keyboard, showWelcome, soundSettings, showQuickActions, keepWelcomeVisible, etc.) remain unexplained here.

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 ('Create an AI assistant chat animation') and scopes it with 'under your own product name', which separates it from the branded siblings like create_chatgpt_conversation. It doesn't explicitly name those siblings, but the brand-free differentiator is clear enough to route correctly.

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

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

There is no when-to-use guidance or contrast against the many sibling conversation tools (create_chatgpt_conversation, create_brand_free_text_chat, etc.). The only conditional advice is about plan tiers and the upgrade message, which is billing guidance rather than tool-selection guidance.

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

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

Annotations only establish the generic mutation profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds real behavioral context beyond that: free-plan exports carry a MockClip watermark, free plan includes 2 MCP renders, and watermark-free commercial use requires the Studio plan. It doesn't cover render time, async behavior, or failure modes, but the plan/watermark disclosure 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?

Front-loaded with the core purpose in the first clause, followed by parameter mapping and the plan note in a single dense paragraph. Every sentence carries information, though the free-plan/upgrade instruction slightly crowds the purpose statement.

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 17-parameter tool with nested objects and no output schema, the description gives a workable overview of purpose, a few parameters, and plan behavior, but says nothing about the required profiles array shape, sequencing, or render output. Adequate but leaves clear gaps for a complex 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 47%, so several parameters (sceneId, videoFormat, exportFormat, exportQuality, textScale, showBezel, showStatusBar, showHomeIndicator) are documented in the schema itself. The description only clarifies brandName, accentColor, and the chat/continuation behavior, adding marginal value over the schema and leaving half the parameters to the schema.

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

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

States a specific verb and resource: create a dating-app swipe animation in an original brand-free app, with the key visual elements (wordmark via brandName, accent color, left/right swipes, mutual-match screen). Clear on its own, but it never names the obvious sibling (create_tinder_animation) or explains why an agent would pick the brand-free variant over it.

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

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

There is no when-to-use guidance and no alternatives named among the many sibling conversation/animation tools. The only conditional instruction is about the free plan and the upgrade prompt, which is conversational guidance rather than tool-selection guidance.

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

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

Annotations already declare a non-read-only, non-destructive, non-open-world write with no idempotency, so the safety profile is covered. The description adds real behavioral context the annotations cannot: free-plan exports carry a MockClip watermark, the free plan allows 2 MCP renders, and the caller should surface the /pricing upgrade path. It does not describe what the call returns or whether rendering is synchronous, which keeps it below 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?

The core capability and the two most consequential defaults (stackNotifications, background) are front-loaded in the first sentence, and the plan/watermark caveat comes last where it belongs. It is dense and slightly run-on, but every clause carries information an agent needs.

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 17-parameter, nested-object, no-output-schema tool, the description covers the headline behavior and plan caveats but leaves the agent without key operational facts: what the tool returns (a file, a job id, a URL?), how long a render takes, and detail on roughly half the parameters. Adequate to invoke, not adequate to invoke confidently.

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 47% across 17 parameters, so the description has to compensate. It does add meaning where the schema is silent: stackNotifications defaults to true and stacks up to 4 banners newest-on-top, false plays them one at a time, and background defaults to the lock screen. But large parts (theme, brandName length, accentColor format, lockScreen and background sub-objects, notifications item fields like delayBefore/displayDuration, soundSettings) get nothing extra beyond the schema, so it does not fully bridge the gap.

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

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

The description states a specific verb and resource: 'Create a lock-screen notification animation from an original, brand-free app', and the stacking/banner behavior is described in enough detail to picture the output. It does distinguish itself from sibling notification tools implicitly through 'brand-free app' and 'lock screen', but it never names a sibling such as create_imessage_notification or create_phone_call_notification, so the differentiation is left to inference.

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

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

Usage context is implied rather than stated: the tool produces a lock-screen mockup, so an agent can infer it fits a 'show phone notifications' scenario. There is no explicit guidance about when to choose this over the other notification siblings, nor about prerequisites beyond the free/paid plan note. The plan note (free plan = watermark + 2 MCP renders, mention /pricing) is useful but is post-call guidance, not tool-selection guidance.

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

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

Adds real behavioral context beyond the annotations: free-plan exports carry a MockClip watermark, the free plan caps MCP renders at 2, and transparent/60fps exports require Creator or Studio plans. This kind of plan gating and quota disclosure is exactly what annotations cannot express. It does not describe the render output or wait/async 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?

Purpose is correctly front-loaded in the first clause, but the paragraph then crams feature bullets and a long, prescriptive upsell instruction into one run-on block. The pricing sentence is agent-facing marketing copy that dilutes the technical description.

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 19-parameter generator with nested message objects and no output schema, the description covers plan limits and two cosmetic params but says nothing about the messages array, item caps, or typical render behavior. "All options controllable" is a vague stand-in for real coverage.

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

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

Schema coverage is only 42% across 19 params, so the description must compensate. It clarifies brandName (unused on screen) and accentColor (bubble colour), which fills gaps the schema leaves blank, but the remaining 17 parameters — including the nested messages structure — get no description-level help.

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: "Create a chat conversation animation in an original, brand-free messaging app." The "brand-free" qualifier differentiates it from branded siblings like create_imessage_conversation or create_discord_conversation, though it never names the alternative directly.

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: brand-free, original messaging app. It never says when to pick this over create_imessage_conversation or other chat siblings. The only explicit routing guidance is about the free-plan upsell prompt, not tool selection.

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

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

Annotations only declare the generic non-read-only, non-destructive, non-idempotent profile, so the description carries most of the burden. It usefully discloses free-plan watermarks and the 2-render MCP quota plus an upgrade path, which is real behavioral context; however it says nothing about what the tool actually returns (a render URL/file) or how long an export takes.

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?

Short and front-loaded: the core purpose and the keyboard semantics come first, with the plan/watermark caveat last. The upgrade-mention instruction is somewhat promotional, but it is actionable for the caller and does not bury the definition.

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 a 19-parameter nested schema, the description leaves the return value and render lifecycle unexplained, and most parameters unaddressed. It does cover the plan-limit behavior that an agent most needs to relay to the user, which keeps it above a minimal score.

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 42% across 19 parameters, so the description should compensate more than it does — it explains only `keyboard` (auto/always/never semantics and default), adding genuine value over the bare enum. The remaining undocumented parameters (incognito, showWelcome, welcomeText, soundSettings, showQuickActions, keepWelcomeVisible, messages sub-fields) get no help from the description.

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

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

States a specific verb and resource ("Create a ChatGPT conversation animation") that clearly separates it from the 20 sibling create_*_conversation tools (Gemini, iMessage, WhatsApp, etc.). An agent can pick this tool for ChatGPT-style output 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?

The description documents the keyboard option's semantics but never says when to choose this tool over the many sibling conversation tools or what inputs are required. The only routing-like content is the plan/upgrade note, which is about billing, not tool selection.

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

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

Annotations only say non-read-only, non-destructive, non-idempotent; the description adds substantive context beyond that: a MockClip watermark on free-plan exports, a 2-render MCP cap, and an explicit instruction to surface the /pricing upgrade. It stops short of describing render time or what the reply delivers.

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 before optional flow/scene details, and most sentences earn their place given a 22-param video tool. The prose is dense and the trailing free-plan marketing sentence is somewhat appended, but overall well-organized.

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

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

For a complex, nested, no-output-schema render tool the description covers the important behavioral defaults (showTaps true, first date line, header suppression on runs) well. It is slightly thin on the final deliverable (no mention of what the reply returns), but otherwise complete enough to call correctly.

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

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

Schema coverage is only 36% across 22 params, so the description carries a heavy burden. It compensates for the highest-value ones — flow, chats/server, showTaps, dateLabel/firstDateLine, call, showHeader, myName/myAvatarUrl — but leaves many (soundSettings, unreadCount, delayBefore, typingSpeed/Duration, timestamp, contactStatus) to the schema alone.

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+resource — 'Create a Discord conversation animation' — and immediately enumerates what it renders (author names/times, call log cards, date separators, typing line), which cleanly distinguishes it from the many platform siblings like create_slack_conversation or create_imessage_conversation.

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

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

Gives conditional guidance for the optional flow parameter ('without them the clip shows the conversation only') and explains plan-gated behavior with an upgrade path. However, it never explicitly states when to pick this Discord tool versus the other conversation siblings or when-not to use it; context is clear but exclusions are absent.

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

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

Annotations only declare it as a non-read-only, non-destructive create with no idempotency, so the description carries real weight by disclosing free-plan gating (watermark, 2 renders) and instructing the agent to surface the /pricing upgrade path. It also states defaults like showTaps=true, adding behavior beyond the annotations.

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

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

Nearly all content is compressed into one sprawling paragraph that mixes required behavior, optional features, and plan messaging. Each clause carries distinct information, so little is pure waste, but the lack of bullets or front-loaded grouping makes it harder to scan than it needs to be.

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

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

For a 32-parameter nested renderer with no output schema, the description covers the highest-complexity surfaces (flow, group, keyboard, story, date line) and the plan caveat. It stops short of documenting many secondary screen objects, but is largely 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?

With only 25% schema description coverage across 32 params, the description compensates well by explaining flow steps and transitions, group.members semantics (2-12, contactName as group name, author naming, at-least-three-authors rule), keyboard modes, firstDateLine fallback chain, and story params. Many nested objects (people, discover, settings, profile, newMessage) remain undocumented, so it is not fully exhaustive.

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+resource ('Create a Messenger conversation animation') and immediately names distinguishing capabilities (photo grids, read marks, typing bubble). The Messenger product name separates it cleanly from the many chat-app siblings such as create_imessage_conversation, create_whatsapp_conversation and create_telegram_conversation.

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

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

The bulk of the text explains how to configure the tool rather than when to choose it. Usage is implied by the product-specific name and by the statement that omitting flow/chatList yields the conversation-only clip, but there is no explicit when-to-use, prerequisite, or alternative-tool 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 only give the generic safety profile (not destructive, not idempotent, not open-world), so the description carries real weight here. It discloses plan-gated behaviour beyond the schema: free-plan exports carry a MockClip watermark and the free plan includes only 2 MCP renders. It does not describe runtime/latency expectations, but coverage of limits and upsell conditions is well above average.

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

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

The core purpose is front-loaded, but the body is a single ~270-word paragraph with three levels of nested parentheses and colons, which makes it hard to scan. Most sentences carry real information, so it is dense rather than padded, but the structure is clearly suboptimal for a 21-parameter 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 complex tool with 21 parameters, nested objects, 6 enums, no output schema and thin annotations, the description covers the required 'messages' surface thoroughly plus flow, screens, keyboard, taps and plan limits. It never explains the export pipeline or return value (no output schema), but it does disclose that some features silently downgrade on lower plans, which is the key completeness detail an agent needs.

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 38% across 21 parameters, so the description must compensate, and it does: it explains messages semantics (typed, thinkingDuration, thinkingLabel, streamingSpeed default 100, error, showActions), title/placeholder/sourceLabel/disclaimer, keyboard modes, flow transitions, showTaps default, and the home/drawer screen params. Bullet-point line handling is extra value the schema does not carry. Uncovered optional params (theme, soundSettings, delayBefore, typingSpeed) keep it from a 5.

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

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

States a specific verb and resource — 'Create a Gemini conversation animation' — and immediately enumerates the observable behaviours it produces (replies revealed top-to-bottom, thinking animation, keyboard typing). The Gemini branding plus the animation framing cleanly separates it from sibling conversation tools like create_chatgpt_conversation and create_imessage_conversation.

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

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

Usage is implied by the app-specific name and description (this is the Gemini-flavoured chat render), but the definition never states when to pick this over a sibling such as create_chatgpt_conversation. The only explicit caller instruction is a plan/upsell nudge ('mention that they can upgrade at /pricing'), which is a sales hint rather than selection guidance.

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

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

Annotations already declare a non-readonly, non-destructive, non-idempotent create op, so the safety profile is covered. The description adds real behavioral context beyond that: free-plan exports carry a MockClip watermark, the free plan allows only 2 MCP renders, and the caller should surface the upgrade path. It does not describe latency or the returned artifact, 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?

A single dense run-on paragraph with no headings or bullets, which is hard to scan for the 17-param structure. It is front-loaded with purpose, but tangents like "All options controllable" add no value and could be cut.

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 17-param nested creation tool with no output schema, most visual and script semantics are covered, but the description never says what the tool returns (render/URL/asset) nor does it hint at the enum-heavy export/format options handled only by the schema. Adequate but leaves an agent guessing about the result 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?

With schema coverage at only 47% across 17 params, the description compensates well: it maps `emails` row fields (senderName/monogram/avatarColor/senderAvatarUrl/time/subject/preview/unread/starred/important), `body`/`to`/`label`, `incoming`, all `script` step types, `myName`/`myAvatarUrl`, `keyboard` and `showTaps`, and supplies defaults (to="to me", label="Inbox", typingSpeed=16, showTaps=true, auto ids m1/n1). The remaining rendered-layout params rely on 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 opens with a specific verb+resource ("Create a Gmail inbox animation") and then enumerates the exact visual contents (emails sliding in, bold unread, replies, keyboard). This is unmistakably distinct from every sibling (iMessage/Discord/Slack conversation, notifications), so an agent can select 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?

It gives implied context (this builds an inbox animation, `script` plays steps in order) but never states when to pick this over a sibling app tool or any exclusions. The only directive is a plan-policy note about mentioning the /pricing upgrade, which is not tool-selection guidance.

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

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

Annotations already declare the write/non-idempotent/non-destructive profile, so the bar is lower. The description goes beyond structured fields by disclosing the free-plan watermark on exports, the 2-render free limit, and an upgrade path, plus the keyboard default — real behavioral context an agent would not otherwise have.

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

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

The purpose is front-loaded in one sentence, which is good. However, 'All options controllable' is filler that earns no place, and the free-plan/upgrade sentence is long and reads as sales copy rather than functional guidance.

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 17-parameter tool with nested objects and no output schema, the description is complete enough on purpose and plan constraints but thin on the mechanics of the `messages` array and most tunable parameters. An agent can create a basic render but must rely on the schema alone for the rest.

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 47%, so the description needs to compensate, yet it only clarifies one parameter (`keyboard` values and its 'auto' default). Many nested message fields (tapbacks, readTime, showRead, cancelTyping, etc.) are undocumented in both schema and description, and 'All options controllable' adds nothing.

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

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

The description opens with a specific verb and resource ('Create an iMessage conversation animation'), which is clearly distinguishable from the WhatsApp/Telegram/Slack siblings by name. It stops short of explicitly contrasting with those siblings, but the resource is unambiguous.

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

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

There is no guidance on when to choose this tool over the many sibling 'create_*_conversation' tools, no prerequisites, and no exclusions. 'All options controllable' is not actionable guidance. The only context given is billing-related, not selection-related.

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 non-readOnly, non-destructive, non-idempotent, closed-world, so the safety profile is covered. The description adds genuinely non-structured context: free-plan exports carry a MockClip watermark, the free plan allows 2 MCP renders, and the caller should point users to /pricing — plus the 4-banner stacking cap and eviction 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?

Purpose is front-loaded in the first sentence, followed by the stacking behavior and then the plan constraints. The plan/pricing sentences are long and semi-promotional but do encode an instruction the agent must act on (mention upgrade), so they earn their 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 15-parameter, deeply nested render tool with no output schema, the description covers the two things an agent would most likely get wrong (stacking toggle, plan limits) but leaves most of the parameter surface and the required notification item shape undocumented. Adequate, not complete.

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

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

Schema description coverage is only 53% across 15 parameters with nested objects, so the description is expected to compensate and largely does not. It explains only stackNotifications; the required notifications array items (sender, message, delayBefore, dismissStyle, displayDuration), theme, background, lockScreen and soundSettings get no meaning from the description beyond their names.

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

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

States a specific verb and resource — 'Create an iMessage notification (banner) animation' — and the following sentences clarify it is an animated banner render, which separates it from create_imessage_conversation or create_phone_call_notification. It does not explicitly name those siblings as alternatives.

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

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

Gives an explicit behavioral choice for one parameter: banners come one at a time unless stackNotifications is true, in which case up to 4 pile up and a 5th evicts the oldest. However there is no guidance on when to pick this tool over the sibling notification/conversation tools, so routing must be 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 cover the safety profile (non-readonly, non-destructive, closed-world), and the description adds genuinely useful behavior beyond them: free-plan exports carry a MockClip watermark, the free plan allows only 2 MCP renders, and there is an upgrade path at /pricing. It stops short of describing the rendered output or timing/animation semantics, so it is not 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?

Purpose is correctly front-loaded and the keyboard note is compact, but the billing sentence is long and tangential relative to the tool's core function, and 'All options controllable' is empty filler that earns no 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 complex tool (15 params, nested message objects, 6 enums) with no output schema and mid-level schema coverage, the description is thin. It never says what is returned (a rendered video/export), how the animation is produced, or how the message array maps to a timeline, leaving major gaps an agent must guess at.

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 53% across 15 parameters with nested objects, so the description should compensate but does not. It explains only `keyboard` (adding the useful default of 'auto'), restates enum values already in the schema, and covers none of the other 14 parameters, including the required `contactName` and `messages`.

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 ('Create an Instagram DM animation') and, via the platform name, distinguishes this from the 20 chat/feed siblings like create_whatsapp_conversation and create_discord_conversation. An agent can identify the platform and artifact type 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?

There is no guidance on when to choose this tool over the many sibling conversation creators, no prerequisites, and no exclusions. The only conditional advice is billing-related ('if the caller is on the free plan, mention upgrade'), which does not help tool selection.

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

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

Beyond the annotations, the description discloses important behavioral traits: free-plan watermarking, the 2-render MCP limit, upgrade messaging, export-format plan constraints, and how sceneId overrides other display options. This adds substantial operational context for a non-read-only creation 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 front-loaded with the core purpose and then layers in optional behavior, which suits the tool's complexity. It is dense as a single paragraph and includes a vague line like 'All options controllable,' but most sentences carry useful information.

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

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

For a complex 22-parameter creation tool with no output schema, the description covers the main animation modes, message types, flow behavior, defaults, and plan constraints. It is nearly complete for invocation, though a few optional display and contact-related parameters remain only in 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?

With only 36% schema description coverage, the description compensates well for core parameters: it explains flow/screen transitions, showTaps, message call/system/dateLine/showHeader semantics, and myName/myAvatarUrl. However, several optional parameters such as theme, soundSettings, contactStatus, contactAvatarUrl, and inbox row details receive no description-level clarification.

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

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

The description opens with a specific verb and resource: 'Create a LinkedIn conversation animation.' It names LinkedIn explicitly and describes distinctive features such as video meeting cards, system lines, and screen flows, which clearly differentiate it from the many sibling conversation generators for other platforms.

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

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

It explains when the optional screen-flow mode applies and what happens without it: 'without them the clip shows the conversation only.' It also states defaults like showTaps=true and firstDateLine behavior, giving clear invocation context, though it does not explicitly route the agent against sibling platform 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 state this is a non-read-only, non-idempotent, non-destructive generator. On top of that the description adds genuinely useful behavior: free-plan exports carry a MockClip watermark and the free plan is limited to 2 MCP renders. However, it says nothing about generation latency, output delivery, or how partial-option combinations (e.g. transparent export requiring a paid plan) affect results — details that live only in 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?

Good front-loading of the core action, but 'All options controllable' is a wasted sentence and the third sentence is a long marketing/upgrade instruction aimed at the end user rather than at an agent selecting the tool. It occupies roughly half the description without helping correct invocation.

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

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

For a rich generation tool with 18 parameters, a nested object, no output schema and 44% schema coverage, the description is far too thin. It covers plan limits but omits parameter meaning, output characteristics, and prerequisites such as paid-plan requirements for transparent or 60fps exports.

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 18 parameters and only 44% schema description coverage, the description should carry real weight, but 'All options controllable' is filler and no parameter is mentioned. Parameters like callerName, outcome, delayBefore, ringDuration, endedDuration and soundSettings are explained in neither the description nor 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 first sentence gives a specific verb and resource: 'Create a full-screen phone call animation.' That clearly separates it from the text-chat and notification siblings, though it never explicitly distinguishes itself from create_phone_call_notification, which is the closest neighbor and could be confused with it.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. The only routing-like content is a plan/upgrade policy for watermarks and renders, which is billing messaging rather than tool-selection guidance.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent render operation. The description adds useful free-plan behavior: watermarking, a 2-render MCP limit, and an upgrade path, but it omits other behavioral details such as export timing, plan restrictions on certain formats, and whether rendering is synchronous.

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

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

The purpose is front-loaded in the first sentence, and the free-plan caveat follows efficiently. The final sentence is longer because it includes caller-facing upgrade messaging, but it remains relevant and does not bury the core purpose.

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

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

For a complex 20-parameter animation generator with nested objects and no output schema, the description is thin. It does not explain the returned artifact, rendering behavior, or parameter effects, leaving most completeness burden on the partially documented input schema.

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

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

The description only says 'All options controllable' and provides no explanation of the 20 parameters, including the two required ones. With schema description coverage at 40%, the description does not compensate for undocumented parameters.

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

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

The description states a specific verb and resource: create a phone call notification (banner) animation. It is clear what the tool produces, but it does not explicitly distinguish this banner animation from the sibling create_phone_call tool.

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

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

There is no guidance on when to use this tool versus alternatives such as create_phone_call or create_imessage_notification. The only usage-related instruction is about free-plan watermark messaging and upgrade prompts.

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

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

With annotations covering the safety profile (not read-only, non-destructive, non-idempotent, closed-world), the description adds genuine behavioral context: free-plan exports carry a MockClip watermark, the free plan caps at 2 MCP renders, and the caller should surface the /pricing upgrade path. These are real operational traits beyond the structured fields, though export timing/async behavior remains unexplained.

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

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

The purpose is front-loaded in the first sentence and the sentences are compact. The final pricing sentence is long but functions as an actionable instruction to the agent rather than padding, so waste is limited.

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

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

For a 12-parameter tool with nested objects and no output schema, the description covers cost/watermark constraints but omits what the tool returns (export URL? job handle?), whether rendering is synchronous or long-running, and any per-call limits beyond the free-tier render count. Adequate but with clear gaps for a tool this complex.

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 67%, with the enumerated parameters (sceneId, videoFormat, exportFormat, exportQuality, textScale) already well documented in the schema. The description only adds 'nested comments supported', which marginally clarifies the comments array's recursive nature that the schema exposes via a self-referencing $ref.

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

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

The description states a specific verb+resource ('Create a Reddit thread animation'), which cleanly distinguishes it from the many sibling conversation/feed tools. However, 'All options controllable' is vague filler that adds no discriminating information beyond the title.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions beyond the free-plan pricing nudge. The intended use (render a Reddit thread as video) is only implied by the tool name and title.

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

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses substantive behavior: per-banner timing defaults, one-at-a-time vs stacked playback with a 4-on-screen cap and 5th-evicts-oldest rule, background type semantics, and the free-plan watermark plus the 2-render MCP limit. That is exactly the extra context annotations cannot carry.

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

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

The core concept is front-loaded, but the remainder is one dense run-on paragraph mixing banner timing, stacking, background modes and plan/watermark policy. Every sentence carries information, yet the lack of structure (no separation of options vs billing caveats) makes it harder to scan than it needs to be.

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

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

For a 15-parameter nested tool with no output schema, the description covers the required array plus the most consequential options and the plan gating that affects exports. Minor gaps (theme, soundSettings, showHomeIndicator, textScale) are partly covered by schema descriptions and are low-risk defaults, so the definition is nearly complete.

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

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

With 53% schema coverage, the description compensates well: it explains the notifications array fields (title bold, time default "now", 4-line body wrap, delayBefore 0.5, displayDuration 4, dismissStyle), stackNotifications behavior, and the background.backgroundType branches including chromaStyle and backgroundImageUrl. These add meaning well beyond the bare schema, even though theme and soundSettings are not covered.

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

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

The description opens with a specific verb+resource ("Create a Shopify notification animation") and immediately explains the core payload, so the agent knows this produces a branded notification-banner video. It does not explicitly contrast itself with the near-identical sibling create_brand_free_notifications, relying on the Shopify branding to differentiate.

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 through the detailed option walkthrough (single vs stacked banners, background types), and there is a plan-related instruction (mention upgrade at /pricing on free plan). But there is no explicit "use this when / instead of X" guidance against the many sibling notification/chat tools, so selection still requires inference.

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

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

Annotations only declare the generic mutation profile (readOnly=false, destructive=false, idempotent=false, openWorld=false); the description adds genuinely non-structured behavior: free-plan MockClip watermark, a 2-render free quota, and an instruction to surface the /pricing upgrade path to free-plan callers. That is meaningful operational context the annotations cannot carry. It still omits whether the render is synchronous/asynchronous and what is actually returned, so it is not 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?

Extremely dense: a single 90+ word first sentence with nested parentheticals, followed by three more long compound sentences. The most actionable instruction for the agent (the free-plan upgrade mention) is buried in the final sentence rather than front-loaded, and the enumeration of chat chrome details could be trimmed. It is information-rich but poorly structured for scanning.

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 22-parameter tool with nested objects and no output schema, the description covers the creative behavior and plan constraints well, but it never explains how the result is delivered (asset URL, job id, async polling) — a real gap when no output schema exists — and leaves roughly two-thirds of parameters undocumented. Adequate but with clear omissions.

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 36% schema description coverage across 22 parameters, the description must compensate, and it does explain several undocumented ones: flow screen steps and transitions, showTaps, firstDateLine/dateLabel rendering rules, showHeader, myName/myAvatarUrl, and the threads/thread screen objects. But it says nothing about intro, theme, soundSettings, contactName/contactStatus, delayBefore, typingSpeed/typingDuration, or reactions structure, leaving large holes. It adds value but does not close 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?

Opens with a concrete verb+resource ('Create a Slack conversation animation') and immediately enumerates the visual artifacts produced (headers, avatars, date separators, reactions, typing line). The Slack-specific resource is clear enough to separate it from most siblings, but the description never explicitly names or contrasts an alternative (e.g. create_discord_conversation) even though 21 sibling conversation tools exist.

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 conditional guidance for optional features ('Optionally walk through the app's screens... pass flow', 'without them the clip shows the conversation only'), which implies when to enable flow. However there is no when-to-use-this-tool vs. a sibling, no prerequisites, and no statement of what inputs are mandatory beyond what the schema enforces.

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 mutation/safety profile, but the description adds substantial behavioral detail: banner timing and stacking rules, lock-screen behavior, background and transparency handling, export format constraints, and free-plan watermark/render limits. It does not describe the response shape, but with no output schema that is a relatively 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?

The description is front-loaded with the most important banner behavior, but it is a dense run-on paragraph with many semicolons and parentheticals. 'All options controllable' is low-value filler, though most of the length is justified by the tool's complexity.

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

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

Given 15 parameters, nested objects, and no output schema, the description is substantial but not fully complete. It omits return-value information and does not cover several schema parameters, while doing a good job on the central notification and background 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 only 53%, so the description must compensate. It does well for the notifications array, background, lockScreen, and stackNotifications, but leaves theme, soundSettings, and several export/scene parameters largely to the schema, so coverage remains incomplete.

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

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

The description opens with a specific verb and resource: 'Create a Stripe notification animation'. Mentioning the Stripe app icon and Stripe-style notification behavior makes it distinguishable from generic siblings like create_brand_free_notifications, but it never explicitly tells the agent when to choose this over those alternatives.

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 text explains many configuration options but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent has to infer that this is the Stripe-specific notification animation tool from the name and content alone.

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 write/non-destructive/non-idempotent profile, so the bar is lower. The description adds genuine behavioral context beyond them: free-plan exports carry a MockClip watermark, the free plan includes only 2 MCP renders, and the caller should mention /pricing upgrade. It does not contradict any annotation.

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

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

Front-loaded with what the tool produces, then descends into optional parameters. The single dense paragraph is long and the opening feature list is packed, but each sentence roughly earns its place and nothing is redundant 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?

For a 19-parameter, deeply nested tool with no output schema and 42% schema coverage, the description covers the core creative flows well but omits many tunable parameters (theme, export/format, sound, status bar). An agent can call it correctly for the common case but must fall back on the schema for much of the configuration surface.

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 42% across 19 params, so the description carries more burden. It adds real meaning for `flow`, `keyboard`, and especially `group.members`/`author` (contactName becomes the group name, use at least three different authors), but leaves theme, videoFormat use, exportQuality, soundSettings and others unaddressed where the schema is silent.

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+resource ("Create a Telegram conversation animation") and the platform name inherently distinguishes it from the many sibling create_*_conversation tools. The following feature list (reply quotes, attachments, sent/read checks, typing indicator, keyboard) makes the output concrete rather than generic.

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 conditional guidance on optional features: without `flow`/`chatList`/`calls` the clip shows the conversation only, and `keyboard` has auto/always/never behavior. It explains the group-chat variant and the free-plan scenario, but never names an alternative sibling or states when NOT to use this tool, so it stops short of full 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 cover the safety profile (non-read-only, non-destructive, not idempotent), so the description's job is to add operational context -- and it does: free-plan watermarks, the 2-render MCP limit, and the instruction to surface /pricing. It does not disclose export duration or async/queuing behavior, so it stops short of a 5.

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

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

Front-loads the purpose in one clause, then focuses on the non-obvious chat mechanics. The final /pricing upsell sentence is the softest, but it is a stated business requirement and is kept to one sentence.

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-parameter nested generator with no output schema, the description adequately explains the chat path and plan limits but leaves roughly half the parameters undocumented and says nothing about what the tool returns (file URL, render handle, async status), which an agent likely needs.

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 15 params and 53% schema coverage, the description adds real value on the chat sub-tree: 'other' vs 'me' sender semantics, showReadCheck's Read caption, and matchedOn's 'today' default. But the many top-level presentation flags (soundSettings, showInfoButton, showLikesBadge, etc.) get no explanation, so it only partly compensates 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 and resource ('Create a Tinder swipe animation') and clarifies the scope via the matched-profile/chat continuation behavior. However, it never distinguishes itself from the near-identical sibling create_brand_free_dating_swipe, leaving an agent to guess which swipe tool to pick.

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: the chat-continuation condition (right swipe + isMatch + chat) tells the agent how the output changes but not when to choose this over the brand-free dating-swipe sibling. The only explicit directive concerns relaying free-plan upgrade info, which is messaging guidance, not tool-selection guidance.

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

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

Annotations mark this as non-read-only, non-destructive, non-open-world, non-idempotent but say nothing about plan gating. The description adds genuinely useful behavior beyond that: free-plan exports carry a MockClip watermark, the free plan permits only 2 MCP renders, and the agent is told to surface the /pricing upgrade path. It stops short of render time or async/return behavior, but with annotations carrying the safety profile this is solid added context.

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

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

Purpose is front-loaded in the first sentence, followed by per-parameter clarifications. Sentences are dense but earn their place; the trailing free-plan/upgrade instruction is slightly verbose but conveys an actionable instruction rather than filler.

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

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

For a 16-parameter tool with nested objects and no output schema, the description covers only the group and keyboard dimensions plus plan gating. Many message-level timing/visual params (reactionDelay, typingSpeed, showReadCheck, etc.) are neither described here nor fully covered by the schema, leaving real gaps for an agent constructing a rich animation.

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

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

Schema description coverage is only 50% across 16 params, so the description must compensate. It explains the `keyboard` enum semantics, the `group.members` structure (2–12 names, optional avatarUrl), the meaning of `contactName` in group mode, and the non-obvious `author` convention ('use at least three different authors') that is absent from the schema. Timing, reaction, and check-mark params are left unexplained, but the highest-value parameters are covered.

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 gives a specific verb and resource ('Create a WhatsApp conversation animation'), which an agent can map to the WhatsApp sibling among the many platform-specific chat tools. The additional detail on keyboard and group behavior sharpens the purpose, but the description never explicitly contrasts itself with e.g. create_telegram_conversation or create_imessage_conversation, so differentiation rests mostly on the name.

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 through conditional guidance: 'keyboard' values, and 'group.members ... makes the thread a group chat' with 'use at least three different authors.' There is no explicit when-to-use-this vs an alternative tool statement or any exclusion. The free-plan note is a usage constraint but not a selection guideline.

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

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

Annotations only give the safety profile (non-read-only, non-destructive, non-idempotent). The description adds genuinely new behavioral context: free-plan exports carry a MockClip watermark, the free plan is limited to 2 MCP renders, and callers on the free plan should be told about /pricing. It still says nothing about render latency or how the result is delivered.

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?

It is one dense block of prose with no headings or ordering; critical routing facts (per-screen payload shapes, thread view, compose behavior) are buried mid-paragraph. Nearly every sentence is informative, but the wall-of-text format makes it hard to scan for the relevant clause.

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

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

For a 23-parameter, deeply nested, no-output-schema render tool, the description covers the high-value semantics (feeds, thread, compose, screens, flow, account) plus plan limits. Less central params (theme, soundSettings, showTaps behaviors beyond the default note) are left to the schema, which is a reasonable division.

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 35% across 23 params, so the description has to carry weight, and it does: it explains `script` step semantics (scroll/like/repost/newPosts/reply/pause, offset, top/bottom), that each `reply` step reveals the next `pendingReplies` item, that `composedPost` lands on top of the first feed once the flow leaves compose, that `newPostsLabel` uses `{n}` as the count placeholder, and that `account` is shared across profile header and side menu. This meaningfully exceeds the bare 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?

Opens with a specific verb+resource ("Create a X feed animation") and then enumerates the concrete surfaces it renders (post cards, thread view, compose screen, flow). Against siblings like create_reddit_thread and create_instagram_dm_conversation, the X-feed scope is unambiguous from the name plus first clause alone.

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 explains how to drive each screen (feed screens take `posts`+`script`, thread view takes `post:{...}`, other screens take rows by screen id) which is effectively usage guidance for constructing a call. It stops short of explicit when-not guidance, though app-specific tooling makes the sibling choice self-evident.

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