Ferry
Related Servers
Alternatives to Ferry
No user-submitted related servers found.
Related Servers
- AlicenseAqualityBmaintenanceEnables 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.7MIT
- AlicenseAqualityFmaintenanceEnables AI agents to present interactive code walkthroughs with voice narration, opening files, highlighting code, and showing inline explanations with synchronized text-to-speech.536 npmMIT
- AlicenseAqualityAmaintenanceEnables coding agents to turn explanations of code, pull requests, or concepts into narrated slide walkthroughs voiced locally with Kokoro, returning a link that starts playing in about a second while the remaining slides are still being written. Slides are grounded in real files and git history, checked for errors, and exportable as static folders with captions.72MIT

Flowcastofficial
FlicenseNot gradedqualityDmaintenanceTurn 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.1-- FlicenseNot gradedqualityDmaintenanceGenerates 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.-
- AlicenseNot gradedqualityBmaintenanceEnables coding agents to scaffold, preview, inspect, navigate, capture, and build interactive HTML presentations authored as React/TSX source files. It operates the local presenter—keys, step tabs, URLs, and tools share one position—while agents edit the source directly.22 npmMIT
TDQS
Scored across 18 tools
Each tool targets a distinct resource or action, from deck and slide CRUD to git inspection and viewer feedback. The only subtle overlap is between get_feedback and wait_for_feedback, but their descriptions clearly distinguish immediate retrieval from blocking wait, and resolve_feedback vs reply_feedback are similarly well separated.
All operational tools follow a consistent snake_case verb_noun pattern (e.g., create_deck, add_slides, update_slide, wait_for_feedback). The lone deviation is authoring_guide, which is a noun phrase rather than an action, but the overall convention is predictable.
18 tools is slightly above the ideal 3-15 range, but the server's domain is genuinely broad: deck lifecycle, slide editing, git diff import, viewer control, and feedback handling. Each tool earns its place, though a few could conceivably be consolidated.
The surface covers full CRUD for decks and slides, list/open/export operations, git change inspection and skeleton deck generation, plus a complete feedback loop (wait, get, resolve, reply). No obvious dead ends exist for the stated purpose of building and refining code-explanation decks.