AdGPT

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

No annotations, so the description carries full burden. It discloses one genuinely non-obvious trait: the returned session token is adopted automatically and all later calls run as that user. However, it says nothing about side effects of register (creates an account) or whether updateProfile overwrites fields, which matters for a tool with mutations.

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

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

Three tight sentences, front-loaded with what the tool reads/writes before the auth note and action list. Little waste, though the action enumeration repeats the schema enum.

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 six-action dispatcher with free-form params, no annotations, and no output schema, the description offloads parameter discovery to adgpt_capabilities, which is a reasonable strategy. Still missing per-action behavioral detail and return-value expectations for a tool this complex.

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

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

Schema coverage is 50%; the free-form `params` object has no per-action shape in the schema. The description compensates by pointing to adgpt_capabilities with the operationId, but it does not itself describe what params register/login/updateProfile expect. Listing actions merely restates the enum.

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 specific resources it reads (profile, credit balance, in-flight generations) and the update case, then enumerates all six actions (register, login, me, credits, activeGenerations, updateProfile). An agent can identify the tool's scope without opening the schema, though the six-in-one dispatcher nature means no single verb is sharp.

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 sequencing guidance — 'No account yet? Start with register (or login)' — and routes the agent to adgpt_capabilities for per-action parameters. It lacks explicit when-not-this-tool exclusions against the many sibling tools, but the auth-first context is clear.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one genuinely useful behavioral trait — fetchDetails costs 5 credits — but for a tool containing create/update/delete it omits any mention of destructive/reversible semantics or auth requirements.

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 front-loaded sentences with the action list and cost caveat placed early. The action list is effectively repeated (once narratively, once as a formal 'Actions:' list), which is minor redundancy but slightly wasteful.

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

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

For a polymorphic dispatcher with nested params, no output schema, and no annotations, the description correctly offloads parameter discovery to adgpt_capabilities and flags the credit cost. It is broadly sufficient, though it never describes what list/get/fetchDetails return or the mutation risk of the write actions.

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

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

Schema coverage is 50%; the 'action' enum is self-documenting and the 'params' field explicitly defers to adgpt_capabilities, which the description reinforces. Beyond that deferral it adds no per-action parameter detail, so it neither compensates for nor significantly exceeds 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 ('Manage') and resource ('brands') and enumerates every operation (list, get, create, update, delete, fetchDetails) the tool supports. The brand resource is distinct from all siblings, so an agent can select it 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?

The enumerated actions imply when each is used, and it usefully routes the agent to adgpt_capabilities for per-action parameters. However it gives no explicit when-to-use/when-not guidance and no comparison against alternative sibling tools.

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

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

With no annotations, the description carries the full load and delivers real behavioral context: exact default asset counts, the fact that tier changes credit cost and UGC quality but not asset counts, and that regenerateAsset consumes credits only. It omits auth/permission requirements, async/status behavior, and what deleteFromLibrary does to already-downloaded assets.

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 defaults, then tier semantics, then the action list — a sensible ordering. The restatement of the action enum that the schema already supplies is mild redundancy, but the surrounding text is dense and information-bearing.

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 seven-action tool with no output schema and no annotations, this covers the essentials: what gets generated, how tiers affect cost/quality, and where to find action parameters. It does not cover response shape, polling/status flow, or credit magnitudes, but the pointer to adgpt_capabilities fills a large part of the 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?

The description adds meaning to several enum values ('Re-render one image', 'remove a campaign from your library', 'download'), which the bare enum does not convey. But the entire 'params' object is delegated to adgpt_capabilities, so at 50% schema coverage the description resolves only the action parameter and leaves the substantive inputs opaque.

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?

Uses a specific verb+resource ('Generate and manage Full Campaigns (FC)') and enumerates the three input modes (product URL, manual product, text-only) plus the default asset bundle. It implicitly differentiates from siblings like adgpt_single_asset and adgpt_ugc by describing the full-bundle scope, but it never names or contrasts them explicitly.

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

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

The action enum is surfaced as a usage menu and the description points to adgpt_capabilities for per-action parameters, which is useful routing. However, there is no explicit when-to-use guidance relative to siblings (e.g. single asset vs full campaign vs social), and no prerequisites or exclusions are stated.

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

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

With no annotations the description carries the full burden, and it does disclose meaningful behavior: the describe mode returns input schema, auth requirements, credit cost, and async behavior — the exact things an agent needs before invoking a costly operation. It stops short of stating that the tool itself is a safe read-only lookup and doesn't describe the search-result shape.

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

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

