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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's added transparency about result shapes per mode, the 'Free' cost signal, capacity limits, examples, thumbnails, and the explicit 'not a sendable contract' warning is strong value beyond structured data. The description also prevents misuse by clarifying that certain outputs are for chooser/discovery and not executable contracts. No contradiction with annotations.

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

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

The description is dense but not wasteful — nearly every clause states a distinct mode or constraint, and the first sentence front-loads the core browsing behavior. That said, the heavy semicolon-separated run-on structure and shorthand such as 'bound fields' and 'FURNITURE' make parsing harder than necessary, so a bit more grouping or bolding would improve 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 an 11-optional-parameter, multi-mode discovery tool with no output schema, the description covers most combinations, expected outputs, and even the follow-up rendering path via create_slide. Minor gaps remain, such as how q interacts with family, what type=schema alone returns, and precise return shapes for search results, but these are relatively small given the tool's complexity.

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

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

The schema leaves several parameters like family, variant, and prior_id without property descriptions, but the description fills those gaps with concrete mode formulas: 'family=<form> -> variant one-liners', 'variant=/prior_id= -> example payload', and 'type=schema + family + variant' for the exact machine-readable contract. It also maps the ambiguous type parameter across schema, widgets, helpers, themes, and brands, adding meaning far beyond the raw schema.

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

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

The description opens with a specific action and resource — 'Browse the PowerPoint slide catalog progressively' — and then enumerates the different browsing surfaces (form overview, variants, search, contracts, widgets, helpers, themes). This makes the tool's purpose distinct from siblings like create_slide, plan_slide, and create_deck, which actually generate presentations.

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 explicit mode-selection guidance: 'No args -> form overview', 'family=<form> -> variant one-liners', 'q=<text> -> ranked search', and it warns that 'type=schema + family' is 'not a sendable contract' while adding variant yields the exact payload contract. It also connects to a sibling for the next step: the theme results 'render via create_slide(form=template_layout, theme_id, data={layout, fills}).' It lacks an explicit global when-not-to-use statement versus alternatives, but the context is otherwise strong.

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

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

The description goes far beyond the annotations: it discloses parallel slide rendering and merge behavior, furniture expectations, dry_run pre-flight with no render/cost, free modes, billing per rendered slide, ignored parameters (force_render/allow_partial), strict_policy rejection behavior, and deck_id==job_id polling. It also explains can_autofix patch recovery, which is behavior not visible from the schema or annotations.

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

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

The description is front-loaded with the core purpose and packs useful information efficiently, with semicolon-joined clauses and clear paragraph breaks. It is dense and somewhat sprawling toward the end ('Also:', 'Polling:'), but for a 17-parameter deck-builder tool the detail is largely earned.

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

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

Despite having no output schema, the description covers the critical output behaviors: pptx_url always returned, dry_run validation manifest, policy failure returning rejected/cost:0, and deck_id==job_id for polling. It does not give a full response shape or explicit worked example, but what an agent needs to invoke and monitor the call correctly 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?

With 88% schema coverage, the schema already carries the baseline, and the description adds value on top: it explains that slides are create_slide intents, that assemble/fork have free/no-retheme semantics, and that deck-level parameters inherit with slide-level wins. It doesn't fully document every parameter (e.g., title, theme_id), but it meaningfully enriches the high-leverage ones.

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

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

Opens with a specific verb+resource: 'Create a complete PowerPoint presentation (.pptx): a whole multi-slide deck, native and editable, in one call.' It differentiates from create_slide by emphasizing multi-slide and one-call deck construction, and further clarifies what the deck includes (cover, dividers, closing, page numbers).

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 mode guidance: render vs mode=assemble (merge job_ids as-rendered, theme_id does not re-theme) vs mode=fork, and points to manage_account for polling and browse_catalog for blocked new forms. It does not explicitly state when to prefer create_slide or plan_slide, though the 'multi-slide deck' framing implies the boundary.

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

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

The description discloses cost and failure behavior in detail: $0 blocked/invalid renders, can_autofix patch merging, unchanged retries blocking, safe-mode billing only when faithful, mode=code and image-generation surcharges, and allow_truncation/force_render consequences. Since annotations only signal non-readonly/non-destructive behavior, all of this is highly additive.

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

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

The description is long, but the tool has 42 parameters and a large form menu, so the length is largely justified. It is well-structured with headings, a compact form menu, and front-loaded purpose; minor redundancy with schema-level mode/block descriptions prevents a 5.

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

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

The description covers the full decision space: form routing, per-form schema access, failure and billing behavior, escape modes, retry semantics, polling, and response verbosity controls. Despite there being no output schema, the description and detail parameter together give agents enough context to invoke 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 93%, so the baseline is 3, but the description adds genuinely valuable semantics: it defines every form menu option, explains list-shaped forms vs structured data payloads, and points to browse_catalog for exact per-form schemas. It also clarifies the tradeoffs between safe and brief modes beyond the schema.

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

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

The first sentence is explicit: 'Create one PowerPoint slide (.pptx, native, editable) from a structured intent in ONE call'. The large form menu and the safe/brief/code/status modes make the tool's scope unmistakable and distinguish it from deck-level or planning 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 gives clear routing guidance: use browse_catalog for schemas, use mode=code for forms the menu cannot express, use mode=status to poll, and use dry_run for a free pre-commit check. It does not explicitly contrast with create_deck or plan_slide, but the single-slide scope and form routing make the intended use 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?

