How do I use showntell?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@showntell show me how a request gets retried in this codebase" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

showntell

by rahimnathwani

Overview Schema Source Related Servers Discussions Admin

Python

Local

showntell

Narrated slide walkthroughs for coding agents, voiced on your machine.

Ask your agent to walk you through a pull request, a module or a concept. It writes slides and narration in Markdown; showntell voices them locally with Kokoro and hands back a link that starts playing in about a second, while the rest is still being written. A pointer follows the narration through code, diagrams and lists, word by word.

A walkthrough playing: the pointer moves through a diagram and then through code as the narration names each part

Watch the gallery: five walkthroughs written by Claude Opus and voiced on a laptop, unedited: a tour of this repository, a code review of one of its commits, the TLS 1.3 handshake, scaled dot-product attention, and git rebase versus merge on a phone-shaped frame.

Local: speech runs on your Mac or PC. No API keys, no hosted service, no telemetry. Code never leaves your machine except to the model you already use.
Fast: the link is playable about 0.3 s after the agent sends its opening, so you start watching while the agent keeps writing.
Grounded: code slides are read straight from your files and git history, with real line numbers. The agent never retypes code, and the pointer lands on the right line.
Checked: every call returns problems to the agent: a cue pointing at a missing line, code too big for the frame, narration that reads the screen aloud, diagrams that failed to render in the open player.
Shareable: export any walkthrough as a static folder with captions, and host it anywhere.

Install

You need uv and Python 3.12 or newer, which uv installs for you.

claude mcp add showntell -- uvx --from git+https://github.com/rahimnathwani/showntell showntell mcp

Once showntell is on PyPI this becomes uvx showntell mcp. Then ask Claude Code: "show me how a request gets retried in this codebase".

The first run downloads the voice model (about 330 MB on Apple silicon, 92 MB elsewhere) and a 12 MB English language model, from Hugging Face and GitHub. After that, everything works offline.

Client	Setup
Claude Code	`claude mcp add showntell -- uvx --from git+https://github.com/rahimnathwani/showntell showntell mcp`
Cursor, VS Code, Codex CLI, Gemini CLI, Claude Desktop	a stdio server with command `uvx` and arguments `--from git+https://github.com/rahimnathwani/showntell showntell mcp`
Any client over HTTP	run `showntell serve`, then connect to `http://localhost:4747/mcp`

showntell mcp starts a shared background daemon the first time, or reuses the running one, so the voice model stays loaded across sessions and every client uses one port. showntell doctor checks the setup and measures speech speed.

On a Mac, showntell autostart on starts the daemon at login, so the first walkthrough of the day is as fast as the rest.

Related MCP server: MCP Walkthrough

How it works

graph TB
  subgraph agent [Your coding agent]
    S[start_walkthrough with the opening] --> L[shares the link with you]
    L --> M[add_slides one to three slides at a time]
    M --> F[finish_walkthrough]
  end
  subgraph daemon [showntell daemon]
    P[Markdown parser] --> B[Slide builder and checks]
    B --> Q[Speech queue]
    Q --> K[Kokoro on MLX or ONNX]
  end
  subgraph browser [Your browser]
    R[Player driven by narration time]
  end
  S --> P
  M --> P
  K --> R
  B -->|changed slides over SSE| R

