Redesign a PowerPoint in your brand, or build a sales deck for a prospect. Returns a share link.
Scored across 7 tools
Each tool has a clearly distinct action and target resource. create_deck and create_sample_deck are the closest pair, but the descriptions make their use cases (account connected vs. not) explicit. get_rebuild_status is tightly scoped to rebuild_deck.
All tool names follow a consistent snake_case verb_noun pattern: create_deck, create_sample_deck, get_deck, get_rebuild_status, list_decks, publish_deck, rebuild_deck. There is no mixing of conventions.
Seven tools is a well-scoped set for PitchBoost's deck creation, retrieval, publishing, and rebuild workflow. Each tool has a clear distinct role and none appear redundant or excessive.
Core lifecycle operations are covered: generate (create_deck, create_sample_deck), retrieve (get_deck, list_decks), publish (publish_deck), and rebuild (rebuild_deck, get_rebuild_status). Missing delete and metadata update operations are minor gaps that do not block primary workflows.
Generate a published PitchBoost deck from a prompt describing the prospect, offer, audience, and goal. Returns a shareable link. Generation takes up to ~60 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Deck type. Defaults to pitch_deck. | |
| prompt | Yes | What the deck should cover: the prospect or company, the offer, the audience, and the goal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds two genuinely non-obvious facts: it returns a shareable link and generation can take ~60 seconds, which is real latency context an agent needs. It does not say what happens on repeated calls despite idempotentHint=false, so it is 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?
Two sentences, zero waste: the action and output come first, the latency caveat last. Every clause carries information an agent would otherwise lack.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter creation tool with no output schema, the description covers the action, the return artifact (shareable link) and the expected duration. Combined with fully-covered schema descriptions and annotations, 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 description coverage is 100%, so both parameters are already documented including the kind enum and its default. The description's phrasing of what the prompt should contain echoes the schema rather than extending it, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Generate a published PitchBoost deck') and implies the distinguishing trait versus create_sample_deck/publish_deck by specifying 'published'. It stops short of naming siblings explicitly, so an agent still has to infer the boundary, but purpose 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?
Usage is implied: call it with a prompt describing prospect, offer, audience and goal. There is no explicit when-to-use vs create_sample_deck or publish_deck, and no stated preconditions or exclusions. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a hosted, shareable sample pitch deck from a short prompt with no PitchBoost account. The deck carries a small PitchBoost badge and the response includes a single-use claim token the user can enter after signing in to move the deck into their own account. Use this when the user has not connected PitchBoost. Generation takes up to a minute.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | What the deck should cover: the prospect or company, the offer, the audience, and the goal. Up to 1000 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/idempotency/open-world profile, so the description only needs to add context it does: a PitchBoost badge is stamped on the output, a single-use claim token is returned for later account migration, and generation takes up to a minute. The latency disclosure is especially valuable for agent timeout planning. It does not state that repeated calls create separate decks, but the non-idempotent annotation already covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the capability and scope, then the output artifact (claim token), then the usage condition and latency. Every sentence carries distinct information; nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: it explains the hosted deck, the badge, and the claim token. Combined with the stated latency and account-free usage condition, an agent has everything needed to call this correctly and set expectations for the user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter with 100% schema description coverage, so the schema already documents the prompt's content and 1000-character limit. The description adds only 'from a short prompt', which is a restatement rather than new syntax or format guidance. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Generate) and resource (hosted, shareable sample pitch deck) and immediately distinguishes itself from the sibling create_deck via the 'no PitchBoost account' qualifier. An agent can route between the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the selecting condition: 'Use this when the user has not connected PitchBoost.' That is a clear when-to-use rule that implicitly contrasts with the authenticated create_deck sibling. It does not name the alternative or the inverse condition ('if connected, use create_deck'), so it falls just 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.
Get a single deck by its numeric id, including its shareable link and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| deck_id | Yes | The deck id. |
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.
Check whether a rebuild started with rebuild_deck has finished. Returns the shareable link and editor link when the deck is ready, or how long it has been running.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_id | Yes | The deal_id returned by rebuild_deck. |
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.
List the most recent published decks for your team, each with its shareable link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (1-50, default 20). |
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.
Turn a deck's shareable link on. Rebuilt and generated decks go live at their share_url as soon as they are finished; use this when the user made one private and wants the link back. Not destructive and safe to repeat.
| Name | Required | Description | Default |
|---|---|---|---|
| deck_id | Yes | The deck id (from get_rebuild_status, list_decks or get_deck). |
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.
Improve, redesign, polish or rebrand an existing presentation. Pass the text of every slide of the user's uploaded PowerPoint, Google Slides or Keynote deck (title and body, in order). PitchBoost keeps the content and figures, rebuilds every slide with professional layout in the user's brand, checks every number against the source, and returns a shareable link plus PDF and PowerPoint exports. Generation runs in the background for 2 to 4 minutes: this call returns a deal_id at once; call get_rebuild_status with it to get the link when ready.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | preserve (default) keeps one slide per source slide; condense compresses a long deck to about 10 to 15 slides. | |
| slides | Yes | The source deck, one entry per slide in order. Extract these from the user's uploaded file: title is the slide heading if any, body is all other text on the slide. | |
| deal_name | No | Optional name for the deck in the user's dashboard. Defaults to the first slide title. | |
| instructions | No | Optional guidance from the user, for example the audience, tone, or slides to emphasise. Up to 1000 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: asynchronous generation running 2-4 minutes in the background, immediate deal_id return, the required polling handoff to get_rebuild_status, and the guarantee that content and figures are preserved while numbers are checked against source. It also names the concrete outputs (shareable link, PDF, PowerPoint), which the annotation set does 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?
Purpose is front-loaded in the first clause, followed by input expectations and then the async mechanics, so the agent gets the 'what' before the 'how'. Every sentence carries distinct information; none restates the schema or the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: it states the call returns a deal_id immediately, how long generation takes, which tool retrieves the final link, and what artifacts come back. Nothing an agent needs to invoke or sequence this tool is absent.
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 real operational meaning by telling the agent where the slide data comes from (PowerPoint, Google Slides or Keynote uploads) and that entries must be ordered title-then-body. The mode and instructions semantics are already carried by the schema, so this is a modest lift above baseline.
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 leads with a specific verb set (improve, redesign, polish, rebrand) applied to a clearly scoped resource: an existing presentation. The word 'existing' plus the slide-extraction instruction cleanly separates it from create_deck and create_sample_deck without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear operative context: extract text from the user's uploaded deck, one entry per slide, and it explicitly routes the follow-up call to get_rebuild_status. What's missing is an explicit exclusion naming create_deck as the alternative when the user has no source deck, so the boundary is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_deckcreate_sample_deckget_deckget_rebuild_statuslist_deckspublish_deckrebuild_deckCreate consulting-style presentation decks (editable PowerPoint) from a topic or notes.
Build decks in your own brand, from the AI agent you already use. Then edit them yourself.
Create professionally designed, editable PowerPoint presentations from a prompt.
Deterministic, fully editable PowerPoint from typed slide intents. 200+ layouts, brand templates.
Add one secure layer between your agents and this server.
