Bisque Presentations

Create narrated presentation

create_presentation

Destructive

Generate a narrated presentation from an html-presentation/v1 document. BEFORE authoring, call get_presentation_spec and follow it exactly — slides without its narration markup publish SILENT. Returns a presentationId; poll get_presentation_status until it is ready.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	No	URL slug; defaults to a slugified title.
`title`	No
`assets`	No	Files the document references relative to itself — fonts, images, Lottie/Rive animations, sound-effect audio, video clips. The SERVER fetches each https url at create time and stores it in the bundle, so reference `assets/...` paths in your HTML and list the sources here instead of inlining base64. 10MB per asset, 30MB total.
`dryRun`	No	Sandbox: run every check a real create runs (format, slug and org conflicts, tier cap, credit preflight) and write nothing. The reply has status "validated" and the webUrl a real create would publish at. Use it to test an integration without touching the channel.
`handle`	No	Publish under a specific channel handle you own.
`voiceId`	No	Narration voice. ElevenLabs: a bare id or cloud:<id>. Self-hosted Kokoro: kokoro:<id> (e.g. kokoro:af_heart); local:<id> is accepted as a synonym. Omit to use the voice saved on the account (bisque.cloud/account), falling back to the server default.
`designMd`	No	Design frontmatter mapped to theme tokens.
`contextMd`	No	Shared-with-viewer context.md.
`indexHtml`	Yes	Full html-presentation/v1 document (the presentation-format meta gate applies).
`visibility`	No	unlisted (the default) is shareable by link and plays in chat-embedded players; private requires the owner to sign in, so an inline chat player shows a sign-in wall instead of playing — choose private only when the user asked for it.	unlisted
`speechSpeed`	No
`presentationId`	No	Stable id for idempotent re-creates; defaults to slug-<hash(userId:slug)>.
`voiceStability`	No

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	ready = nothing needed narration; queued = narration runs in the background — poll get_presentation_status.
`webUrl`	Yes	Shareable watch URL (live once status is ready).
`narration`	Yes
`statusUrl`	Yes
`presentationId`	Yes

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations, the description adds valuable behavioral context: slides without the required narration markup 'publish SILENT,' and creation is asynchronous, requiring polling until ready. It does not elaborate on the destructiveHint=true annotation, but it does not contradict it, and the added silent-failure warning is genuinely useful.

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

Conciseness5/5

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

The description is three sentences with no filler: it states the core action, the critical prerequisite, and the follow-up step. Every sentence earns its place, and the most important warning is front-loaded.

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

Completeness4/5

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

Given the 13-parameter complexity and availability of an output schema, the description covers the essential workflow: prerequisites, the silent-failure risk, and polling. It does not mention sibling-tool selection or destructive implications, but the core invocation context is sufficiently complete.

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

Parameters3/5

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

Schema description coverage is 77%, so most parameters are already documented. The description adds meaning around the main input by tying the html-presentation/v1 document to the narration markup requirement, but it does not otherwise explain parameters beyond the schema. This is adequate but not exceptional.

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

Purpose4/5

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

The description states a specific verb and resource: 'Generate a narrated presentation from an html-presentation/v1 document.' This clearly identifies what the tool does. However, it does not explicitly distinguish itself from the sibling publish_narrated_presentation, so an agent may have to infer the relationship between creating and publishing.

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

Usage Guidelines4/5

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

The description gives explicit usage guidance: call get_presentation_spec before authoring, follow it exactly, and poll get_presentation_status after creation. This is clear operational context. It does not, however, explain when to choose this tool over publish_narrated_presentation or other siblings, so exclusion guidance is missing.

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

All Bisque Presentations tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Most tools are clearly distinct, with create/get/list/publish/update separating actions and resources. The main ambiguity is between create_presentation and publish_narrated_presentation, though the descriptions do clarify that one is server-narrated and the other uses locally synthesized audio.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: create_, get_, list_, publish_, update_. The naming is predictable and makes the action and target resource easy to identify.

Tool Count5/5

Eight tools is well-scoped for the presentations domain, covering authoring, publishing, status, reading, analytics, and channel configuration. There is no bloat, and each tool has a place in the workflow.

Completeness4/5

The core lifecycle is covered: fetch spec, create/publish, check status, list, read shared context, and view analytics. Obvious gaps like deleting or unpublishing a presentation are missing, but they are workable around and do not severely break the primary authoring-to-analytics workflow.

Resources

Need Help?