The description goes well beyond the annotations by disclosing irreversibility of delete_job and delete_asset, automatic wallet credit on topup, volume bonuses, the fact that logos are content-addressed/shared and not deleted, and the severity default to 'suggestion'. These are genuinely useful behavioral details.

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

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

The description is dense but front-loaded with an action inventory before detailed explanations. Given 18 actions and 17 parameters, the length is largely justified. There is some redundancy where the action parameter description repeats parts of the initial inventory, but it remains scannable.

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

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

The description covers most actions and destructive semantics thoroughly, but the missing theme_id parameter for brand_report and the conflicting reports action description are real invocation hazards. Several actions such as onboarding, webhook_test, and security_status lack expected behavior or return detail, and with no output schema the description must carry more weight than it does.

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 meaningful semantics: amount volume bonuses, detail masking identity fields, include_children cost roll-up, and severity defaulting. However, it loses a point because action=brand_report tells the agent to pass theme_id, yet theme_id is not present in the schema, and reports behavior is described inconsistently between the action summary and the slug parameter.

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 names the exact domain ('SlideForge account for PowerPoint generation: balance, billing, job history, feedback, data controls') and the action list enumerates the operations in detail. This clearly differentiates the tool from sibling tools like create_slide, create_deck, and upload_asset.

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 explicit selection guidance: use topup when a render is refused for balance, use webhooks instead of polling, use download_url when a result carries no inline URL, and check feedback_list before working around a previously reported defect. It also instructs the agent to ask the user before filing feedback.

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 read-only, idempotent, non-destructive behavior, but the description adds substantial extra context: free one-embedding cost, escalation behavior, calibrated confidence semantics, negative margin meaning, and source distinction. This goes well beyond the annotations.

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

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

The description is front-loaded with the core purpose, then covers detailed response semantics that are necessary because no output schema exists. It is dense but not padded; the parentheticals are efficient rather than 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?

The description thoroughly explains the returned verdict fields, confidence, retrieval scores, and next steps, compensating for the missing output schema. However, the 'top' parameter remains undocumented and the shape of the candidate ranking is only implied.

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 documents escalate and variant_policy, but the description does not explain the 'top' parameter at all, and only vaguely references 'a short brief.' With only 50% schema description coverage, the missing 'top' semantics is a meaningful gap.

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

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

The description states a specific verb and resource: plan a PowerPoint slide before rendering, returning ranked candidates plus a verdict. It explicitly hooks into create_slide for the actual creation step, which differentiates it from the sibling tool create_slide.

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 clear context: use this tool before rendering, it is free, and then call create_slide with the chosen form/variant. It does not exhaustively list when not to use the other siblings, but the workflow guidance is strong and unambiguous.

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

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

Annotations are all false and carry no operational meaning, so the description bears the burden. It adds non-obvious behavioral facts: the '$0.02/slide' cost, the formatting-preservation guarantee, and the 32-language/script scope. It does not disclose what is returned or whether a new job is created, which is the main gap.

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

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

Three sentences with no filler: purpose+guarantee, cost+language scope, and input routes. The most important information is front-loaded in the first clause, and every sentence adds a distinct 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 10-parameter paid tool with no output schema, the description covers the critical invocation facts: purpose, cost, language scope, and the three mutually exclusive input methods. The notable omission is result semantics — what the agent receives after translation — which matters because there is no output schema to fill 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 100%, so per baseline this is a 3. The description's one contribution — framing job_id/pptx_url/pptx_base64 as three alternative source routes — largely restates what the schema already says ('preferred — no file transfer needed'). No additional meaning 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?

Opens with a specific verb+resource: 'Translate a PowerPoint (.pptx) deck'. The qualifier 'preserving all formatting' adds precision, and translation is clearly distinct from the sibling tools (create_slide/create_deck build decks, upload_asset uploads, plan_slide plans, browse_catalog browses). An agent can identify what this tool does instantly.

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 context: the source must come from 'a previous create_slide/create_deck' job, an HTTPS URL, or base64 — with the workflow implication that translation happens after deck creation. It lacks an explicit when-not-to-use statement naming an alternative, hence not 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 signal that this is not read-only, not idempotent, and not destructive. The description goes far beyond that by disclosing prices, native template rendering, the drop-zone fallback ('bytes never pass through the agent'), and the recreate fallback behavior with free refusals.

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

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

The description is dense but extremely well-structured: a one-sentence summary followed by purpose bullets, each containing only unique facts (ID returned, cost, size limit, fallback behavior). There is no fluff or repeated 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?

All eight purposes are explained with their required parameters, return IDs, costs, and edge-case handling. With no output schema, the description still prepares the agent for what each call yields (logo_id, asset_id, theme_id, deck job_id), making it complete enough 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?

Although schema coverage is 100%, the description adds critical meaning not in the schema: size limits (logo 5MB, image 10MB), per-purpose costs, the effect of omitting data for pdf/translate/theme, and the brand/theme alias. This is exactly the kind of parameter context an agent needs.

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 ('Upload assets... or AI-generate an image') and resource ('assets for PowerPoint (.pptx) generation'), then breaks down eight distinct purposes. This makes it unmistakable that this tool is the asset-ingestion/generation entry point, and none of the sibling tools handle this 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?

The bullet list acts as a decision table: each purpose explains when to use it, what it returns, and any special requirements (e.g., target_language for translate). It also gives direct routing advice like 'Use image to just place a picture' for recreate, and recommends omitting data for files >3MB to trigger a drop-zone.

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