AIGE

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

Annotations only say non-idempotent and non-destructive; the description adds the copy-then-insert semantics, place-after-source behavior, the required expectedVersion with the DECK_CONFLICT read-and-retry protocol, and that the call is free. These are exactly the operational facts an agent needs before invoking a mutating, version-gated 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?

Four tight sentences: trigger first, then mechanics, then the follow-up dependency, then the conflict/cost note. No filler or restatement of the tool name.

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

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

For a 6-parameter mutation tool with no output schema, the description covers the essential flow and failure mode. It would be stronger if it stated whether a new slide ID is returned so the agent can chain antix_set_slide_copy, and what locale/accountHandle/projectId affect.

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

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

Schema coverage is only 33%, so the description must compensate. It does add real meaning for afterSlideId (defaults to last slide) and expectedVersion (stale value fails with DECK_CONFLICT), but deckId, locale, accountHandle, and projectId are left to the schema with no 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?

States a specific operation — copying an existing slide and inserting the duplicate immediately after the original — with the placement parameter named and the default behavior spelled out. This clearly separates it from siblings such as antix_delete_slide, antix_reorder_slides, and antix_create_deck.

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

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

"Use this when the user asks to add or duplicate a slide" gives an explicit trigger, and the description routes the agent onward to antix_set_slide_copy for content. It stops short of naming when NOT to use it (e.g. versus antix_edit_deck_slides or antix_create_deck), so no explicit exclusions.

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

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

Beyond the non-destructive and non-idempotent annotations, the description explains important behavior: data URLs are normalized and uploaded to AIGE Storage, gallery entries become fetchable HTTPS URLs, and the latest image is automatically used by antix_generate_image when no explicit referenceImage is provided. It also notes visibility in the AIGE web PromptBar and describes rejected URLs in the return value.

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

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

The description is front-loaded, organized into Inputs, workflow, and Returns sections, and each section is useful. It is somewhat verbose and repeats the 'latest gallery image as the img2img reference' point in both the opening and the workflow steps, but this repetition is minor and does not obscure the core 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?

The tool is fully described for a two-parameter append operation with no output schema. The description covers input formats, fallback behavior, side effects, the downstream auto-img2img behavior, and the return fields including rejected URLs and totalImages. An agent has enough information to call it correctly without further clarification.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains that characterId comes from antix_list_characters, that images accepts HTTPS URLs or base64 data URLs, and that 1-20 images are allowed per call, matching and enriching the schema constraints.

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: 'Append images to a character's saved reference gallery.' It clearly distinguishes the operation from sibling tools such as antix_list_character_gallery and antix_generate_image by explaining that this tool populates the gallery and that antix_generate_image later consumes the latest entry.

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

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

It provides explicit when-to-use guidance, including a four-step workflow for bridging chat-attached images into the img2img flow. It also states the fallback behavior when the Claude client cannot forward image bytes, directing the user to https://aige.ws/r and then calling the tool with the resulting URL.

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

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

