Bisque Presentations

Publish a presentation you narrated yourself

publish_narrated_presentation

Destructive

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
`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.
`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

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

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already mark this as destructive, so the description need not restate that. It adds useful behavior not visible in annotations: the two-step upload flow (PUT MP3s/assets then POST completeUrl), server-side cue recomputation, and re-publish carry-forward/reuse semantics with staleSlides. It is slightly less explicit about destructive overwrite effects, but the annotation covers that baseline.

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 dense but well organized, front-loading the core behavior, then the upload workflow, then the RE-PUBLISHING section. A few clauses (e.g., 'free, unlimited, and works on macOS, Linux and Windows') are contextual rather than invocation-critical, but the structure keeps the important guidance easy to parse.

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?

Given 13 parameters, an output schema, and rich annotations, the description covers what an agent needs: the full call/response workflow, re-publish behavior, stale-slide remediation, and the alternative tool. Nothing critical for correct invocation appears to be missing.

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?

With 85% schema coverage, the schema carries most parameter detail; the description adds high-level meaning by explaining how the audio array and returned URLs fit into the publish workflow and by clarifying re-publish audio optionality. It does not fully compensate for the undocumented voiceStability field, but that gap is minor given the schema richness.

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?

The description names a specific verb and resource ('Publish an html-presentation/v1 document using audio YOU synthesized locally') and immediately distinguishes it from the sibling that server-narrates. It leaves no ambiguity about what this tool is for.

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?

It gives explicit selection criteria: use this for locally synthesized narration, and 'Use create_presentation instead to have the server narrate.' It also states exactly when re-publishing can omit audio, covering a major conditional use case.

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?