PitchBoost

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

Annotations already declare non-read-only, non-destructive, non-idempotent and closed-world, so the safety profile is covered. The description usefully adds two behavioral facts annotations cannot carry: it returns a shareable link and generation takes up to ~60 seconds. It does not say whether repeated calls create duplicate decks (relevant given idempotentHint=false) or whether the call blocks during those 60 seconds.

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 front-loaded sentence with the action first, then scope, output, and latency. The middle genre enumeration is long but serves retrieval and intent matching, so it mostly earns its place.

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

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

Covers purpose, inputs, output (shareable link), and latency, which is enough for a two-parameter generation tool with no output schema. It stops short of explaining the relationship to get_rebuild_status or list_decks, leaving post-creation flows 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 documented in the schema, including the kind enum with its default. The description only implies that the prompt drives generation and that language is free-form; it adds no syntax, format, or length guidance 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 concrete verb+resource ("Make a presentation in the user's PitchBoost account from a prompt") and enumerates the presentation genres it targets, which disambiguates it from the read/status siblings. It does not explicitly distinguish itself from create_sample_deck or rebuild_deck, 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 genre list (lesson, thesis, report, workshop, sales pitch) and "in any language" give clear guidance on when this tool is the right choice. No exclusions or comparisons to create_sample_deck / rebuild_deck are offered, so the agent must infer which generator to pick.

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 (which already flag non-read-only, non-destructive, non-idempotent, closed-world), the description discloses what an agent could not otherwise know: the deck is publicly hosted and carries a PitchBoost badge, the response contains a single-use claim token for later account transfer, and generation can take up to a minute. That latency note and the claim-token mechanics are essential operating context.

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

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

Purpose and the no-account qualifier lead, followed by the return-value mechanics and the timing warning. The mid-sentence list of deck genres is a bit long but each item maps to a real use case, so it earns most of its 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?

No output schema exists, yet the description tells the agent what comes back (a claim token) and how long to expect to wait. For a single-parameter generation tool with annotations covering the safety profile, 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?

Schema coverage is 100%, so the baseline is 3, but the description goes further by enumerating acceptable prompt intents (lesson, thesis presentation, report, talk, investor pitch) and stating 'in any language' — neither of which appears in the schema. This measurably improves how an agent composes the prompt.

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 ('Make a hosted, shareable presentation') with the key differentiator 'with no PitchBoost account' front and center. That clause alone separates it from create_deck, so an agent can pick correctly without opening 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?

'Use this when the user has not connected PitchBoost' gives an explicit selection condition that implicitly excludes the account-based sibling. It stops short of naming create_deck as the alternative for connected users, so the routing is inferred rather than 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that by disclosing what the call returns ('its shareable link and metadata'), which annotations do not 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?

One sentence, front-loaded with the verb and resource, with no redundant or filler content. Every clause (id scoping, return contents) earns its place.

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

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

For a simple single-resource read with no output schema, the description covers the identity, the key input and the shape of the return value. Only error behavior and id-format expectations are unaddressed, which is 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 description coverage is 100%, so the single deck_id parameter is already documented in the schema, and the description only restates it as a 'numeric id'. Baseline 3 applies when the schema does the heavy lifting and the description adds no format or edge-case detail.

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 ('Get a single deck') and scopes it by numeric id, which implicitly distinguishes it from list_decks. It does not name any sibling explicitly, but the singular/plural contrast is clear enough to route correctly.

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

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

Usage is only implied: an agent can infer this is the tool for fetching one known deck rather than enumerating decks. There is no explicit statement of when to prefer this over list_decks or what happens with an invalid/missing id.

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 the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description adds real value beyond them by disclosing both possible outcomes: links when ready, or elapsed running time otherwise. It does not mention polling cadence or terminal failure states, keeping it just 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?

Two sentences with no waste: the first defines the condition being checked, the second enumerates the return outcomes. Both are front-loaded and every clause earns its place.

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

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

There is no output schema, so return values must be conveyed in prose, and the description does so concretely (shareable link, editor link, or elapsed duration). Combined with a fully documented single parameter, an agent has everything needed to call and interpret this 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 100% and the sole parameter (deal_id) is documented there as 'the deal_id returned by rebuild_deck'. The description adds no syntax or format detail beyond the schema, so the 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 (Check) and resource (whether a rebuild has finished), and ties it to the sibling that initiates the operation (rebuild_deck). An agent can distinguish this polling tool from rebuild_deck and get_deck 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?