Two sentences, zero filler. The dual-mode purpose is front-loaded and the parameter routing follows immediately, so the highest-value information is read first.

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, and the description compensates by listing what the describe mode returns; for the search mode it only implies the matched fields. For a two-optional-parameter discovery tool that is close to complete, with only the search result shape 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%, so both parameters are already documented, and the description largely restates which parameter selects which mode. It does add the matching-field hint 'name / domain / path', but that slightly conflicts with the schema's 'operationId, uri, title, or domain', so it earns no bonus over the baseline 3.

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

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

States two specific verbs (search, describe) on a specific resource (AdGPT operations) and enumerates exactly what each mode yields, including schema/auth/cost/async detail. This is unmistakably the meta-discovery tool among the adgpt_* action siblings, so an agent can place it without opening the schema.

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

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

Explicitly routes between the two modes: 'Use `operationId` to describe a specific operation, or `query` to search by name / domain / path.' That tells the agent which parameter to reach for and when, though it never states the broader when-not condition (e.g. skip this tool if you already know the operation) or names any alternative.

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 full burden, yet it discloses nothing about permissions required, rate limits, or the side effects of mutating actions like createFeed and updateProduct. It only notes the supported operations without their behavioral implications, leaving the agent to guess about safety and reversibility.

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

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

The description is a compact two-sentence block that front-loads the resource and then lists the actions. There is one small redundancy (listing actions before also saying 'read and update products'), but no major padding.

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

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

For a multi-action tool with no annotations and no output schema, the description covers the essential operation surface and points to adgpt_capabilities for parameter details. However, it omits return behavior, error handling, and safety implications for mutations, leaving material gaps for an agent.

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

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

The input schema defines the action enum and a free-form params object with 50% schema description coverage. The description adds no parameter-level semantics beyond the action names, instead deferring to adgpt_capabilities. Baseline 3 is appropriate given the partial schema description and the explicit deferral mechanism.

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

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

The description clearly states the resource (product feeds and items) and enumerates the supported actions (import a feed, poll import status, read and update products). It's specific about what the tool does, though it doesn't explicitly differentiate itself from the sibling upload_product_image tool which also touches products.

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 actions are listed with brief context (e.g., 'poll import status'), which implies when each would be used, but there are no explicit when-to-use or when-not-to-use rules relative to alternatives. The pointer to adgpt_capabilities for parameters adds some operational context but does not guide tool selection.

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

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

With no annotations, the description carries full behavioral burden; it does add useful traits (version keep/discard/revert semantics, normalized overlay geometry, voice/emotion/gender narration options, language-dependent extras). However, it never distinguishes read actions from mutations, says nothing about async job behavior (a likely trait given the adgpt_job sibling), reversibility of deletes, or auth requirements.

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 statement is front-loaded, but roughly half the text is a verbatim re-listing of the 30-value enum already present in the schema, which earns little. The grouping into plain image/video vs inAction families is the only added value from that enumeration.

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

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

For a 30-action dispatcher with no annotations, no output schema, and a passthrough params object, the definition gives a reasonable map plus a discovery mechanism. It still leaves the agent without per-action effect, output, or async expectations, so it is adequate but clearly short of 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?

The schema is a passthrough (action enum + free-form params object) at 50% coverage, so the description should compensate. It does the next-best thing by telling the agent to call adgpt_capabilities with the operationId for per-action parameters, but it explains no parameter semantics itself, so it is only partially compensating.

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

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

Opens with a specific verb/resource pair ("Post-generation editing of image and video assets") and enumerates the concrete capability families (prompt edits, overlays, narration re-dub, version control, share links). It is distinguishable from resize/single-asset siblings, though the 30-action dump blurs the core purpose more than it clarifies.

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 implicitly scopes in-action editing ("inAction* works on completed UGC in-action ads"), which hints at the boundary with adgpt_in_action, but never states when to pick this tool over adgpt_single_asset, adgpt_image_resize, or adgpt_ugc. The only explicit guidance is a discovery pointer, not a selection rule.

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 it does disclose the key trait that this is read-only and that mutations live elsewhere. However, it says nothing about auth requirements, rate limits, pagination, or the shape of returned data, so behavioral coverage is only partial.

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 status statement followed by scope and routing guidance; three tight sentences. The 'Actions: current, history, performance' line mildly duplicates the schema enum but earns its place as scannable navigation.

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

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

