Adseezy

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the mutation and non-idempotency profile is partly pre-supplied. The description still adds real value the annotations do not: this call consumes credits, requires a two-phase cost confirmation, and is asynchronous with a poll-this-other-tool follow-up. It does not, however, describe failure modes, what happens on an unconfirmed cost, or how long generation 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?

Three sentences, front-loaded with purpose, then the credit-confirmation loop, then the return handle and follow-up call. Every clause carries operational information (format source, cost protocol, video id, polling) with no restatement of the tool name or filler.

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

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

For a 16-parameter, no-output-schema, asynchronous generation tool, the definition covers the essentials an agent needs to call it correctly and handle the response (video id plus get_video polling) and the monetization gate. What is missing is minor parameter guidance for the enum/optional styling fields, which the schema already partially documents.

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 16 parameters and only 44% schema description coverage, the description has to carry weight and it does explain the most consequential ones: format (must come from list_ad_formats), the photo/product_url relationship, product_info, captions, music, and the exact meaning of confirm_credits. Roughly half the params (ratio, duration, engine, language, music_mood, caption_style, caption_position, caption_highlight, logo_image_url) get no mention in the description, so gaps remain that the schema alone does not fully close.

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 ("Starts an Ad Studio video ad") plus its required input (a format id from list_ad_formats) and the 1-5 photo/product-page source material. It is clear on its own, but it never distinguishes itself from the sibling create_video, so an agent choosing between the two has to infer the difference.

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 unusually concrete procedural guidance: call first without confirm_credits to obtain the cost, confirm with the user, then call again with that exact cost, and afterward poll get_video. No exclusions or alternatives (e.g. when to use create_video instead) are listed, which keeps it 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 openWorldHint=true, idempotentHint=false, readOnlyHint=false, so the write/external nature is covered; the description adds the non-obvious credit-spend gate requiring explicit user agreement. It also discloses the async job pattern (returns an id, then poll), though it leaves slight ambiguity about whether the pre-confirmation call creates anything or only quotes a price.

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, each carrying distinct information: capability and tool list first, the credit-confirmation workflow second, the return value and follow-up last. No filler or restated title.

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

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

With no output schema, the description correctly supplies the return contract (video id) and the next step (poll get_video). For a 15-parameter, multi-mode tool it covers the critical decision points, but it doesn't clarify which params are mandatory per tool (e.g. product_image_url, logo_image_url, voice/script) or how ratio interacts with tool choice, leaving some trial-and-error.

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

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

Schema coverage is high (87%) with enums for tool, voice, language, duration, and quality, so the description only needs to add routing meaning. It does add cross-call semantics for confirm_credits ("the exact cost the user agreed to, from the previous call") and scopes several params to specific tools (voice/script/captions/language to UGC creator, headline to caption/3D text, quality where offered and pro costs more).

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 ("Starts a product video") and enumerates the style-based tool families it covers (UGC creator, product ads, product with model, product effect, studio, 3D text, animated logo). This makes it clearly distinct from get_video, list_styles, and estimate_cost.

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 two-step procedure: call first without confirm_credits to obtain the cost, get user confirmation, then call again with confirm_credits set to that exact cost. It also names the follow-up action ("poll get_video"), so the agent knows the full lifecycle rather than just the single call.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description still earns credit by adding the business-critical fact that nothing is charged ("without charging anything") and that the figure is exact rather than an upper bound. It stops short of describing error behavior for invalid arguments or what the response payload looks like.

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, with the scope and the no-charge guarantee front-loaded before the invocation instruction. Nothing could be removed without losing information.

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

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

For a read-only estimator with a fully documented nested schema and no output schema, the description covers purpose, cost-free behavior, and argument convention. Only the return shape (a single number vs. a breakdown) is left unstated, which is a minor gap given there is 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?

Schema description coverage is 100%, so baseline is 3; the description adds a genuine semantic layer by framing the nested video/ad objects as pass-through copies of the target tool's arguments, which tells the agent how the three-parameter shape maps onto create_video/create_ad/generate_hooks calls. It does not restate the kind enum semantics or note which fields actually affect price.

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?

"Returns the exact credit cost of a planned create_video, create_ad or generate_hooks call" states a specific verb (returns cost) and resource (credit cost), and names the three siblings it serves as a preflight for. An agent can distinguish it from create_video/create_ad 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?

"Pass the same arguments you would pass to that tool" gives concrete invocation guidance and implicitly defines the when: before running one of the three named generation tools. It does not explicitly say whether it is mandatory before generation or what to do if the estimate exceeds budget, but the context is clear.

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

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

Beyond the annotations it discloses the credit price (30 credits per run), a refund policy on failure, and an expected latency of up to a minute — exactly the operational facts an agent needs before committing a paid, non-idempotent call. This also reinforces the non-idempotent, open-world annotation profile without contradicting it.

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 output set, then cost, then runtime — each sentence carries distinct, decision-relevant information 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 paid generative tool with no output schema, the description covers deliverables, cost, refund, and runtime well. The remaining gap is the shape of the returned payload (field names/structure for hooks and scripts), which the agent cannot learn from any structured field.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds real meaning by framing url and details as an 'and/or' pair, which tells the agent at least one product input is required even though the schema marks zero parameters required. It does not explain how tone or language interact with outputs, so it stops short of a 5.

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

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

The description uses a concrete verb (writes) and enumerates the exact deliverables: 10 ad hooks, 3 UGC scripts at 10/20/30 seconds, a caption and hashtags. It is far more specific than the title alone, but it never distinguishes itself from siblings like create_ad or create_video, leaving the agent to infer whether hook generation is a sub-step of ad creation.

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 by 'from a product page link and/or a description', which hints that at least one product input is needed and that both are acceptable together. There is no explicit when-to-use versus create_ad, no stated prerequisites, and no exclusions, 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?