Opening first. The agent's first call starts the walkthrough with only the title slide and a sentence or two. It returns as soon as that audio exists, about 0.3 s later, and tells the agent to send you the link.
Voiced in the background. Later slides are parsed, checked and voiced while you watch. The player waits with a notice if it ever catches up with the writer.
Timed to the word. Kokoro reports when each word is spoken. Each cue in the narration, a Markdown link like [the retry limit](#L48), moves the pointer as its first word is heard.

The format

A walkthrough is Markdown. Headings start slides, fenced blocks and lists are what you see, plain paragraphs are what you hear.

# How the retry loop works
> Backoff in the HTTP client

A failed request can be sent up to four times. Let's follow one.

## Giving up {#give-up .build}

```python file=src/http/retry.py lines=40-56
```

Each pass through [the loop](#L42 "for attempt in range") sends the request once.
After [the final attempt](#L55) the error goes back to the caller.

Visual	Markdown
Code	a fenced block, or `file=path lines=10-24` to read it from disk
Diff	`old` and `new` blocks, a unified `diff` block, or `diff file=path rev=HEAD~1`
Diagram	a `mermaid` block, any diagram type
Formula	a `math` block or `$$ … $$`, rendered with KaTeX
Table	a pipe table
List, steps, cards	`-` or `1.` items; `.cards` on the heading for cards
Image	`![alt](path)` from the project

.build on a heading reveals parts as the narration reaches them. The full reference is docs/format.md. You can also write a walkthrough by hand and play it with showntell play talk.md.

Commands

Command	What it does
`showntell mcp`	stdio MCP server; starts or reuses the daemon
`showntell serve`	the daemon in the foreground: MCP over HTTP at `/mcp`, the player, and the list of walkthroughs at `/`
`showntell play FILE.md`	voice a Markdown walkthrough and open it
`showntell export ID\|LINK\|FILE.md OUT [--mp3]`	a static folder that plays from any web server, with WebVTT captions
`showntell list`	recent walkthroughs
`showntell doctor`	check models, speech speed, port and daemon
`showntell autostart on\|off\|status`	macOS: keep the daemon running from login

Settings

Environment variables, also listed in .env.example. Command-line flags override them.

Variable	Default	Meaning
`SHOWNTELL_PORT`	4747	daemon port; the next free one is used if taken
`SHOWNTELL_HOST`	127.0.0.1	interface; anything else requires an access token, which is generated and added to links
`SHOWNTELL_DATA`	`~/.local/share/showntell`	walkthroughs, audio cache, models, lockfile and log
`SHOWNTELL_VOICE`	`af_heart`	default voice; any English Kokoro voice, such as `am_michael` or `bf_emma`
`SHOWNTELL_SPEECH`	`auto`	`mlx` on Apple silicon, `onnx` elsewhere, or `fake` for tests
`SHOWNTELL_PUBLIC_URL`		base URL for links when viewing from another device, such as a Tailscale name; links then carry an access token
`SHOWNTELL_ONNX_MODEL`	`model_quantized`	ONNX variant; `model` (fp32) can be faster on CPUs without AVX2
`SHOWNTELL_THREADS`	up to 6	CPU threads for ONNX speech

Pronunciations: put word = spoken form lines in ~/.local/share/showntell/lexicon.txt. A lowercase word matches any capitalisation, and the spoken form may be misaki phonemes between slashes (kubectl = /kjˈubkˌʌtəl/). showntell already knows several hundred technical terms.

Privacy and security

Network: showntell listens on localhost only, checks the Host and Origin of every request, and accepts only JSON POSTs.
Links: walkthrough ids are 128-bit random values; writing needs a separate key that only the agent holds.
Files: code and images are read only from the project folder, and git runs only plumbing commands with repository hooks and diff drivers disabled.
Downloads: the only network traffic is the first-run model download.

See SECURITY.md to report a problem.

Platforms

Platform	Speech	Status
macOS, Apple silicon	Kokoro on MLX	primary
Linux, Windows, Intel Mac	Kokoro on ONNX Runtime (CPU)	supported

English voices only for now. Kokoro's other languages are on the roadmap.

Development

uv sync
uv run pytest                    # fast tests, no GPU needed
uv run showntell serve --speech fake   # run without a voice model

See CONTRIBUTING.md, docs/spec.md and docs/architecture.md.

Licence

MIT. Bundled libraries and downloaded models keep their own licences; see THIRD_PARTY_NOTICES.md.

Available Tools

5 tools

add_slidesAdd slidesA

Append slides to a walkthrough, written in Markdown.

Calls:

Opening: normally sent in start_walkthrough's opening (see its example). Only if it was not sent there, the first call carries it and nothing more: the title slide and one or two short spoken sentences. That call returns when the link is playable, with the full guide; send the link to the user then, before anything else.
All other calls: first one short slide alone, then one to three whole slides. Never resend earlier Markdown. Never split a slide or its code block across calls.
Replies list problems: fix them in later slides, or replace a broken slide with revise_slide.

Format:

Slide: each #, ## or ### heading starts one. Optional attributes: ## Title {#id .build}; .build reveals parts as cues reach them.
Narration: plain paragraphs are spoken, each voiced separately. Put identifiers in backticks; [text]{say="spoken"} fixes pronunciation.
Shown text: > lines are shown, never spoken; under the first heading, one is the subtitle.
Visual: at most one per slide: fenced code, diff, mermaid diagram, math formula, pipe table, list, or image .
Code from disk, with an empty body and the file's own line numbers in the gutter:

Inline code may set start=10.

Diff: python old then python new blocks; diff with -/+ lines, one hunk per slide; or diff file=path rev=A (against the working tree) or rev=A..B.
List: - **Title**: text {#id}; without {#id}, the id is the title, lowercased and hyphenated. 1. items are steps; .cards on the heading shows cards.
Cues are links in narration. The pointer moves when the label's first word is spoken, within the current slide only. label line 12 | #L12-18 a range | label only that text on line 12 | #-L5 old side, #+L7 new side of a diff | #id a list item, card or Mermaid node | #row-2 the second table row, or a {#id} ending its last cell | # the whole visual; label finds that text in it.

ParametersJSON Schema

Name	Required	Description	Default
`handle`	Yes	Handle from start_walkthrough.
`markdown`	Yes	Slides in Markdown: one to three whole slides, nothing already sent. Only when the opening was not sent with start_walkthrough: the first call carries just the title slide and one or two spoken sentences.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the generic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), but the description adds real behavioral context beyond them: the first call returns when the link becomes playable, replies may list problems, and content is append-only ('Never resend earlier Markdown'). These traits are not derivable from the 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 front-loaded and organized under 'Calls:' and 'Format:' headings, and nearly every line is load-bearing specification for the Markdown DSL that the agent cannot infer elsewhere. It is dense rather than padded, though the volume is close to the limit of what belongs inline.

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?

With no output schema, the description compensates by explaining return timing and error behavior, and it covers sequencing across sibling tools, content formats, and cue syntax. An agent has everything needed to invoke the tool correctly on the first try.

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% and both parameters are documented in the schema, so the baseline is 3. The description goes further by spelling out what the `markdown` payload must contain in terms of DSL structure, ordering, and the special-case opening call, which materially improves how the agent constructs the argument.

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?

Opens with a specific verb+resource+format: 'Append slides to a walkthrough, written in Markdown.' The Calls section further distinguishes its role from start_walkthrough (which carries the opening) and revise_slide (which replaces broken slides), so an agent can route between siblings 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.

Usage Guidelines5/5

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

Explicitly states when to use this call vs. alternatives: the opening normally belongs in start_walkthrough's `opening`, and only if omitted does the first add_slides call carry it. It also names revise_slide as the remedy for a broken slide and specifies batch sizing (one short slide, then one to three).

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

finish_walkthroughFinish walkthroughA

Close the walkthrough after its last slide. Records the end questions and returns a summary with any remaining problems. Then tell the user it is finished and give the link.

ParametersJSON Schema

Name	Required	Description	Default
`handle`	Yes	Handle from start_walkthrough.
`questions`	No	Two or three short follow-up questions the viewer might ask next, as a list of strings. Offered at the end of the walkthrough. Optional when the Markdown already lists them under a `.questions` heading; questions passed here replace those.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this mutates state without destroying it; the description is consistent with that. It adds useful behavior (records end questions, returns a summary of remaining problems, then instructs the agent to surface the link), but says nothing about handle validity, repeat-call semantics, or failure modes despite idempotentHint=false.

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?

Three short sentences, front-loaded with the action, then the side effect, then the required post-call user communication. No padding, though the final sentence is an agent instruction rather than tool semantics.

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?

For a mutation tool with no output schema, the description covers what is recorded, what is returned (summary with remaining problems), and what the agent must do next. Missing only error/repeat-invocation behavior, which is a minor gap against otherwise good annotation coverage.

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 100%, so both parameters are already documented, including the fallback rule for the `.questions` heading. The description's 'records the end questions' only echoes the schema, adding no new syntax or format detail.

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?

States a specific verb and resource (close the walkthrough) and pins down lifecycle position with 'after its last slide', which separates it from start_walkthrough and add_slides. It also names what is recorded and returned. It stops short of explicitly naming the sibling it complements.

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

Usage Guidelines3/5

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

'Close the walkthrough after its last slide' implies the correct moment to call it, and it prescribes follow-up behavior (tell the user it's finished, give the link). There is no explicit when-not guidance or statement about what happens if called early or more than once.

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

list_walkthroughsList walkthroughsA

Read-only

List recent walkthroughs with their handles, titles and links. Use it to find the handle of a walkthrough to revise later, including one from an earlier session. Its Markdown source is the resource showntell://walkthroughs/{id}, where id is the part of the handle before the dot.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond them: what the list returns, that it reaches across sessions, and the resource URI (showntell://walkthroughs/{id}) whose id is derived from the handle before the dot. It does not state how many 'recent' items are returned or any paging behavior.

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?

Three short sentences, front-loaded with what it returns, then the use case, then the resource linkage. Every sentence carries information an agent needs and none repeats the schema or annotations.

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?

With no output schema, the description compensates by naming the returned fields and the resource template for retrieving content. For a no-parameter read-only list tool, nothing needed to call or consume it is 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?

The tool takes zero parameters, so the baseline is 4. The description instead explains how the returned handle relates to the downstream resource id, which is the only semantic an agent needs to consume the result.

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 (list walkthroughs) and enumerates the returned fields (handles, titles, links). It is clearly distinguishable from the sibling mutators add_slides, start_walkthrough, revise_slide and finish_walkthrough, which act on a single walkthrough rather than enumerating them.

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?

Explicitly says when to use it: to find the handle needed to revise a walkthrough later, even one from an earlier session, which links directly to revise_slide. There are no competing list siblings to exclude, so no when-not guidance is needed, but the positive use case is stated clearly.

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

revise_slideRevise slideA

Replace one slide, found by its id, with new Markdown. Only narration whose text changed is voiced again; the rest keeps its audio. Omit the heading to keep the slide's title, classes and attributes. Use it for a slide a reply reported as broken, or to rework a finished walkthrough: find its handle with list_walkthroughs and read its Markdown from the resource showntell://walkthroughs/{id}.

ParametersJSON Schema

Name	Required	Description
`slide`	Yes	Id of the slide to replace: its {#id}, or the id generated from its title as named in replies.
`handle`	Yes	Handle from start_walkthrough or list_walkthroughs.
`markdown`	Yes	The complete new slide: heading (optional), visual, shown text and narration. One slide only.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare the mutation profile (readOnlyHint=false, idempotentHint=false) but say nothing about side effects; the description adds the non-obvious behavior that only narration whose text changed is re-voiced while the rest keeps its existing audio, plus the partial-update semantics of omitting the heading. That is exactly the kind of cost/cascade information an agent cannot infer from the schema.

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?

Three sentences, front-loaded with the core action, then behavior, then usage and discovery path. No filler and nothing redundant with the schema or annotations.

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?

With no output schema the description must carry the burden, and it covers discovery of the handle, id resolution, partial-update rules and audio side effects. It stops short of saying what a successful revision returns (e.g. new revision/version or updated id) or how an unknown slide id fails.

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, but the description adds real semantics on top: omitting the heading preserves the slide's title, classes and attributes, which tells the agent what the optional heading in 'markdown' actually does. The slide-id lookup semantics are already fully documented in 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 precise verb and resource ('Replace one slide ... with new Markdown') and constrains scope to a single slide found by id. It is immediately distinguishable from add_slides, list_walkthroughs and the other siblings.

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?

Gives two concrete triggering conditions ('a slide a reply reported as broken', 'rework a finished walkthrough') and routes the agent to the prerequisite tools: find the handle with list_walkthroughs and read the Markdown from showntell://walkthroughs/{id}.

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

start_walkthroughStart walkthroughA

Create a narrated walkthrough. Pass its opening in opening: the reply then comes once that is voiced, with the handle, the playable link and the full authoring guide. Send the link to the user at once, in a message, before your next tool call; they watch while you add the body with add_slides. Without opening, the reply is short and your first add_slides call must carry the opening instead.

ParametersJSON Schema

Name	Required	Description	Default
`frame`	No	Slide shape: landscape (default, 1280×720), square (960×960) or portrait (720×1280, for phones).	landscape
`speed`	No	Speech rate from 0.8 to 1.3; 1.0 is normal.
`title`	Yes	Walkthrough title, shown on the title slide and in the player.
`voice`	No	English Kokoro voice id. Omit for the default. Voices: af_heart, af_bella, af_nicole, af_aoede, af_kore, af_sarah, af_nova, af_sky, af_alloy, af_jessica, af_river, am_michael, am_fenrir, am_puck, am_echo, am_eric, am_liam, am_onyx, am_adam, bf_emma, bf_isabella, bf_alice, bf_lily, bm_george, bm_fable, bm_lewis, bm_daniel.
`opening`	No	The opening in Markdown, voiced before this call returns: a `#` title heading, an optional `>` subtitle line, then one or two short spoken sentences as a plain paragraph. Nothing more; the body goes in add_slides. Example: # How the retry loop works > Backoff in the HTTP client A failed request can be sent up to four times. We'll follow one through the client.
`project_dir`	No	Absolute path of the project. Code blocks with file= and image paths are read from it and must stay inside it. Defaults to the client's root, then the server's working directory.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare the mutation profile (readOnly=false, destructive=false, idempotent=false) but say nothing about blocking semantics or output. The description adds the critical behavior that the call blocks until the opening is voiced and returns a handle, a playable link, and an authoring guide — exactly the context annotations cannot provide.

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?

Dense but front-loaded: the core action leads, then the sequencing and the opening/no-opening branch. Every sentence carries operational weight, though the second sentence is long and packs the reply-contents, the immediate-link instruction, and the body-authoring step into one breath.

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?

With no output schema, the description carries the full burden of describing what comes back (handle, playable link, authoring guide) and does so, plus it defines the two response shapes conditioned on `opening`. Nothing an agent needs to invoke and follow up correctly is 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds value by explaining the consequence of supplying versus omitting `opening` (the reply shape and where the opening must then go). That is meaningful semantics beyond the schema's format-and-example text, though it stops short of covering the other five parameters.

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 ('Create a narrated walkthrough') and immediately grounds it against the sibling workflow ('add the body with add_slides'). An agent can distinguish this from add_slides, revise_slide, and finish_walkthrough without opening any schema.

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?

Gives explicit sequencing instructions (send the link at once, in a message, before the next tool call) and branches on the `opening` parameter: with it, the reply is short; without it, the first add_slides call must carry the opening. This is clear when-and-how guidance tied to the sibling tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Oct 16, 2026
- First observedadd_slides
- First observedfinish_walkthrough
- First observedlist_walkthroughs
- First observedrevise_slide
- First observedstart_walkthrough

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.2/5.0

Scored 2026-10-16 15:25 across 5 tools

Disambiguation4/5

Each tool maps to a distinct lifecycle step (start, add, revise, list, finish), so selection is mostly clear. The one blur is that add_slides can optionally carry the opening that start_walkthrough normally owns, creating a documented overlap between the two.

Naming Consistency4/5

All names are snake_case verb_noun (start_walkthrough, add_slides, revise_slide, list_walkthroughs, finish_walkthrough), which is highly predictable. Minor deviation: some nouns are plural (slides, walkthroughs) while others are singular (slide, walkthrough).

Tool Count5/5

Five tools cleanly cover the create/append/edit/list/close workflow for narrated walkthroughs. Each earns its place with no redundant surface.

Completeness4/5

The lifecycle is well covered from creation through finishing and later revision (via list_walkthroughs plus revise_slide). A delete/remove walkthrough operation is absent, but core authoring flows have no dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Screen Browser AOAuth
com.screenbrowser
Narrated demo and tutorial videos of your web app, from a guide or your coding agent.
Browser Automation Multimedia Processing Developer Tools
141
cliphou.se release videos A
se.cliphou
Turn every release into a social video, right in your coding agent.
Image & Video Processing Multimedia Processing Marketing
51
Agent-Native SlidesOAuth
io.github.BuilderIO
Agent-Native Google Slides - generate and edit React presentations
Workplace & Productivity App Automation Design Tools
14,698
Pitch
co.trypitch
Turn URLs, recordings, docs, assets, or ideas into launch films, demo recordings, and decks.
Entertainment & Media Marketing
1

Related MCP Servers

Git Commit Video Walkthrough
Version Control Multimedia Processing Developer Tools
tomatitito
F
license
Not graded
quality
D
maintenance
Generates narrated video walkthroughs of git commits, staged/unstaged changes, or entire codebases with AI-powered analysis, syntax-highlighted code visualization, and text-to-speech narration.
Updated 9 months ago (2026-01-20 22:28 UTC)
-
MCP Walkthrough
Developer Tools Text-to-Speech
Stefan-Nitu
A
license
A
quality
F
maintenance
Enables AI agents to present interactive code walkthroughs with voice narration, opening files, highlighting code, and showing inline explanations with synchronized text-to-speech.
Updated 6 months ago (2026-04-13 09:04 UTC)
5
8 npm
MIT
Flowcastofficial
Coding Agents Multimedia Processing Developer Tools
flowcast-studio
F
license
Not graded
quality
D
maintenance
Turn your AI coding agent into a producer of interactive, narrated walkthroughs — code, whiteboard, and 3D casts, each a single self-contained HTML file that opens in any browser. Runs locally over npx.
Updated 4 months ago (2026-06-30 21:14 UTC)
1
-
CodeTour
Version Control Developer Tools
benstaniford
A
license
A
quality
B
maintenance
Enables LLMs to create animated, narrated tours of GitHub pull requests, with a local browser viewer showing diffs and code highlights while speaking the narration aloud.
Updated 10 days ago (2026-10-06 09:19 UTC)
7
MIT

showntell

Install

How it works

The format

Commands

Settings

Privacy and security

Platforms

Development

Licence

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Flowcastofficial