With no output schema and no annotations, the description does a reasonable job: it establishes read-only behavior, lists actions, and offloads parameter detail to adgpt_capabilities. It stops short of describing return values or the params object's shape, which the agent must fetch elsewhere.

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

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

Schema coverage is 50%. The description restates the three enum values already present in the schema and defers the meaning of the free-form params object to adgpt_capabilities, adding little beyond the structured fields.

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

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

States a specific verb+resource: read-only status of a campaign's live ads, and enumerates the three sub-actions (current, history, performance). It distinguishes the read path from the write path by noting mutations happen in the web app, though it does not explicitly contrast itself against similarly-named sibling 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?

Clearly scopes usage: this tool reads go-live status, while starting/renewing/stopping happens in the web app, and it tells the agent to consult adgpt_capabilities for action parameters. Missing an explicit statement of when 'current' vs 'history' vs 'performance' should each be chosen.

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. It helpfully discloses the async batch nature and a concrete cost cadence of 25 credits per size, but says nothing about permissions, whether existing renditions are overwritten, or 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?

A single dense paragraph, front-loaded with the core purpose, followed by the operations and a routing instruction. Every clause (cost, async, action names, capabilities pointer) contributes; no filler.

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

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

Given a complex multi-action tool with a nested free-form params object and no output schema or annotations, the description covers purpose and defers parameter detail to adgpt_capabilities — a defensible pattern. It still omits return-shape expectations, pagination for batch status, and sibling disambiguation, so it is only minimally adequate.

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

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

Schema coverage is 50%, with a free-form `params` object and only the action enum documented. The description mitigates this by mapping each action name to a short gloss and explicitly directing the agent to adgpt_capabilities with the operationId, but it does not itself add per-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?

States a specific verb+resource ('subject-preserving platform-size renditions of your generated image ads') and enumerates the five operations it supports. An agent knows what the tool family does, though the multi-action shape blurs a single crisp purpose and none of the siblings are named for disambiguation.

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 action list implies when each operation applies (presets catalog, batch status, campaign renditions), which is partial usage guidance. However, it offers no explicit when-to-use/when-not-to-use versus siblings like adgpt_edit_creative or adgpt_single_asset, leaving the routing decision 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?

With no annotations, the description carries the full behavioral burden. It discloses useful traits: required prior resource reads, a Pro-plan entitlement gate for in-action/commercial output, that parameters must be resolved through adgpt_capabilities, and that wizard state is persisted. It does not distinguish read actions (plans, getWizardState, voicePreviewStatus) from mutating ones (saveWizardState, tagScript), nor mention side effects, cost, or async polling behavior for the generate/voice actions.

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?

Prerequisites and the plan gate are buried mid-paragraph rather than front-loaded, and the 'Actions: ...' sentence repeats the input schema enum verbatim, which earns no credit per the structured-data rule. The content is dense and mostly necessary, but the ordering and the redundant enum listing cost it a point.

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?

This is a nine-action multiplexer with a generic passthrough `params` object, no output schema, and no annotations, so the description has to do a lot. It covers prerequisites, entitlement, and parameter discovery, which are the essentials for calling it, but nothing describes per-action intent or return shape, leaving the agent dependent on adgpt_capabilities for every action's meaning.

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 50%: `action` is fully enumerated in the schema, but `params` is an opaque free-form object. The description compensates in exactly the right way by telling the agent to call adgpt_capabilities with the operationId to learn an action's parameters, which is the only real path to correct `params` values. It adds no per-action parameter hints of its own, so it is adequate rather than rich.

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 gives a specific verb+resource framing: a 'talking-head / UGC-in-action wizard for a SAC campaign' that generates scripts, strategies, per-character plans, previews voices, tags scripts, and persists wizard state. It names the concrete capabilities rather than restating the title, so an agent knows what class of work this handles. It does not explicitly contrast itself with the sibling adgpt_ugc tool, which is the most likely source of confusion in this cluster.

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

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