The phrase 'a rebuild started with rebuild_deck' tells the agent this is the follow-up to a prior rebuild_deck call, giving clear usage context. It stops short of explicit when-not guidance or naming alternatives for checking deck state (e.g., 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a real behavioral detail beyond the annotations — that results are limited to *published* decks and each carries a shareable link — but says nothing about ordering guarantees, pagination, or what happens when a team has no decks.

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

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

A single sentence with zero filler that front-loads the resource and the scope, then adds the payload detail. Nothing could be trimmed without losing information.

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

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

For a simple 1-parameter, no-output-schema read tool whose annotations already carry the safety profile, the description covers purpose, scope, and return shape adequately. It is only mildly short on failure/empty-result behavior, which is 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?

With one parameter and 100% schema description coverage ('How many to return (1-50, default 20)'), the schema fully documents the input. The description adds only the implicit notion of 'most recent' ordering and no extra syntax or format meaning, so the 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 ('List the most recent published decks') plus useful scope ('for your team'), so an agent can distinguish it from the singular get_deck sibling. It stops short of explicitly naming which sibling to prefer, but the purpose itself is unambiguous.

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

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

The description never says when to use this tool versus get_deck, publish_deck, or the create_* siblings, nor does it state prerequisites. Usage is only implied by the word 'List'.

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

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

The annotations already declare idempotentHint=true and destructiveHint=false, and the description's 'Not destructive and safe to repeat' largely restates those. But it adds genuinely new context with 'Rebuilt and generated decks go live at their share_url as soon as they are finished,' which explains auto-publish behavior the 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?

Three short sentences, front-loaded with the core action, and every sentence is readable at a glance. The 'Not destructive and safe to repeat' sentence is partially redundant with the annotations, a minor inefficiency rather than clutter.

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

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

For a one-parameter, no-output-schema tool with full annotation coverage, the description supplies everything needed: the action, the trigger condition, and the auto-publish nuance. Nothing required to invoke 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 100% and the sole parameter's id source ('from get_rebuild_status, list_decks or get_deck') is already documented in the schema. The description adds no argument syntax or format detail beyond that, so the 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: 'Turn a deck's shareable link on.' This is clearly distinguishable from create_deck, rebuild_deck, and the read tools among its siblings. An agent knows exactly which state change this performs.

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 usage condition: 'use this when the user made one private and wants the link back,' which is concrete and actionable. It does not, however, name an alternative or state when not to use it (e.g., versus create_deck or the auto-publish behavior of rebuild_deck), so it stops short of full routing guidance.

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

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

Annotations only declare non-read-only, non-destructive, non-open-world, so the description carries real weight and does: it states content and figures are preserved, numbers are verified against the source, the brand is applied, and that generation is asynchronous (2-4 minutes) returning a deal_id immediately, with downloads via the web app. That is exactly the behavioral context an agent needs before calling a long-running mutation.

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 action and input are front-loaded, then the pipeline and async follow-up, which is the right order. The parenthetical list of deck types ('coursework, a lecture, a report, a pitch') is padding that could be cut without loss.

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 explain returns and it does: a deal_id immediately, then a shareable link and PowerPoint/PDF downloads via the web app. Combined with the async timing and the sibling handoff to get_rebuild_status, an agent has everything needed to invoke and complete the workflow.

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 that by adding extraction semantics the schema does not — pull title and body from the user's uploaded file, one entry per slide, in order. The mode parameter's preserve-vs-condense tradeoff is left entirely to the schema, which limits it to a 4.

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 set (improve, redesign, polish, rebrand) applied to a precise resource: an existing presentation, explicitly distinguished from creating a new one. It also names the accepted source formats (PowerPoint, Google Slides, Keynote), so the agent knows exactly which request this tool owns.

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 tells the agent what to pass (the text of every slide, in order) and spells out the follow-up step: this call returns a deal_id and get_rebuild_status must be called for the link. The only gap is that the sibling create_deck is never named as the alternative for new decks — the split is implied by 'existing' rather than stated.

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