The annotations already establish that this is a read-only, idempotent, closed-world, non-destructive operation. The description adds useful behavioral context beyond that: it is scoped to the connected account, returns specific account-state fields, and is explicitly free to 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?

The description is a single front-loaded sentence that names the returned account data and includes the relevant 'Free' cost note. Every phrase earns its place, with no redundant or vague 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 zero-parameter read-only tool with rich annotations, the description is largely complete: it identifies the account scope, the returned fields, and the free cost. It could be slightly richer about the account context, but no output schema exists and the key information an agent needs is present.

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

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

The tool has zero parameters, so there is no parameter semantics burden. The schema is empty and fully covered, and the description correctly adds no fabricated parameter details.

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

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

The description uses a specific verb, 'Shows', with the resource 'connected Adseezy account' and names the exact fields returned: credit balance, current plan, and remaining daily spend. This clearly distinguishes it from sibling tools such as get_video, create_ad, and estimate_cost.

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 stated fields: an agent can infer it should call this when it needs account balance, plan, or daily spending capacity. However, the description gives no explicit when-to-use guidance, exclusions, or named alternatives.

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

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

Annotations already cover the safety profile (readOnlyHint true, non-destructive, closed-world), so the description's added value is the conditional return behavior — MP4 link and optional poster only once ready — plus the cost signal "Free", which appears nowhere in the structured fields. It stops short of saying what a non-ready status looks like or whether polling frequency is limited.

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, result shape stated up front and the cost note last; nothing is padded or 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 usefully sketches the return payload (status, progress, MP4 link, poster) and cost. It leaves out possible status values and any error/not-found behavior, which keeps it from being fully complete for a status-polling 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?

Single parameter with 100% schema description coverage that already explains the id comes from create_video, create_ad or list_videos. The description adds no further meaning about the id, so 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 ("Returns a video's status and progress") plus what is included on completion (MP4 link, poster image). It is clearly distinct from create_video/list_videos by being a single-video status read, though it never names a sibling explicitly.

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 "When it's ready" implies polling after creation, which hints at when to call it, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative for listing many videos.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the exact content of the response (formats, engines, per-duration credit costs, allowed option values) and the fact that the call costs nothing ('Free'), which is not visible in any structured field.

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 sentence that front-loads the primary purpose and packs the return contents into one parenthetical list, closing with the cost note. No filler, no repetition of the title.

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

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

With no output schema and no parameters, the description carries the full burden of explaining what comes back, and it does so concretely (formats, two engines with credit costs per duration, option values). Nothing an agent needs in order to decide to call this before create_ad is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly spends no words on inputs and instead describes outputs — the right allocation for a no-arg enumeration 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?

States a specific verb ('Lists') and a precisely scoped resource (Ad Studio formats), then enumerates the categories returned: formats, the two engines with credit costs per duration, and the ratio/language/caption/music options create_ad accepts. That framing also separates it from the sibling create_ad, which consumes rather than enumerates these values.

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: naming the options 'create_ad accepts' signals this is the discovery step before create_ad, and 'Free' implicitly contrasts with paid operations like estimate_cost. There is no explicit when-to-use statement and no exclusions, so the agent must infer the sequencing itself.

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, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds two things beyond that: the returned styles include preview cover URLs, and the call is 'Free' — a cost signal that matters next to estimate_cost. It does not mention pagination behavior or that an omitted tool returns the full tool list with options (only implied by 'the tools and their options').

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 two listing modes, then filtering, then the next-step hand-off. No filler and nothing repeated.

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

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

For a five-parameter, zero-required read tool with full schema coverage and a rich annotation set, the description covers both modes, the filter options, the return shape (cover URLs), cost, and the follow-up tool. Only minor gaps remain, such as default page size and the fact that omitting `tool` returns tools plus their options.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already explains tool, limit, offset, search and category in detail. The description only restates the category/search filtering and the tool-scoping idea without adding syntax, defaults, or matching rules beyond the schema.

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

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

The description uses a specific verb and resource ('Lists the style-based video tools, or the styles of one tool') and clarifies the two operating modes, including that styles come with preview cover URLs. It implicitly separates itself from list_videos/list_ad_formats by scoping to 'style-based' tools, though it never names an alternative outright.

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

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

It gives concrete usage context: omit/no tool to enumerate tools, or filter by category or search phrase, and then hand the selected style id to create_video. That downstream hand-off is genuinely useful routing guidance. It stops short of explicit when-not conditions or naming sibling list tools as 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered structurally. The description adds real value beyond them with the sort order, the returned fields, and the cost note ('Free'), but says nothing about pagination behavior, whether drafts or failed items appear, or how many results are typically returned.

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 compact sentence that front-loads scope and ordering, then cost, with no filler. Every clause earns its place.

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

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

For a one-parameter read-only listing, the description plus rich annotations tell an agent what it gets back (status and links) and in what order. It lacks only pagination/coverage detail, which is a minor gap for this complexity.

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

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

Schema description coverage is 100% with a single documented 'limit' parameter (1–50, default 10), so the schema carries the semantics. The description adds no meaning about the limit, 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 ('Lists the account's most recent videos and ads') plus ordering ('newest first') and returned fields ('status and links'). It is clearly distinguishable from create_* and get_video siblings by being a recent-items listing, though it never explicitly contrasts with get_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?

'Free' is a decision-relevant hint that this costs nothing, implying it is the cheap way to browse recent content, but there is no explicit when-to-use vs get_video or when-not guidance. The agent must infer that this is the right call for a quick recent-items scan.

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