Annotations flag destructiveHint=true and idempotentHint=false, and the description earns its keep by disclosing exactly what is destroyed (layout, slide compositions, text styling) versus preserved (every slide's words, and colours/typefaces when keepTheme:true). It additionally states the version precondition, the conflict-retry protocol, and that the call is free.

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

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

Information is front-loaded: trigger phrasings, then the operation, then prerequisites and failure handling. It is a single dense block with no wasted sentence, though the trigger-phrase enumeration and the 'Free' remark could be trimmed marginally.

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

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

For an 8-parameter destructive mutation with no output schema, the description covers the full operator loop: how to pick a target layout, what gets replaced, how to avoid a stale-version failure, and how to recover from one. The only unused parameter (projectId) is already documented 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?

Schema description coverage is only 25% (projectId and expectedVersion only), so the description must compensate; it explains templateId's lib- prefix convention, the meaning of keepTheme, and that look is an alternative styling axis with its own shape. deckId, locale and accountHandle remain undocumented anywhere, which keeps this 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?

"Re-lay the whole deck in another built-in layout ... keeping every slide's words" gives a specific verb, an explicit scope (whole deck, not one slide) and a preservation guarantee. The deck-wide scope implicitly separates it from antix_set_slide_layout and, combined with keepTheme, from antix_set_deck_palette/antix_set_deck_fonts.

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?

Supplies concrete user phrasings that should trigger it ('try a different layout', 'use the highlighter layout'), a mandatory prerequisite ('List the layouts with antix_list_carousel_templates first'), and the alternative path (templateId vs look). It also prescribes recovery behavior on DECK_CONFLICT rather than leaving the agent to guess.

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

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

Goes well beyond the annotations: discloses that the post is NOT live on return, that 'live' means status published with a permalink, and that idempotent-sounding Story reminders terminate at handoff_ready with no permalink. This is exactly the out-of-band behavior an agent would otherwise get wrong, and it does not conflict with readOnlyHint=false / destructiveHint=false.

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 safety-critical constraint and organized as release-condition, timing, verification, and edge case. Slightly padded by restating the publishNow behavior almost verbatim from the schema, which is minor redundancy.

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

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

For a mutation tool with no output schema, it covers everything an agent needs: the confirm gate, the timing branch, the fact that success is not equivalent to being live, how to verify, and the Story-reminder exception. Nothing material is missing.

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

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

At 67% schema coverage, the description usefully reinforces that confirm must reflect real user approval in this conversation and explains what publishNow=true does to scheduling timing. postId's meaning is left implicit, but its constrained name and pattern make it self-evident.

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 ('Release a post that is waiting for approval') and immediately scopes it to the approval workflow, which cleanly separates it from antix_get_post, antix_cancel_post, and antix_create_post. The Story-reminder carve-out further clarifies what class of object this actually acts on.

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

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

Explicit precondition ('ONLY after the user explicitly approved it in this conversation'), explicit required flag, and an explicit post-call verification step via antix_get_post. It also distinguishes the publishNow branch versus keeping the booked time, so an agent knows which call variant to make.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description adds useful context beyond annotations: screening, full-bleed placement, copy recolouring, free versus paid replacement rules, expectedVersion conflict behavior, and retry shading with the same image. However, it does not fully explain the destructive scope of replacing existing slide artwork beyond the confirmDropPaid condition.

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

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

The description is front-loaded with the core action and free status, then layers replacement rules and image-quality guidance. It is dense and useful, though long; a few clauses could be tightened without losing meaning.

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?

Although there is no output schema, the description explains that it returns the deck with re-rendered previews and tells the agent how to respond to a review that says the copy is lost. Combined with the replacement and version guidance, it is complete enough for correct invocation.

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

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

Schema coverage is 56%, so the description must help with several parameters. It adds important meaning for slideIds, expectedVersion, shade, confirmDropPaid, and the image source, but does not explain deckId, projectId, locale, or accountHandle.

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: putting an image file from the conversation onto named slides of a carousel deck. It also distinguishes the operation from generation-based siblings by saying nothing is generated and no credits are used, so an agent can separate it from antix_generate_deck_slide_images or antix_set_slide_picture.

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

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

Gives explicit when-to-use conditions: the image must be one the user uploaded or one the agent generated separately. It also specifies replacement rules, the requirement to ask the user before replacing paid artwork, and the retry path when the review says the copy is lost.

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 idempotentHint=false and destructiveHint=false, and the description adds substantial behavior beyond them: it is free but rate-limited, unanalyzed handles are refused rather than fetched, aspect is silently remapped with a response flag, and brandKitAvailable gates whether palette/typography actually ground the brief. That is exactly the kind of context structured fields 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 defining sentence leads with the artifact, then constraints and the create_deck handoff follow in priority order. It is dense but nearly every sentence carries operational information, though the brandKitAvailable/styleSource passage is somewhat verbose for what it adds.

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 12-param tool with no output schema, the description still names the key return signals (aspectMappedFrom, styleSource, brandKitAvailable) and explains the downstream contract with antix_create_deck. An agent can call it and interpret the result without further lookup.

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

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

Schema description coverage is only 25% across 12 params, so the description must compensate. It adds real meaning for accountHandle (must be audited first) and aspect (9:16 mapping), but leaves brand, objective, slideCount, voiceDescription, visualReferences, projectId, briefId, and locale unexplained beyond their names and enums, so the gap is only partially closed.

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

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

The first sentence names a specific verb and multi-part artifact (slide-by-slide narrative with headline/body/image brief, caption, hashtags) plus its inputs (topic + audience). It also distinguishes itself from antix_create_deck by stating the result 'feeds antix_create_deck verbatim', so an agent knows the sequencing between the two siblings.

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

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

It gives concrete conditions: pass accountHandle only for already-analyzed accounts (refused, never fetched), and 9:16 is accepted then mapped to 4:5. It doesn't compare against alternatives like antix_list_carousel_templates or antix_list_carousel_design_options, so the 'which sibling' routing is only partially covered.

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

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

Annotations already declare destructive and idempotent, so safety is structured; the description adds what the annotations cannot — the set of eligible states (scheduled, awaiting approval, missed). It does not state whether cancellation is reversible or what happens to the post record afterward, which would be the remaining behavioral 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?

Two short sentences with the eligibility rule front-loaded and the exclusion second. No filler, no restatement of the tool name.

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

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

A one-parameter mutation tool with annotations covering safety and no output schema needs little more than eligibility rules, which are present. The only missing piece is guidance on sourcing postId and the outcome of a successful cancel.

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

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

Schema description coverage is 0% and the single parameter postId is documented only by type, pattern, and length constraints. The description never clarifies what a postId refers to or how to obtain one (e.g., from antix_list_scheduled_posts), so it adds no semantic value beyond the schema.

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

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

States a specific verb (cancel) and resource (booked post), and bounds the resource to post states that have not gone out. It implicitly separates itself from publish/approve siblings, though it never names an alternative 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?

Gives a clear when-to-use condition (post must not have gone out) and an explicit when-not (already live posts cannot be removed from here). It stops short of saying what to do instead for a live post, so the agent is left without a routing target.

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?

No annotations exist, so the description carries the full burden and does so: it enumerates the terminal statuses, defines the non-obvious `partial` semantics ('at least one item completed and at least one failed'), and states that failed items carry refund details. It also discloses the response shape (`batchStatus`, ordered `items[]`) and the `markdownEmbed` payload.

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 and scope are front-loaded, and the polling cadence is separated into its own labeled sentence. The imperative INLINE RENDERING block is long and is really agent-behavior instruction rather than tool semantics, which dilutes the tool contract somewhat, but nothing is pure 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?

There is no output schema, yet the description fully accounts for the return value: status vocabulary, item ordering, per-item fields (status, prompt, model, media), terminal-state rules, and the embed string. An agent can call and interpret results correctly from the description alone.

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

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

Only one parameter and the schema gives it 0% description coverage, but `batchId` is self-evident from the name and the description only says 'by `batchId`'. No format or sourcing detail (e.g. where the id comes from) is added beyond the property name.

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

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

Opens with a specific verb and resource: 'Poll every generation in an image batch or multi-video request in ONE call, by `batchId`'. This clearly separates it from the single-task sibling `antix_check_task`, which is named explicitly later. An agent knows exactly what it does without opening the schema.

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

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

Gives explicit polling protocol: wait ~15s after submission, then every ~10s while status is `queued`/`processing`, stop on `completed`/`partial`/`failed`, plus a note on expected wall time. It also routes to the sibling relationship by binding the inline-rendering rule to 'same rule as antix_check_task'.

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 that the tool is FREE, read-only, deterministic, never calls a model, and never spends credits. It also explains finding levels (`fix` vs `check`), that `ready:true` is not a taste judgement, and that placeholder findings mirror the paid-art placeholder guard.

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 and workflow are front-loaded, and the dense checklist is relevant to understanding what the linter detects. It is longer than typical, but most sentences carry operational value rather than restating 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, the description explains the finding shape (`level`, `layers`, exact correction), the expected edit loop, the optional image behavior, and the limits of `ready:true`. It is complete enough for an agent to call and interpret the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds useful meaning for `look:true`: it returns one small numbered image block, the numbering matches findings, and the image is for the agent rather than the user reply because the deck panel already shows the slides.

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

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

The description opens with a precise verb and resource: lint a carousel deck for posting blockers. It goes further by enumerating the exact classes of problems detected and clearly separates structural checks from subjective taste.

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 an explicit workflow: antix_get_deck → antix_check_deck_readiness → antix_edit_deck_slides → re-check, with a two-round limit and instruction to tell the user what remains. It also states when to use `look:true` versus leaving it out for a routine check.

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 no annotations, the description carries the full burden and does so thoroughly: it discloses refund behavior on failure, credit spending, latency expectations (10-25s images, 30-90s videos), and the full response shape for both image and video tasks. It also flags the URL-safety constraint (never substitute raw firebasestorage URLs) and the panel-vs-no-panel rendering distinction, which are behavioral traits no schema could express.

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 and the status branches are well-ordered, but the response is heavily padded: the 'never show twice' rule is restated four separate times (pasting once, not replacing with a description, not pasting twice, whole concatenated string), and emoji/caps formatting inflates length. Much of the presentation directive is genuinely necessary, but the repetition costs it.

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

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

There is no output schema, so the description must document return values itself — and it does, with separate response shapes for completed image and video tasks listing every field. Combined with branching behavior, refunds, and polling timing, an agent has everything needed to call and handle the result correctly.

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

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

Schema description coverage is 0% for the single taskId parameter, but the description compensates by explaining where the value comes from ('returned by antix_generate_image or antix_generate_video'). It gives origin and semantics but not format, so slightly below the no-parameter baseline of 4-plus.

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

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

States a specific verb and resource ('Check the status of an in-progress generation task') and immediately disambiguates by naming the producing tools (antix_generate_image / antix_generate_video). It even enumerates the possible return values (queued, processing, completed, failed), so an agent knows exactly what question this tool answers.

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

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

Gives explicit prescriptive guidance per status branch ('queued/processing → poll again in 10s', 'completed → paste markdownEmbed first', 'failed → surface error, credits refunded') plus concrete polling cadence for images vs videos. The one gap is that the adjacent sibling antix_check_batch is never mentioned, so an agent holding a batch task has no stated rule for which status tool to 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 declare destructiveHint=true and idempotentHint=false, and the description goes well past that: it names the resulting state ('the layout's own colours come back'), the protected resource (paid artwork), the required precondition (current expectedVersion), the failure mode and retry loop, and the cost ('Free'). That is substantive context an agent needs to act safely on a destructive call.

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

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

Front-loads the trigger, then scope, then guardrails, then the retry rule, then cost — a sensible ordering. It is dense and slightly run-on in the middle clause, but every sentence carries information and none are 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 destructive, version-guarded mutation with no output schema, the description covers trigger, scope, protected content, precondition, conflict recovery, and cost. It does not say what is returned or how the optional projectId/accountHandle/locale affect the operation, which is the remaining gap.

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

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

Schema coverage is only 33%, so the description must compensate, and it does for the two decision-critical parameters: slideId means 'one slide' while omitting it means the whole deck, and expectedVersion carries conflict semantics with the DECK_CONFLICT failure path. The three ancillary params (locale, projectId, accountHandle) are not explained in the description, leaving some 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 ('remove the drawn background... from one slide or from the whole deck') and explicitly names the sibling that created the artifact (antix_attach_deck_image). It also distinguishes itself from paid-artwork removal, so an agent can tell exactly what is and isn't in scope.

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

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

Gives an explicit trigger ('when the user asks to remove a background'), the two supported scopes, an exclusion ('never removes artwork that was paid for'), and a conflict-recovery procedure ('on DECK_CONFLICT, read the deck again and repeat the same intended change'). Nothing about when to reach for this tool is left to inference.

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

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

Goes well beyond the annotations: discloses cost ('FREE (rate-limited)'), side effects (persists to the AIGE account, mirrored as a Markdown file plus long-term Memory), and a return behavior (opens pre-filled in the web app via openUrl). Those persistence details are exactly what an agent needs before triggering an unannotated write-ish side effect.

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, then sequences cost, persistence, return channel, locale pairing, and refinement mode — each sentence carries distinct information. It is dense but borders on cramming five behaviors into one paragraph, which slightly hurts scannability.

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 nine-parameter, non-idempotent generation tool with no output schema, the description covers what is produced, where it lands, what it costs, and how the returned openUrl is used. An agent can decide and call correctly without further reading.

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?

Adds real meaning beyond the 78%-covered schema, notably the locale (brief text) versus accountLocale (publishable copy) distinction and the briefId refine-vs-create semantics. It stays silent on research and sourceUrl, which the schema already documents, so it does not fully cover all nine 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?

Opens with a specific verb+resource ('Turn a raw idea into a structured content brief') and enumerates the artifacts produced (angle, hooks, copy directions, formats, prompt recommendations). This makes it unmistakably distinct from siblings like antix_compose_social_post or antix_enhance_prompt without needing to name them.

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

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

Gives concrete conditional guidance: pass projectId to scope Files/Memory to a production project, pass briefId to refine rather than mint, pass locale vs accountLocale for different language targets. It does not explicitly route against alternative sibling tools (e.g., when a brief is overkill and a social post is enough), 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 cover the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds valuable context: nothing is live on return, the publisher posts within about a minute, and status only reaches published with a permalink. However, it is a mutation tool with no explicit statement of reversibility beyond pointing at antix_cancel_post and antix_approve_post.

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

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

The critical facts (confirm semantics, nothing live yet, FREE) are front-loaded, which is good, but the remainder is a single ~1,500-word paragraph mixing media rules, Stories, threads, extras, alt text, tags, Reels and per-platform captions. Backticked field names help, but an agent must rescan the block to find any one rule.

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 11-parameter tool with deep nesting, cross-channel conditional refusals and no output schema, the description is remarkably complete: it names every refusal condition, which fields are Instagram- vs Threads-only, and what the response will report back.

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

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

Schema coverage is already 100%, but the description adds substantial meaning the schema can't: which media combinations produce a photo/Reel/carousel/text post, why Instagram Stories degrade to reminders on non-Business accounts, that spoilerRanges count in JavaScript string units, and the one-shot audio rename rule.

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: 'Book a post on the user's own connected Instagram and/or Threads channels', and immediately frames the approval flow via antix_approve_post. It does not, however, distinguish itself from the sibling antix_create_post, which is the most likely source of selection ambiguity.

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

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

Explicitly says when to set confirm:true (only after the user said to post) and what happens without it, routes to antix_approve_post and antix_get_post for verification, and explains each `when` mode's preconditions including the queue refusal case. Alternatives and exclusions are named rather than implied.

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 idempotentHint=false and destructiveHint=false; the description goes well beyond by disclosing where the write lands (the same collection the AIGE web app uses), the observable effect (character appears in the aige.ws switcher immediately), and the downstream reuse of characterId. The base64/upload fallback note is real operational context not present in structured fields.

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

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

Bold-labeled Inputs / Effects / Returns blocks make it scannable and the trigger example is front-loaded before the mechanics. Slightly long, with a few lines (name, gallery count) that re-state schema text, but nearly every block adds something the structured data lacks.

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

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

No output schema exists, and the description compensates with an explicit Returns list (characterId, name, avatarUrl, galleryCount, characterPageUrl). Combined with the Effects and input-handling notes, an agent has everything needed to call this correctly and to use the result.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by clarifying that avatarUrl accepts a base64 data URL as well as an HTTPS URL (the schema says only 'HTTPS URL of the avatar image') and by explaining what galleryUrls seeds ('up to 8 extra reference images to seed the reference gallery'). The name/galleryItems details largely restate 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 + resource ('Create a NEW persistent AIGE character from an image') and the capitalized 'NEW' plus the persistence framing separates it from siblings like antix_set_character_avatar and antix_add_to_character_gallery. An agent can identify the operation without opening the schema.

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

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

Gives explicit trigger phrasing ('name her Aurorra', 'this is my model, call her X', 'create a character named Y from this image') and chains forward to antix_generate_image / antix_generate_image_batch / antix_generate_video via the returned characterId. It also names the sibling whose input rules apply and offers a fallback upload path when the client can't forward bytes.

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

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

Goes well beyond the idempotentHint/destructiveHint pair: states Canvas delivery is automatic across Claude/ChatGPT/CLI/automation, the call is FREE, the response carries backgroundCostEstimate from the live charge resolver, and reusing a deckId fails with DECK_EXISTS — consistent with destructiveHint=false. It also warns that previews are layout approximations rather than exact renders.

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

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

Dense but front-loaded: the core action and the three input forms come first, then cost, then the non-overwrite guarantee, then preview and publishing caveats. It is one long run-on paragraph, but each sentence contributes new information rather than restating the name or schema.

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

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

For a 12-param, nested-object tool with no output schema, the description does meaningful work: it names two response fields (backgroundCostEstimate, preview URLs) and explains the failure mode. The main gap is that it never clarifies the minimal viable payload or the defaults for aspect/slideCount, which matters given zero required parameters.

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% and there are 12 params with zero required, yet the description never states whether blueprint/topic/templateId are mutually exclusive or which one wins when several are supplied. It does add meaning for the entry modes and cost estimate, but leaves look, brand, aspect, slideCount, accountHandle, backgroundModel, locale and projectId entirely 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 — 'materialise ... into a REAL carousel deck' — plus the three accepted input forms (blueprint, bare topic, templateId) and the side effect of rendering previews. It also implicitly distinguishes itself from antix_build_carousel_blueprint (produces the blueprint) and the slide-level mutators, since this creates the whole deck.

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 three entry paths and the note that no Machine Run is required give a clear picture of when this tool fits. It also discloses an exclusion ('Instagram autopublish is NOT available'), but it never names a sibling alternative or states when-not to use this versus e.g. antix_send_to_canvas or antix_get_deck.

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 sparse annotations, the description discloses that this creates a public post, returns a postId and public postUrl, and can attach media via imageUrls or reference an AIGE generation via fromHistoryId. It still omits meaningful behavioral details such as retry/idempotency behavior despite the idempotencyKey parameter and idempotentHint=false annotation.

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

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

The description is compact and front-loaded: purpose first, attachment modes second, usage cues third, return values fourth, and a short note on tags. Every sentence contributes actionable information without repetition.

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

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

For a publish tool with no output schema, the description helpfully covers the core action, primary media-attachment paths, and return values. It is not fully complete for a seven-parameter mutation because idempotency, fromTaskId, and videoUrls are not explained, but the main calling context is present.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains imageUrls, fromHistoryId, and optional tags, but leaves text, videoUrls, fromTaskId, and especially idempotencyKey unexplained, leaving several caller decisions to inference.

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

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

The description states a specific verb and resource: publishing a post to the AIGORA social feed at aigora.ws. It clearly frames the action as sharing/publishing a creation to a feed, which separates it from generation-oriented siblings such as antix_generate_image or antix_compose_social_post.

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

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

The description gives concrete when-to-use cases: sharing a creation, publishing to a feed, posting to social, or showing work to the community. It does not explicitly name alternatives or when-not-to-use cases, such as composing content versus publishing an approved/scheduled post, so it falls 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 already declare destructiveHint=true and idempotentHint=false; the description goes beyond them by disclosing that deleting a paid-background slide discards spend, that expectedVersion is mandatory, and that a stale version fails before any work is done. It also notes the operation is free. It stops short of describing the return payload or whether other slides shift/re-index after deletion, which is relevant for a destructive non-idempotent op.

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?

Five sentences, all load-bearing: trigger first, scope second, then the confirmation gate, then the concurrency contract, then the cost note. No repetition of the title or schema fields verbatim.

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

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

For a destructive, non-idempotent, version-guarded mutation with no output schema, the description covers the confirmation gate, the version requirement, the conflict-recovery loop, and the billing side effect. Nothing essential to a correct invocation is missing.

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

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

Schema description coverage is only 43% across 7 params, so the description must compensate; it covers the two risky ones (confirmDropPaid as a confirmation gate, expectedVersion as the concurrency token with its DECK_CONFLICT failure mode). The remaining params (locale, accountHandle, and unlabeled deckId/slideId) get no semantic help beyond their obvious names, leaving deck scoping and the Canvas-related projectId lightly explained.

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

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

States a specific verb and resource — 'remove a slide', 'Delete one slide from the deck' — and scopes it to exactly one slide. This clearly separates it from sibling mutations like antix_add_slide, antix_reorder_slides, and antix_edit_deck_slides.

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

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

Gives an explicit trigger ('when the user asks to remove a slide'), a prerequisite gate for paid backgrounds requiring user confirmation before proceeding, and a recovery path on DECK_CONFLICT. An agent knows when to call it, when to pause for approval, and what to do on failure.

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 flag destructiveHint=true and idempotentHint=false; the description goes far beyond by disclosing transactional semantics (stale version fails with DECK_CONFLICT before touching anything), atomic batch abort on paid backgrounds unless confirmDropPaid:true, re-render scope ('only edited slides'), automatic text re-fit, the `design` return payload, and cost ('FREE'). This is exactly the extra context an agent needs to avoid blind writes.

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, then ops are grouped under Copy/Design/Structure, then constraints. Dense and long for a single paragraph but sized appropriately to a 13-variant operation union, with little 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 destructive, non-idempotent batch tool with no output schema, the description covers conflict handling, atomicity, paid-resource safety, return shape, and render behavior. Minor gaps remain: no ordering guarantee for ops, no mention of the Canvas side effect implied by projectId, and no error taxonomy beyond DECK_CONFLICT.

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 43%, and the description compensates meaningfully: it explains the deck-wide-unless-slideId scoping rule, that apply_template keeps copy, that set_background_url is restricted to allowlisted AIGE/Storage hosts, and which external tool supplies font families. It leaves the large nested background recipe (light, objects, layers) and top-level locale/accountHandle/projectId unexplained, though some are covered by schema descriptions.

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

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

The opening sentence states a specific verb and resource ('Apply a bounded batch of edits to a deck') and enumerates the three op families (copy, design, structure), making the scope concrete. It does not explicitly distinguish itself from the many per-slide sibling tools (antix_set_slide_copy, antix_set_deck_fonts, antix_reorder_slides), so an agent must infer that this is the batch alternative.

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

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

Useful prerequisites are given: expectedVersion must come from a prior antix_get_deck read, design values come from antix_list_carousel_design_options, and the agent is told to ask the user before setting confirmDropPaid. However, there is no explicit when-to-use-this-vs-siblings routing against the overlapping single-slide tools, so the choice is only implied.

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 no annotations, the description carries the full disclosure burden, and it does address the most important misconception — no image is produced, only text is returned, and a specific model performs the work. However, it says nothing about whether this consumes credits (relevant given the sibling antix_get_credits), latency, or any failure/limits behavior, which matters for a 9-parameter remote model 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?

Four short sentences, front-loaded with what the tool does, then the negative clarification, then the usage pointer, then the mode instruction. No filler. Slightly penalized only because the mode sentence sits at the end where the schema-adjacent guidance would be more useful earlier.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description explains roughly one parameter and no return shape. An agent knows what the tool is for but not how the model/quality/duration/referenceTypes inputs affect the enhancement, nor what the enhanced text looks like coming back, so it would likely call with only a prompt and mode and miss the tool's real capability.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate and it largely does not. Only 'mode' is explained ('image' for visual prompts, 'video' for motion prompts); model, quality, audio, duration, resolution, aspectRatio, and referenceTypes are left entirely to bare enum lists with no guidance on how they interact with mode or why an enhancement call would accept generation-style options.

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 ('expand a brief prompt into a richer, model-optimized description') and names the underlying engine (Gemini 3.5 Flash Lite). It explicitly distinguishes itself from the generation siblings with 'Doesn't generate an image — just improves the text,' so an agent can tell it apart from antix_generate_image without opening any schema.

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

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

Gives clear positive placement: 'Useful before calling antix_generate_image or antix_generate_video for higher-quality results,' which is exactly the routing decision an agent needs. It also says which mode value maps to which downstream tool. It stops short of a when-not-to-use case (e.g. when the prompt is already detailed, or cost considerations), so it is a strong 4 rather than a 5.

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

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

Beyond the annotations, it discloses that exports are permanent, public, full-resolution, and never reaped, unlike previews subject to 14-day cleanup and pruning. It explains browser-finalized export precedence, server-side rendering reuse per designVersion/format, and the pendingArt flag when art is missing.

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 main purpose and key warning are front-loaded, and the remaining paragraphs are organized around alternatives, caching behavior, response shape, and caveats. It is somewhat dense and long, but nearly every sentence provides actionable information rather than restating structured fields.

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

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

For a tool with no output schema, the description explains the returned URLs, exportSource semantics, bufferAssets shape, and pendingArt signal. It also covers the main operational caveat that Instagram autopublish is unavailable and points to the alternative tool.

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

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

Schema coverage is 100%, so the schema already documents deckId, format, slideIds, and knownDesignVersion. The description still adds behavioral meaning by explaining that exports always target the current version and that rendering is reused across calls for the same designVersion and format.

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: export a carousel deck's slides as permanent, full-resolution image files with direct URLs. It explicitly distinguishes itself from antix_get_deck's previewUrl and from antix_compose_social_post, so an agent can identify the correct tool without inspecting schemas.

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

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

It names concrete use cases (scheduler, uploader, user download) and explicitly says not to hand out previewUrl for those cases. It also gives sequencing guidance with antix_check_deck_readiness and redirects posting use cases to antix_compose_social_post.

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

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

Annotations declare idempotentHint=true and destructiveHint=true; the description earns its keep by explaining exactly why: it replaces the slide's background image, determinism holds for 'the same recipe and `seed`', and a stale `expectedVersion` fails with DECK_CONFLICT before any work. It also discloses side effects not in the annotations — text recolouring for contrast unless `adaptInk:false`, and objects rendering BEHIND the copy.

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 highest-value facts (what it draws, that it is free and fast) and every clause carries information. It is one dense ~250-word paragraph though, and the long material/pattern enumerations would read far better as a bulleted list or grouped 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 9-parameter tool with nested objects, no output schema and thin schema descriptions, it covers the side effects, version precondition, paid-overwrite confirmation and determinism. It never mentions the return value or the role of locale/projectId/accountHandle, but those are minor relative to the recipe guidance it does provide.

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%, but the description compensates heavily: it defines the recipe shape (base, ≤4 layers, light, ≤8 objects, grain/vignette/scrim), the five `base` variants and their shader/material enumerations, palette-slot colour values, object placement via x/y or `on`, and `seed` re-roll semantics. The only untouched parameters are locale, projectId and accountHandle.

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 ('Draw a procedural background on a deck's slides') and immediately distinguishes itself from the model-based sibling: 'by code, not by a model: FREE, no credits, about a second.' An agent can tell this apart from antix_generate_deck_slide_images or antix_clear_slide_background without opening a schema.

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

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

It sets the condition for dropping existing paid art ('needs `confirmDropPaid:true` after the user agrees') and states 'Omit `slideIds` for every slide', which is real invocation guidance. It stops short of naming alternatives (e.g. when to prefer model-generated art via antix_generate_deck_slide_images instead), so an exclusion rule is left implicit.

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

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

Annotations only supply weak hints (idempotentHint false, destructiveHint false), but the description adds substantial undisclosed behavior: it spends credits, refusals charge nothing, failed generations auto-refund, deck-attach hiccups never refund, and placeholder-copy slides are refused at zero spend. This is exactly the extra context annotations cannot convey.

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

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

The critical payload (cost gate, required params, approval flow) is front-loaded and every sentence carries operational content. The bold/bold-caps emphasis is slightly heavy but does not waste much space.

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

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

For a no-output-schema, 9-param, credit-spending mutation, the description covers the approval gate, refund behavior and post-call polling well. The remaining gap is the unexplained optional parameters, which leaves an agent guessing about model/resolution/characterId selection.

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

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

Schema coverage is only 33% across 9 params. The description explains slideIds, maxCredits and promptOverrides semantics, but those are already documented in the schema, while model, resolution, characterId, accountHandle and idempotencyKey remain undocumented in both places. Partial compensation, not full.

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

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

States a specific verb and resource ('Generate background art for NAMED slides of a carousel deck') plus its cost-critical distinction from other deck tools. It does not, however, explicitly contrast with the sibling antix_generate_deck_background, and the claim 'the ONLY deck tool that spends credits' is ambiguous given a background-generation sibling exists.

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

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

Gives explicit prerequisites and a pre-call sequence (quote backgroundCostEstimate from antix_create_deck/antix_get_deck, get explicit user approval), plus conditional routing (write copy first or use promptOverrides; poll antix_check_batch for progress). An agent knows exactly when and how to invoke it.

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

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

Goes well beyond the thin annotations (idempotentHint/destructiveHint false) by disclosing async queueing, return-in-<1s, poll at 10–25s, upfront atomic credit charge with per-image cost math, and automatic refunds on provider failure such as content_policy_violation. One inconsistency is left unresolved at the description level: annotations declare idempotentHint=false while the schema advertises an idempotencyKey that guarantees 'same key must not charge or queue twice' — the description never reconciles these, so retry safety is ambiguous.

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 single-vs-batch decision and the async contract, then organized into bolded, skimmable sections — appropriate shape for a 16-parameter tool. It is very long, however, and the model list is partially restated across the img2img and model-selection sections, which is redundant for an agent that reads sequentially.

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 async, credit-consuming, multi-model generation tool with no output schema, the description covers the full lifecycle: what is returned (taskId, creditsSpent, perImageCost, creditsRemaining, estimatedSeconds, nextStep), how to poll, and what happens on insufficient credits and on generation failure. Nothing essential to calling it correctly is missing.

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

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

Schema description coverage is only 25%, so the description carries the burden and mostly delivers: per-parameter honor semantics for model, aspectRatio (with provider-specific preset mapping), resolution clamping, quality, style injection, count fan-out and cost multiplication, characterUse, and a 4-step reference-image resolution priority order. Gaps remain for referenceImageUrl (never explained alongside referenceImage/referenceImages) and for how the three reference variants interact.

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 + scope ('Generate one or more AI images for a SINGLE prompt') and immediately names the sibling it is not for — 'IF THE USER WANTS MULTIPLE DIFFERENT PROMPTS ... USE antix_generate_image_batch INSTEAD'. An agent can distinguish this from antix_generate_image_batch, antix_generate_video and antix_enhance_prompt 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?

Explicit routing rules: single prompt here, N different prompts to the batch tool, model selection by intent, and a fallback to antix_pick_model when unsure. It also enumerates when to pass referenceImage explicitly vs. let the character gallery/avatar resolve, and tells the agent exactly what to say to the user when chat-attached bytes are unavailable instead of silently degrading to text-to-image.

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 carry idempotentHint/destructiveHint, so the description does the heavy lifting and does it well: atomic all-or-nothing billing, ~15-30s wall time, the exact return fields (batchId, tasks[], totalCredits, creditsRemaining, estimatedSeconds), and a polling cadence via antix_check_batch. Limits (10 items, 4 variations, 40 images) and the reference-resolution priority chain are disclosed.

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

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

Front-loaded with the core action, then structured with bold headers and bullets so an agent can skim to the relevant section. Slightly inflated by persuasive framing ('Why this over N sequential...') and duplicated limit/speed claims, but almost every sentence carries operational 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 13-parameter tool with no output schema, the description compensates by enumerating return fields, polling behavior, billing semantics, and hard limits. Remaining shortfall: `referenceImages`, `idempotencyKey` retry semantics, and the projectId/sessionId asset-routing behavior are left to the schema (or undocumented), which matters for a paid batch operation.

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

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

With only 31% schema coverage, the description usefully explains the `items` array (1-10 entries, `prompt` required, per-item overrides), the top-level shared-param inheritance rule, and the five-step reference resolution order. The notable gap is `referenceImages` (plural, up to 10) which appears only in the schema and is never reconciled with the singular `referenceImage` priority chain.

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

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

States a specific verb+resource (submit N image generations in parallel) and immediately distinguishes itself from the sequential sibling by contrasting with 'N sequential generate_image calls'. An agent can route between this, antix_generate_image, and antix_check_batch 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?

Gives an explicit trigger ('use this whenever the user asks for multiple different scenes / poses / variations at once') with a worked example, names the alternative it replaces, and states the boundary condition ('for >10 different prompts, send multiple sequential batches'). When-to-use and when-to-split are both covered.

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 only declare destructiveHint=false and idempotentHint=false, so the description carries the behavioral burden and does add real value: atomic queueing, per-video charge receipts and failure refunds, ~30–90s polling latency, forced-audio rejection on h3-max, and the Veo retirement cutoff. However, most of the volume is pricing/marketing detail rather than operational behavior (no mention of concurrency limits, what happens to partial batch failures, or how long assets persist), so it is strong but not exhaustive.

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 correctly: the first two sentences cover the core action, batching, and polling. But the body balloons into a multi-tier credit price list per model and per resolution, which is far more than an agent needs to select and invoke the tool and buries the operational rules (source-image priority, upload path) mid-document.

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 20-parameter, 7-model generation tool with no output schema, the description explains the return shape (taskId, batchId, taskIds, tasks), the correct follow-up polling path per count, billing/refund semantics, and input-source prerequisites. An agent has everything needed to call this 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 20% schema description coverage across 20 parameters, the description compensates heavily: it constrains `duration` per model (including Veo's exact 4/6/8 snap behavior), documents count semantics, sourceImage vs legacy sourceImageUrl vs characterId priority, endImage as tail frame, HTTPS-only rules for sourceVideo/referenceVideos/referenceAudios, and resolution-dependent pricing. Only aspectRatio and the projectId/sessionId plumbing go unaddressed.

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

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

Opening sentence states a specific verb and resource with scope: 'Generate 1–4 independent AI videos from one prompt, optionally with a starting image.' It also distinguishes itself from siblings by naming follow-up tools (antix_check_batch vs antix_check_task) and by routing model uncertainty to antix_pick_model.

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

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

Gives explicit when-to-use rules per model ('First pick for fast talking clips and social content with sound', 'Pick it for bulk drafts, animatics, b-roll', 'pick seedance when 1080p matters more than length'), plus when to use batch polling, how to choose sourceImage vs characterId, and a hard when-not with the exact user-facing message for inaccessible chat 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 readOnly/idempotent/non-destructive, and the description adds context beyond them: no credits are spent, the data is a mirror that may lag the Atelier, and logos/customFonts[].url are ready-to-use https URLs that must not be re-derived. That is real behavioral disclosure, not a restatement of hints.

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

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

Front-loaded with the resource and its contents, then the trigger, then the failure mode and caveats — a good ordering. Slightly long for a zero-parameter read tool; the 'never invent a brand color, font or logo' sentence partially repeats the preceding exists: false instruction.

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

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

With no output schema, the description carries the return-value burden and does it: it names the key fields, the empty-state signal (`exists: false`), the URL format, and the staleness caveat. An agent can call it and interpret the response without further information.

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

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

There are zero input parameters, so the baseline of 4 applies; nothing needs documenting in the schema. The description instead documents the response keys (`exists`, `logos`, `customFonts[].url`), which is useful but belongs more to output semantics than to parameter meaning.

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

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

Specific verb (read) plus resource (this user's saved brand kit) with the contents enumerated: palette, font families, logo files, font files. No sibling tool covers brand-kit retrieval, and the description makes the boundary obvious against the many generation/set-* siblings.

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

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

Gives an explicit trigger ('Call it BEFORE you design, illustrate or write anything branded'), covers the negative case (exists: false → say so plainly and ask for colors/fonts), and adds a staleness caveat about the mirror. Both when-to-call and what-to-do-on-empty are spelled out.

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

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

No annotations are provided, so the description carries the burden, and it does disclose the return shape (balance, plan name, dailyFreeRemaining, purchase URL). For a zero-parameter read it omits little of consequence — no mention of caching or rate limits, but risk is inherently low and the 'Get' framing plus enumerated outputs implies a safe read.

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

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

Three sentences, no waste: purpose first, triggers second, return contents third. Each sentence adds information an agent needs and none restates 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, the description must enumerate what comes back — and it does, including the actionable purchase URL. Combined with the trigger conditions, an agent has everything needed to decide when to call and interpret the result.

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

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

The tool takes zero parameters, so the baseline is 4; the description correctly says nothing about parameters and instead spends that space on return values, which is the only semantic content available.

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

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

States a specific verb and resource — 'Get the user's current AIGE credit balance' — plus the two adjacent data points (subscription plan, daily-free allowance) it returns. No sibling tool does anything similar, so the agent can immediately separate this from the many generation/deck tools.

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

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

Gives three explicit triggering conditions: failure with INSUFFICIENT_CREDITS, a direct user question about credit count, and proactively before queuing many generations. This is exactly the when-to-use guidance that most definitions omit.

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 (read-only, idempotent, non-destructive), and the description adds substantial context beyond them: previews are rasterised approximations with specific simplifications (glass/blur, pan-zoom, exotic gradients), `fidelity.exact=false` signals approximation, preview URLs expire on a 14-day cleanup while `exportUrl` is permanent, and `knownDesignVersion` lets unchanged decks skip re-rendering. This is materially useful behavior an agent would otherwise have to infer.

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 front-loaded with the mode split and the primary capability, then layers caveats in a defensible order. It runs long with heavy bold emphasis and some density around export/preview URL lifetimes, but nearly every sentence carries an operational constraint 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?

With seven parameters and no output schema, the description carries the burden of describing the response shape — per-slide preview URLs, copy headlines, paid-background flags, and a fidelity report — and it also explains the durability of `exportUrl` versus ephemeral previews. Nothing an agent needs to call this correctly and interpret the result is missing.

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

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

Schema coverage is already 100%, yet the description still adds semantics the schema cannot: `deckId` omitted flips the tool into list mode, `knownDesignVersion` suppresses re-rendering when unchanged, and `slideIds` re-renders only the edited slides for cheap polling. That is interaction-level meaning rather than a restatement of field descriptions.

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

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

The description names a specific verb and resource — 'Read one of the user's Instagram carousel decks (or list them all)' — and immediately flags the distinguishing feature: server-rendered slide previews. The dual list/detail mode is stated in the first sentence, so an agent can separate it from siblings like antix_export_deck or antix_get_instagram_audit without inspecting 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 explicit routing rules: omit `deckId` to list newest-first, pass `deckId` for the full deck, and use `antix_export_deck` when an actual file is needed for a scheduler, uploader or download. It also gives a hard negative ('do not promise posting to Instagram') and a recovery rule for `previewStatus:"partial"` — call again, don't assume failure.

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 no annotations, the description does substantial work: it discloses the 200-item cap per call, that the newest items return as inline image previews, and that MCP Apps hosts render a browsable gallery panel with filter/load-more/post actions. It omits ordering guarantees, whether results are strictly scoped to the calling user/workspace, and any auth or rate-limit 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?

Front-loaded with the core purpose, followed by return shape, filter, triggers, and UI behavior — a sensible ordering. All six clauses carry information, though the gallery-panel sentence could be trimmed without losing call-critical detail.

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 annotations and no output schema, the description still describes the returned fields, the result cap, and host-rendered UI side effects, which is most of what an agent needs. The unexplained `projectId` filter and vague cursor pagination are the remaining holes for this zero-required-param read 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 0%, so the description must carry parameter meaning. It explains `type` ('image' or 'video') and constrains `limit` via 'up to 200 items per call', but `cursor` is only hinted at through 'load more' and `projectId` is never mentioned at all — an agent would not know they can scope history to a project.

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

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

States a specific verb and resource — 'Get the user's recent AIGE generation history (images and videos)' — plus the scope (per-user, recent) and item contents (prompt, result URL, thumbnail). No sibling in the list covers generation history, so an agent can route here without ambiguity.

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

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

Gives concrete trigger phrasings ('show me my recent generations', 'what was that prompt I used yesterday') and downstream intents (remix/post a previous generation), which is clear positive guidance. It never states when NOT to use it or names an alternative sibling (e.g. antix_get_post, antix_list_projects), so it falls 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 only declare readOnlyHint=true; the description adds substantial context beyond that — no scraping, no analysis, no credit spend, the response carries an openUrl for running a fresh audit, and it explains host-dependent rendering (inline insights panel on MCP Apps hosts, markdownEmbed elsewhere). That is exactly the operational detail an agent needs to set expectations with the user.

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 read-only framing and what is returned, then routing rules, then boundaries, then rendering. Every sentence carries distinct information — no filler or 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?

There is no output schema, so the description must describe returns — and it does, listing the audit fields, openUrl, and markdownEmbed. For a zero-required-parameter read tool this is close to complete; only the shape of the list mode (what an account entry looks like) is left implicit.

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

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

Schema description coverage is 100% and both parameters are already documented, including the omit-to-list behavior. The description restates the handle semantics but adds no format or behavior detail beyond the schema, 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 ('READ-ONLY Instagram analytics: the latest account audit the AIGE growth agent produced') and enumerates the payload (overall score, per-area findings with severity, recommendations, suggested bio). It also distinguishes itself from a fresh audit, which no sibling tool provides, so the agent can route correctly 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?

Explicit both ways: 'Omit `handle` to list every account... pass a handle for that account's full audit.' It adds natural-language triggers ('show my Instagram analytics', 'how is my account doing') and an explicit when-not ('This tool never scrapes, never analyzes... a FRESH audit runs in the AIGE app').

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, so the safety profile is covered and "FREE and read-only" is redundant. The description earns credit by disclosing semantics beyond annotations: the meaning of each status/followUp state, that a skipped item was NOT sent, and that handoff_ready posts were not published by AIGE. It says nothing about error behavior for an unknown postId or any rate limits.

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

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

One dense run-on paragraph mixing return fields, status interpretation and handoff rules, with nested quotes that are hard to scan. Front-loading is good (it starts with what is returned), but the parenthetical about `threads.extras.quotePostId` belongs to another tool and dilutes focus.

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

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

No output schema exists, and the description compensates thoroughly by explaining status, permalink, followUpState/followUps, skipped vs failed, and handoff fields. The only real gap is identifying what postId to pass and what happens when the post is not found.

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

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

Schema description coverage is 0% and the sole parameter postId is only constrained by pattern/length, so the description must carry the meaning. It never says the input is the AIGE post id or where to obtain it; the contrast with `providerPostId` ("the post's id on its platform") only partially implies the distinction.

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 makes clear this returns a single booked post with its status, time, media, permalink and IDs, which distinguishes it from list-style siblings like antix_list_scheduled_posts. It never states the verb plainly ("fetch/retrieve a post by postId"), but the resource and scope are 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?

Explicit guidance: "Use it to confirm a post went live," with the decision rule that only status: published plus a permalink means live, and that in-progress means Meta is still processing. It also prescribes behavior for followUpState values and handoff_ready. It lacks an explicit "don't use this for X, use sibling Y instead" routing statement.

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

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

Annotations already declare readOnly/idempotent/non-destructive; the description adds value beyond that with 'FREE' (no credits consumed) and the consequence that an unlisted font family is refused, which affects downstream calls. It also clarifies the default section set when `include` is omitted. Return format is not detailed, but the content of each section is.

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 identity ('What a carousel can be made of. FREE and read-only.') is front-loaded, then the sections are enumerated compactly. It is dense and slightly long for one paragraph, 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?

With one optional parameter, full schema coverage, and annotations covering the safety profile, the description supplies everything needed to call the tool correctly and to know why. The only omission is any routing note against the similarly named template-listing sibling.

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

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

Schema coverage is 100% and already documents the `include` enum, but the description goes further by explaining what each section yields and why an agent would want it. The one weakness is that the `backgroundEditor` value present in the schema is not covered in the description, though the schema itself explains it and warns it is not needed.

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

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

The description states a specific purpose with concrete detail: it returns a design guide plus selected sections (templates, fonts, backgrounds, edits) and enumerates what each contains. It is clearly distinct from action tools like antix_set_deck_fonts, but it never addresses the potential overlap with the sibling antix_list_carousel_templates even though its `templates` section sounds similar.

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

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

Explicit guidance is given: call it before choosing a typeface or writing a background recipe, because an unlisted family is refused. That supplies a clear trigger condition. It does not state when NOT to call it or how to choose between this and antix_list_carousel_templates, which is the remaining gap.

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

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

Annotations already mark this idempotent and non-destructive, and the description reinforces this with 'FREE and read-only' (the cost claim is new information beyond the annotations). It also discloses the return payload in detail despite there being no output schema. It stops short of saying whether results are paginated or scoped by project.

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

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

Front-loaded with the verb and the free/read-only trait, then the return shape, then the follow-up actions. Dense but every clause carries information an agent needs. The return-shape sentence is long but justified in the absence of an output schema.

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

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

For a simple two-optional-parameter list tool it covers the return values well, which matters since no output schema exists. But it omits the meaning and effect of `limit` and `projectId`, leaving the agent unable to reason about pagination or scoping. 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 0% and neither of the tool's two parameters (`limit`, `projectId`) is mentioned anywhere in the description. The only parameter-like terms discussed — `templateId` and `look` — belong to antix_create_deck, which risks the agent assuming they are inputs here. This is the definition's clearest 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?

Specific verb + resource ('List carousel layouts') plus an explicit breakdown of the two returned collections, `builtIn` and `templates`. This distinguishes it from the neighbouring list/save template tools without the agent needing to open 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?

Clearly routes the agent downstream: pass a templateId (plus a `look` for built-ins) to antix_create_deck, or use antix_edit_deck_slides op apply_template to restyle an existing deck. That create-vs-edit split is genuinely useful. It does not, however, clarify how this differs from the similarly named sibling antix_list_carousel_design_options.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that the operation is FREE, explains how channel availability works, clarifies Instagram Story behavior by accountType, and defines queue-slot timing semantics. It also warns that Meta sign-in cannot run inside chat and must happen in the browser. These are substantial behavioral details beyond structured annotations.

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

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

The purpose and usage rule are front-loaded, and most clauses earn their place because there is no output schema to document return fields. However, the description is a single dense paragraph with multiple nested clauses, so structure could be improved for readability.

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 zero parameters, the description carries the full burden of explaining what the tool returns. It defines the key response fields, accountType semantics, available status, queueSlots format, nextQueueSlot ISO-8601 behavior, and connectUrl usage. That is complete for an agent to call and interpret the tool correctly.

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

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

The tool has zero parameters, so there is no parameter syntax to explain and the baseline is 4. The description appropriately spends its detail on return-value semantics instead.

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

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

The description begins with a specific verb and resource: listing the user's connected Instagram and Threads accounts. It enumerates the channel fields returned and explicitly differentiates the tool from antix_compose_social_post by stating it should be called first. An agent can identify exactly what this tool does 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 an explicit sequencing rule: call this BEFORE antix_compose_social_post because only channels with available:true can be posted to. It also names the alternative workflow for connecting or reconnecting a channel through the browser and connectUrl. Feature-gated guidance for collaborators and tagging is also included.

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 no annotations, the description carries the load and does well: it declares this is a read, discloses the shared bidirectional storage between MCP and the web PromptBar, and explains the side effect that the last image becomes the default img2img reference. It omits any statement about what happens with an empty gallery or auth/permission requirements, which is a minor gap for a read-only 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?

Front-loads the concrete action and the return shape, then adds usage. The 'Why this exists' paragraph is longer than strictly needed for a single-parameter read, but it does carry real behavioral information (gallery reuse, byte-forwarding limitation) rather than pure marketing.

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

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

No output schema exists, and the description compensates by enumerating the returned fields (characterId, characterName, images, count, characterPageUrl). Combined with the usage triggers, an agent has nearly everything needed; only the provenance of characterId 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?

One parameter at 0% schema description coverage, so the description must compensate. It conveys that the parameter identifies a character and that characterId/characterName come back in the response, but never says where to obtain a characterId (e.g., via antix_list_characters) or whether it accepts a name — leaving the only input underspecified.

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: read the user's saved 'Upload' gallery for a character, returning reference image URLs. It implicitly separates itself from antix_add_to_character_gallery (write side) and antix_list_characters (enumerating characters), so an agent can route 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?

Gives explicit triggers ('what references do I have for X', picking an existing reference, checking before adding to avoid duplicates) and names the downstream consumer, antix_generate_image, describing the auto-attach fallback. Alternatives and their selection conditions are spelled out rather than 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?

With no annotations, the description carries the full burden and does so well: it discloses that avatarUrl is auto-attached as the img2img reference, that Firestore is the backing store, that the user maintains avatars via aige.ws, and that avatarCount 0 degrades to text-to-image. It omits ordering, default page size, and any auth/scope notes.

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 and field list are front-loaded, followed by a clearly labeled mechanism section and a trigger list. It is longer than most list tools need, but the img2img explanation genuinely earns its space; the typographic styling is slightly noisy.

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

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

No output schema exists, and the description compensates by documenting every returned field and the meaning of activeCharacterId. The one real gap is the undocumented `limit` input, which leaves an agent guessing about pagination 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?

The single parameter `limit` has 0% schema description coverage and the description never mentions it, its default, or its 1-200 range. All of the prose is about return fields, leaving the only input completely undocumented.

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

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

States a specific verb and resource ('List the user's saved AIGE characters') and enumerates the returned fields, so the agent knows exactly what comes back. It does not differentiate itself from the similarly named sibling antix_list_character_gallery, which is the one plausible source of confusion.

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 four concrete invocation triggers: user names a character, asks 'what characters do I have', wants to verify which avatar will be used for img2img, or is about to generate an image of a specific person/face. No when-not conditions or named alternative tools are given, so it stops short of a 5.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds non-obvious behavioral context: results are valid projectId inputs to specific generation tools, and omitting characterId falls back to the project's mirrored character. It does not disclose ordering, pagination, or default filtering 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?

Three sentences, front-loaded with what it does and immediately followed by triggers and the downstream handoff. The trigger list is slightly crammed into one sentence but no sentence is wasted.

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

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

For a two-parameter read-only list with no output schema, the description supplies the essential missing piece (what the returned ids are for) and the implicit character fallback. The only real hole is parameter behavior, which is addressed in the parameter dimension.

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

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

Schema description coverage is 0% and the description says nothing about either parameter. limit and includeArchived are left entirely to bare schema typing with no guidance on defaults or when to set them, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ("List the user's AIGE work projects") and adds the output contract that matters: it returns valid projectId targets for generation. That distinguishes it from the sibling list tools (antix_list_characters, antix_list_channels) without the agent needing to open 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?

Gives explicit trigger phrases ("put it in my project", naming a project, wanting output live in the same AIGE workspace) and names the downstream tools that consume the id (image, image-batch, video). This is a clear when-to-use plus how-to-continue chain.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context beyond them: results are newest-first, include status, time, permalink, failure reason, follow-up text, handoffNotes, and statusHint, and the call is FREE. It still omits pagination/default limit 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?

Front-loads the resource and return shape, then filter options and cost. It is dense but mostly earns its space; the parenthetical status list is somewhat duplicative of the schema enum, though it adds categorization.

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

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

With no output schema, the description does a good job naming returned fields and ordering. It is less complete on limit/pagination behavior and does not fully explain all status values, but for a simple read-only list it is largely sufficient.

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

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

Schema description coverage is 0%, so the description must document all three parameters. It explains status and channelId as filters but never mentions the limit parameter or its default/max, and its status examples omit enum values such as missed, needs_review, cancelled, and posted_manually.

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 user's Instagram/Threads posts booked through AIGE, newest first, with status/time/permalink/failure fields. It distinguishes this from antix_get_post by describing a collection and referencing shared fields, but it does not explicitly distinguish it from other list/history siblings.

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

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

The description implies usage by explaining that results can be filtered by status or channelId and are read-only/free. However, it gives no explicit when-to-use/when-not guidance or alternatives such as antix_get_history.

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, but the description adds non-derivable behavior: it is deterministic, makes no API call, costs no credits, and is instant. It also discloses the return shape (recommended + suggestedParams pass-through, runnerUp, 'honest' consider caveats such as a model not actually being cheaper) — meaningful for a tool with no output schema, and it points to antix://models for the live guide.

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 claim and the cost/latency reassurance, then cleanly sectioned into Inputs / Returns / Quick map. It runs long and the hardcoded model map partially duplicates what the tool computes at runtime (and may drift from the antix://models resource), but every block is scannable and purposeful.

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 13-parameter tool with no output schema, it supplies the two things an agent most needs: when to invoke it and what comes back (recommended, runnerUp, caveats, notes). Minor gaps remain — quality/resolution/aspectRatio semantics are left to the schema — but nothing blocks a correct call.

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 85%, so the schema already carries most parameter meaning; the description mainly restates a subset (kind, useCase, priorities, needsImg2img, needsAudio, duration, count). It adds some value with concrete free-text useCase examples, but omits quality, resolution, aspectRatio and the three reference-flag params entirely, so it does not extend much beyond the schema.

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

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

States a specific verb and resource — 'deterministic model routing' that returns which image/video model fits and the exact params — and explicitly positions itself upstream of antix_generate_image / antix_generate_video, so it is unmistakable against its siblings. An agent knows this is a decision tool, not a generation 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?

Gives an explicit trigger ('whenever the user hasn't named a model and the choice isn't obvious, or when they ask which model should I use') and an implicit exclusion (if the user named a model, skip it). The 'FREE (no credits, no API call, instant)' note removes the usual hesitation about calling a helper tool, which is exactly the routing guidance an agent needs.

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

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

Adds substantial context beyond the thin annotations: FREE, moderation of caption + hashtags + image bytes with nothing posting on refusal, and the exportSource resolution rule (browser-finalized export wins; server_rendered is a vector approximation that must be disclosed). Annotations only declare idempotentHint=false and destructiveHint=false, so this added detail is valuable. It never explains that idempotencyKey is the retry-safety mechanism despite idempotentHint=false.

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

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

Front-loaded with the core action and the publish target, then layers the details that matter (export resolution, URL reuse, moderation, no Instagram). Dense but nearly every clause carries operational information; the Instagram paragraph is somewhat long relative to its single fact.

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

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

No output schema exists, yet the description explains the key response fields (exportSource values, slideUrls[] ordering and permanence, publish.instagram.available=false) and failure behavior, which is exactly what an agent needs. The gap is input-side: with five parameters and zero schema descriptions, an agent gets no guidance on caption/hashtags/accountHandle/idempotencyKey usage.

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

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

Schema description coverage is 0% across 5 parameters, and the description mentions no parameter by name — caption limits, hashtag count/moderated status, accountHandle, and especially idempotencyKey semantics are entirely undocumented. The only implicit parameter mapping is 'a finished carousel deck' → deckId, which the required field already conveys.

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

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

States a specific verb+resource+destination: 'Publish a finished carousel deck to the AIGORA feed — the only live publish target.' It explicitly distinguishes itself from antix_create_post (moderation pipeline reference) and antix_export_deck (scheduling handoff), and rules out Instagram in bold.

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 when-to-use context ('the only live publish target'), tells the agent what to do with the output (hand slideUrls[] to a scheduler, never re-derive), and names a hard exclusion (no Instagram autopublish). It does not state preconditions such as deck readiness (e.g., antix_check_deck_readiness) or when to prefer antix_create_post instead.

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 only cover destructiveHint/idempotentHint. The description adds the async taskId contract, the account-global rate limit of 6 renders per 5 minutes, the fact that a key-replay counts against it, the cost (free, no credits), the input validation of deck aspect (DECK_ASPECT_UNSUPPORTED rather than letterboxing), the queue-full failure mode, and the fidelity caveat. That is exactly the kind of context annotations cannot provide.

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

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

Front-loaded with the outcome (MP4 saved to the account) and the cost (free), then the async contract. It is dense but every sentence earns its place; the uppercase emphasis and parenthetical asides make it slightly heavier than necessary.

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

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

No output schema exists, but the description fully covers what comes back: a taskId plus durationSeconds, then polling that yields poster, play link and direct .mp4 URL. It also covers the failure path and the fidelity caveat, so an agent can call and follow up correctly without other sources.

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 already 100%, so the baseline is 3. The description adds real meaning beyond the schema: how secondsPerSlide affects the held duration, what transition=fade actually does, that audioUrl is trimmed to the video length, and that reusing idempotencyKey after a failure hands back the same failed task instead of retrying.

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: turns a finished carousel deck into an MP4 saved in the user's AIGE account. It also distinguishes itself from the nearest siblings by name: antix_compose_social_post for actually posting, and antix_check_task for polling the result.

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

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

Explicitly scopes when to use it (render a file and hand it off) and when not to (Instagram/Threads autopublish is NOT available — use antix_compose_social_post). It also names the follow-up step (poll antix_check_task) and the retry procedure after DECK_VIDEO_BUSY.

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

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

Annotations declare destructiveHint=true and idempotentHint=false; the description adds real context beyond them: optimistic-concurrency via expectedVersion, the DECK_CONFLICT failure mode and retry protocol, and the cost ('Free'). It confirms the full-replacement nature of `order` (every slide id required), which is consistent with the destructive annotation. It doesn't say whether existing slide content/ids are preserved or what the response contains.

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

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

Four short sentences, front-loaded with the trigger and the core contract, with no filler. Every clause (order contract, version requirement, conflict handling, cost) 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 destructive reorder with no output schema and six params, the description covers the essentials: what the argument must contain, the concurrency precondition, the failure mode and recovery, and that it costs nothing. The unmentioned params are optional and self-describing 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?

Schema coverage is only 33%, and the description compensates for the two highest-risk params: `order` must contain every slide id in the desired sequence (a non-obvious full-replacement contract), and `expectedVersion` is mandatory with a stale value failing before any work. The three ancillary params (locale, accountHandle, projectId) are left entirely to the schema, so it is not complete.

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 ('Put the slides in a new order') and pins down the exact payload semantics (pass every slide id, in the order wanted), which separates it from the layout/edit siblings by implication. It never names antix_apply_deck_layout or antix_edit_deck_slides to draw the boundary explicitly, so it stops short of a 5.

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

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

Gives concrete trigger phrasings ('move slide 4 to the front', 'swap slides 2 and 3') and recovery guidance for DECK_CONFLICT (re-read and repeat the same intended change). No when-not guidance or named alternative for cases where the agent may wrongly reach for this tool instead of a layout tool.

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

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

Annotations already declare destructiveHint=false and idempotentHint=false; the description is consistent with those and adds the useful 'FREE' cost signal plus a note on what the snapshot covers (zones, typography, brand elements, slide roles). It omits what happens on name/templateId collisions, whether an existing template is overwritten, and whether the source deck is modified.

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

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

Two sentences, front-loaded with the action and effect, with no wasted wording. The standalone 'FREE.' sentence is slightly abrupt but delivers a genuinely useful fact.

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 mutation with no output schema and zero schema descriptions, the description is too thin: it does not explain parameter roles, duplicate/collision behavior, or what the caller gets back (e.g., a templateId). The consumer relationship to antix_create_deck is the only completeness asset.

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

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

Schema description coverage is 0% across five parameters, so the description carries the full burden, yet it explains none of them. It hints only indirectly at deckId ('existing canonical carousel deck') and never clarifies the roles of name, projectId, templateId (create vs. overwrite?), or 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: 'Snapshot an existing canonical carousel deck as a reusable template.' It also names the downstream consumer (antix_create_deck), which helps situate it among siblings. It does not explicitly contrast with antix_list_carousel_templates, so it falls short of full sibling differentiation.

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 intent is implicit: use it when you have an existing deck whose design should be reused. There is no explicit when-to-use/ when-not guidance, no prerequisites (e.g., deck must be canonical/ready), and no mention of the alternative of choosing a pre-existing template via antix_list_carousel_templates.

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 behavior beyond the thin annotations: the pin persists across sessions, surfaces in the @-mention picker on aige.ws, and mimeType is inferred when omitted. What's missing is duplicate behavior — idempotentHint is false, so re-pinning likely creates a second entry, but the description never warns about that or about any limits on memory size.

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

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

Front-loaded with purpose, then triggers, then exclusion, then Inputs/Returns headers — an agent can stop reading after sentence two and still call correctly. It is somewhat longer than necessary, with the Returns sentence partly duplicating what a caller would verify anyway.

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 compensates by naming the return fields (fileId, label) and telling the agent to confirm the pin to the user. Combined with the stated persistence and picker visibility, nothing important about the call outcome is left unknown.

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

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

Schema coverage is 100%, so the schema already labels every parameter; the description still adds value by stating the URL may be an HTTPS or data URL (the schema only says HTTPS) and by grouping constraints such as tags up to 8 and mimeType inference. It does not explain format expectations for label or name beyond what the schema's examples already give.

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

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

Opens with a specific verb and resource: 'Pin a FILE ... to the user's long-term AIGE memory', and enumerates the asset types covered. It also explicitly contrasts itself with antix_add_to_character_gallery, so an agent can select it over that sibling without inspecting either schema.

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

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

Gives concrete user phrasings that should trigger the tool ('remember this reference', 'save this for later') plus a clear when-not with the named alternative for character reference images. The routing decision is fully specified.

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 readOnlyHint=false, idempotentHint=true, destructiveHint=false; the description adds genuinely new behavioral facts — FREE/no credits, creates nothing new, image is queued into the board inbox and materializes asynchronously the next time Canvas is open. That async caveat plus the instruction not to claim it is on screen is exactly the context annotations cannot convey.

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

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

Front-loads the core action, then constraints, then cost, then the async caveat and user-facing instruction. Dense but every sentence carries an operational fact; nothing is filler.

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

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

Complete for a zero-required-param mutation with no output schema: it covers cost, idempotency implications, accepted inputs, refusal cases, delivery timing, and what to tell the user. An agent can call this and set expectations correctly with no further lookup.

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

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

Schema description coverage is 100%, and the schema already documents the either/or rule for url vs historyId and the 'omit to let whichever board opens first claim it' behavior for projectId. The description mostly restates this; its only marginal addition is reiterating that url must be an AIGE storage host, which the schema also states.

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 (place/send) and resource (image onto AIGE Canvas board) with scope: 'an image this user ALREADY generated in AIGE'. It distinguishes itself from sibling generation tools by emphasizing it creates nothing new and moves existing output, so an agent can tell it apart from antix_generate_image or the deck tools.

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

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

Explicit conditions and exclusions: pass EITHER historyId (from antix_get_history) OR url, never both; images only; video generations and non-AIGE-host URLs (including expiring provider links) are refused. It also names the upstream tool that supplies the id, which routes the agent correctly.

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

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

Goes well beyond the destructiveHint=true / idempotentHint=false annotations: names the exact storage path overwritten (users/<uid>/characters/<characterId>/avatar.jpg), states the previous avatar is returned but not preserved, and notes the change is immediately visible on the AIGE web page. It also discloses the client-side limitation that motivates the design.

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 purpose and usage examples, then uses bold-labelled Inputs/Side effects/Returns sections that scan well. It is longer than strictly necessary — the 'Why this matters' client-limitation discussion is useful but the longest single block, and a little of it could be trimmed without losing agent-relevant 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?

No output schema exists, but the description enumerates the return fields (characterId, characterName, avatarUrl, previousAvatarUrl, characterPageUrl). Combined with the documented side effects and the two documented params, an agent has everything needed to call this correctly and report the result.

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

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

Schema coverage is 0% and the schema provides no descriptions, so the description must carry the load — and it does. It documents both parameters: characterId sourced from antix_list_characters, and image accepting either an HTTPS URL (with the recommended acquisition path) or a base64 data URL.

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 ('Change the saved AIGE character's avatar') and immediately defines what an avatar means operationally — the img2img reference auto-attached when the characterId is passed to antix_generate_image. That definition cleanly separates it from antix_create_character, antix_add_to_character_gallery, and antix_generate_image in the sibling list.

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

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

Gives explicit triggering conditions with three natural-language user utterances ('use this image as Aurora's new face going forward', etc.) and explains the correct alternative workflow when chat bytes aren't forwarded — upload to aige.ws/r or supply any public URL, then call this tool. The when-to-use boundary against per-generation image passing is stated outright.

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

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

Adds substantial context beyond the destructiveHint/idempotentHint annotations: disallowed font families are refused server-side, text re-fits after the change, the call is free, and the optimistic-concurrency contract (expectedVersion required; DECK_CONFLICT means re-read and repeat) is documented. That is the exact failure-mode guidance an agent needs for a mutating 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?

Front-loaded trigger sentence, then scope, then the supporting constraint, then the concurrency contract. Four compact sentences with no filler; the refusal and DECK_CONFLICT rules are stated in the fewest words that make them actionable.

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 destructive mutation with no output schema, the description covers the intent, scope, validation source, side effect (text re-fitting) and the conflict-recovery path. What remains missing is what the three ancillary context params (locale, accountHandle, projectId routing) mean and whether prior fonts can be restored.

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 17% schema coverage across 12 params, the description carries the load and does so for most of them: heading/body/accent, slideId scoping, headingWeight/headingItalic/headingUppercase, and expectedVersion semantics. It leaves locale, accountHandle and the deckId/projectId relationship unaddressed, so coverage is strong but not complete.

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: set heading, body and accent typefaces for the whole deck or a single slide via slideId, plus heading weight/italic/capitals. This is clearly differentiated from siblings like antix_set_text_style and antix_set_slide_colors, which operate on different attributes.

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 concrete user-utterance triggers ('change the font', 'use a serif for the titles', 'match my brand fonts') and an explicit precondition: families must come from antix_list_carousel_design_options or be refused. Scope selection (whole deck vs slideId) is spelled out. It does not explicitly exclude attribute siblings such as antix_set_text_style, so it falls short of a full when/when-not map.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description adds real context beyond that: partial-update semantics ('Only the slots you pass change'), the required expectedVersion with a named failure mode and retry procedure, and that the call is free. The conflict-retry guidance slightly softens the non-idempotent hint but is coherent once a fresh version is re-read.

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 trigger conditions, then slot definitions, then scope, then versioning and cost. It is dense but every sentence carries new information; there is no restatement of the title or filler.

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