It states concrete prerequisites ('Read adgpt://pipeline/characters and adgpt://pipeline/voices first'), a gating condition ('In-action and commercial videos need a Pro plan or higher'), and a discovery route ('Call adgpt_capabilities with the operationId to see an action's parameters'). That is real when-to-use guidance. It lacks an explicit when-not or a direct comparison against adgpt_ugc, keeping 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?

With no annotations, the description carries full burden and does well: it discloses the blocking cap ('up to waitSeconds, max 25'), the callAgain=true continuation signal, and the notable side-effect fact 'Never charges credits.' It omits auth/permission requirements and rate-limit behavior, so not a 5.

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

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

Three tight sentences, front-loaded with the core action and followed by the invocation recipe and the credit guarantee; no filler.

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

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

For a polling tool with no output schema, the description conveys the key return signal (callAgain) and the blocking semantics, which is what an agent needs to drive the loop. It doesn't sketch the eventual result payload, a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning by specifying that operationId is a 'status' operation obtained from a create call's job handle and that params are path/query params like {id}, which the schema alone doesn't explain.

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 ('Poll a long-running generation to completion') and ties it to the create-call workflow via the job handle, which cleanly separates it from the create-style siblings in the 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?

Explains how to use it (pass the status operationId from a create call's job handle) and the re-invocation loop ('invoke again to keep waiting'), giving clear context. It doesn't explicitly name an alternative tool or state when not to use it, 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?

With no annotations, the description carries the full burden and does disclose the two most non-obvious traits: the operation is asynchronous (poll adStatus) and adCancel refunds an in-flight clone. It omits auth/permission requirements, side effects of re-ingesting the same ad, and what adAssets/adStatus actually return.

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

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

Front-loaded with the core purpose and workflow, and every sentence carries information. The explicit re-listing of all seven action names is redundant with the schema enum, which is the only real waste.

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

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

For an action-dispatch tool with nested params, no output schema, and no annotations, the description covers the lifecycle, the refund behavior, and where to find per-action parameters. It leaves gaps around return values/status states, but the capabilities-tool pointer covers the biggest risk area.

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

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

Schema coverage is 50% and 'params' is an opaque free-form object, so the description's pointer to adgpt_capabilities with the operationId is genuinely useful. However, it supplies no per-action parameter meaning itself and largely repeats the action enum already present in the schema.

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

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

The description names a concrete verb+resource ('Clone any existing ad') and lays out the full ingest → analyze → generate pipeline, which is specific enough to distinguish this from generic creative tools. It never explicitly contrasts itself with siblings like adgpt_ugc or adgpt_edit_creative, 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?

It gives real sequencing guidance: ingest first (URL or upload), then analyze, then generate, poll adStatus for progress, and adCancel to abort/refund. Usage context is clear, but there are no explicit 'when not to use this' conditions or named alternatives for the sibling tools.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: 'credits charged upfront, failed items auto-refund' and the confirm sub-payload mechanic. It still omits permission requirements, whether cancel is reversible, and rate/credit-limit behavior, so it is only partially transparent for a mutating batch job 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 core purpose, but the middle is an extremely dense run-on of parenthetical asides and dash-separated clauses. The per-asset-type counts (6 image ads, 4 video ads, etc.) and the flat 14-item action list are useful but heavy, making it harder to scan 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?

For a 14-action batch tool with no output schema and no annotations, the description covers asset counts, the create/confirm flow, and bulk credit/refund behavior, and points to adgpt_capabilities. It remains incomplete on per-action parameters and return shape, but the capabilities pointer mitigates that 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 50% and the two params are action (enum, but enum values have no descriptions) plus an untyped params blob. The description enumerates and loosely groups actions (bulk* actions) which adds meaning over the bare enum, but it explicitly offloads field detail to adgpt_capabilities, so it compensates only partially.

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

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

States a specific verb and resource ('Generate a BATCH of premium creatives of one asset type (SAC)') and contrasts it with the bulk-order mode and bulk* actions. It also implicitly differentiates from multi-asset siblings (adgpt_campaigns) via the 'one asset type' framing, though it never names a sibling explicitly.

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

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

Provides workflow sequencing guidance ('create → (customize) → confirm', 'pricing / eligibility quote the credit cost first') and notes that interactive UGC uses confirm sub-payloads. However, it gives no explicit when-to-use vs when-not or which sibling to pick for adjacent tasks; usage is only implied through action ordering.

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 and no output schema, the description carries the full burden, and it does add useful non-obvious context: the multi-action dispatch model, the connect-first prerequisite, and the delegated-parameter pattern via adgpt_capabilities. It does not disclose the write/irreversibility profile of createAds or an OAuth flow for connectAccount, nor any auth or rate-limit behavior, so the safety picture is only partially covered.

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 connect/publish framing, but the first sentence is a dense run-on mixing two platforms plus reads and taxonomy. The second sentence re-enumerates all eight action values, which duplicates the schema enum and is redundant text. Functional, not wasteful enough to be bad, but not tight.

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 eight-action dispatcher with no annotations and no output schema, the description is reasonably complete: it states the scope, the connect-first prerequisite, and explicitly routes parameter discovery to adgpt_capabilities, which matches the schema's own pointer. The main remaining gap is that per-action behavior and output shape are entirely offloaded, requiring a second call before the agent can act confidently.

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

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

Two parameters at 50% coverage; the critical 'params' object is essentially undocumented beyond 'see adgpt_capabilities', so the description does not compensate for the gap. The action list in the description merely restates the schema enum rather than adding meaning. Guidance points the agent elsewhere, which is a valid design but adds little over the structured fields.

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

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

The description names concrete resources and verbs across the two platforms it fronts (Facebook ad-account connect/check/exchange-token, TikTok regions/languages/campaigns/ad-groups/create-ads), so an agent knows what class of operations live here. It is a dispatcher, so the purpose is a bundle rather than a single verb+resource, and overlap with siblings like adgpt_campaigns is not resolved. Still clear enough to route above the level of a vague wrapper.

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 one real prerequisite ('publish to TikTok from an account you already connected in the web app') and a second-hop instruction to call adgpt_capabilities with the operationId for parameters. However, it never says when to reach for this tool versus adgpt_campaigns or other siblings, which matters because several actions (campaign/ad-group reads) plausibly overlap. Usage is implied rather than bounded.

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 supplied, so the description carries the full burden. It usefully discloses a key behavioral trait: action parameters are not in the schema and must be fetched via adgpt_capabilities with the operationId. It says nothing about pagination behavior (implied by 'avatarsPaginated'), rate limits, or the return shape, which leaves meaningful gaps for a no-annotation 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?

Three tight sentences, front-loaded with the purpose and with the disambiguation/navigation guidance following. The list of three sibling tools in the parenthetical is slightly verbose but earns its place as boundary-setting.

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

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

For a 2-param tool with a nested object, no annotations, and no output schema, the description covers purpose and where to find parameters, but does not describe what a catalog result contains or how pagination works. It is adequate but leaves the agent to discover return structure at call time.

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 50% — the 'action' enum is self-documenting, but 'params' is a free-form object. The description names the two actions (avatarsPaginated, voices) and correctly points the agent to adgpt_capabilities for their parameters, which adds value, though it delegates rather than explaining param semantics directly.

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 ('Browse') and resource ('UGC presenter avatar and voice catalogs'), then explicitly draws the boundary against siblings by noting that UGC videos are generated via adgpt_campaigns, adgpt_single_asset, and adgpt_in_action. An agent can distinguish this catalog tool from the generation tools without opening a schema.

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

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

It clearly frames the tool's role (browsing catalogs, not generating videos) and routes the agent to adgpt_capabilities for action parameters. It does not, however, address when to prefer this over other catalog-style siblings such as adgpt_catalog, leaving that choice 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?

With no annotations, the description carries the full burden and does so well: it discloses validation rules (min 100x100px, aspect 1:4–4:1), accepted formats, a 10MB size cap, the storage/mutation behavior, the exact return shape {url,width,height}, and an auth note ('works before login too'). This is unusually rich behavioral context.

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

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

Front-loaded with the core action and information-dense, with each clause carrying a distinct fact (formats, limits, downstream usage, auth). It is a long single paragraph rather than split into scannable structure, but there is little waste.

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

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

For a mutation tool with no annotations and no output schema, the description covers everything needed: input alternatives, validation constraints, formats, size limit, return values, downstream usage, and auth behavior. An agent has all it needs to invoke 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, but the description adds decision value beyond the schema: it labels file_path as 'preferred', presents data_base64 as the alternative, and pairs it with filename based on extension. That guidance on which parameter to choose is not in the schema.

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

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

States a specific verb and resource ('Upload a product photo to AdGPT') with clear scope ('from the local machine'). It is immediately distinguishable from siblings like adgpt_image_resize or adgpt_single_asset, which do different things.

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 usage guidance: file_path is preferred, data_base64 is the alternative that requires filename, and the returned url belongs in user_instructions.uploaded_images when creating a campaign (max 5). It does not explicitly contrast against sibling tools, but the context for correct invocation is clear.

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