Bisque Presentations

Deprecated — use create_presentation with `audio`

publish_narrated_presentation

Destructive

DEPRECATED: call create_presentation with an audio array instead — it is the same thing in one call, and the slides are viewable while the narration lands. Publish an html-presentation/v1 document using audio YOU synthesized locally (e.g. with bisque-voice) — free, unlimited, and works on macOS, Linux and Windows. Send each narrated slide's word timings and MP3 metadata; the server assembles presentation.json (recomputing cues from your narration markers) and returns one upload URL per MP3. Then PUT each file and POST the returned completeUrl with the returned files array. RE-PUBLISHING: audio is optional — any narrated slide you omit reuses the audio from the last publish whenever its narration text and speechSpeed are unchanged, so an HTML-only edit needs no synthesis at all. The response reports reused, synthesized, and staleSlides (narrated slides whose text changed and have no audio — synthesize exactly those and publish again). Use create_presentation instead to have the server narrate.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	No	URL slug; defaults to a slugified title.
`audio`	No	One entry per slide you synthesized, from the JSON `bisque-voice` prints on stdout. `words`, `durationMs`, `size` and `hash` map across verbatim. Optional: omit a slide (or the whole array) and its audio carries forward from the previous publish if the narration text is unchanged — otherwise that slide publishes silent and is listed in `staleSlides`. A FIRST publish with nothing to carry forward is rejected.
`title`	No	Display title for the watch page and listings. Omit to use the title parsed from the document.
`assets`	No	Files the document references relative to itself — fonts, images, SVG, Lottie, Rive, bundled audio cues. html-presentation/v1 requires these to be self-hosted, so a presentation that renders locally is broken once published unless they travel with it. Each gets an upload URL back alongside the MP3s; PUT them the same way. Paths must be under `assets/` — the server owns index.html, presentation.json and context.md, and the manifest owns audio/. Omit for a presentation that references nothing.
`handle`	No	Publish under a specific channel handle you own.
`voiceId`	No	Records what actually spoke, e.g. kokoro:af_heart for a locally synthesized Kokoro voice. No audio is generated server-side.
`designMd`	No	Design frontmatter mapped to theme tokens.
`madeWith`	No	Credit the models that made this: the model you are running as, and the engine that synthesized the audio you are uploading — e.g. ["Claude Opus 5", "Kokoro af_heart"]. Shown to viewers in the watch page's ⋯ menu. Send it on every publish; omitting it keeps whatever a previous publish recorded.
`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	Must match the speed you synthesized at — it is part of the audio cache key, so changing it on a re-publish makes every slide stale instead of carrying forward.
`presentationId`	No	Stable id for idempotent re-publishes; defaults to slug-<hash(userId:slug)>.
`voiceStability`	No	Records the stability setting you synthesized at. No audio is generated server-side.

Output Schema

TableJSON Schema

Name	Required	Description
`files`	Yes	Echo back verbatim as the complete call's `files`.
`reused`	Yes	Slide keys whose audio carried forward — no upload.
`webUrl`	Yes	Shareable watch URL.
`warnings`	Yes
`publishId`	Yes
`uploadUrls`	Yes	One pre-signed PUT per file to upload.
`completeUrl`	Yes	POST here after every PUT, echoing `files` back verbatim.
`staleSlides`	Yes	Narrated slide keys that will publish SILENT — synthesize exactly these and publish again.
`synthesized`	Yes	Slide keys this request supplied audio for.
`presentationId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 9, 2026

addedInput schema / properties / madeWith

Added value: +{
+  "description": "Credit the models that made this: the model you are running as, and the engine that synthesized the audio you are uploading — e.g. [\"Claude Opus 5\", \"Kokoro af_heart\"]. Shown to viewers in the watch page's ⋯ menu. Send it on every publish; omitting it keeps whatever a previous publish recorded.",
+  "items": {
+    "maxLength": 80,
+    "type": "string"
+  },
+  "maxItems": 8,
+  "type": "array"
+}

Changed2 schema fields changedSep 2, 2026

addedInput schema / properties / title / description

Added value: +"Display title for the watch page and listings. Omit to use the title parsed from the document."

addedInput schema / properties / voiceStability / description

Added value: +"Records the stability setting you synthesized at. No audio is generated server-side."

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark destructiveHint=true, and the description adds substantial behavior beyond that: deprecation, the multi-step PUT/POST upload flow, rejection of a first publish with no audio, and response fields such as `reused`, `synthesized`, and `staleSlides`. There is 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.

Conciseness4/5

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

The description is long but dense and front-loaded: deprecation and the replacement call appear first, followed by the upload workflow and re-publishing semantics. Every sentence earns its place for this complex tool, though the deprecation notice is restated from the title.

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

Completeness5/5

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

For a 14-parameter tool with an output schema and rich annotations, the description provides all decision-level context: deprecation, alternative tool, upload mechanics, carry-forward rules, and response reporting. An agent has enough to decide whether to call it and how to invoke it correctly.

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

Parameters4/5

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 extra meaning beyond the schema by explaining that `audio` entries map from bisque-voice stdout, that omission carries forward prior audio, and that changing `speechSpeed` invalidates carry-forward. This is helpful context without merely restating the schema.

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

Purpose5/5

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

States a specific verb and resource: publishing an html-presentation/v1 document with locally synthesized audio. It also clearly distinguishes itself from create_presentation by declaring itself deprecated and naming the replacement call with an `audio` array.

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

Usage Guidelines5/5

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

Explicitly tells the agent to call create_presentation with an `audio` array instead, and explains why it is preferable. It also covers when re-publishing can omit audio, when stale slides need re-synthesis, and when to use create_presentation for server-side narration.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?