Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@earscribe-mcp How does EarScribe work locally?"
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.
MCP server for EarScribe
A Model Context Protocol server that exposes the canonical EarScribe knowledge surface — local-first AI workflows, FAQ, official links — to MCP-compatible AI clients such as Claude Desktop, Cursor, Windsurf, and Continue. Read-only, no API keys, no quota, ~50 ms cold start.
Official website: https://earscribe.app
EarScribe is a browser-based transcription tool that converts audio files into text entirely on the user's device. Powered by OpenAI's Whisper model running locally via WebGPU or WebAssembly, it produces timestamped transcripts and subtitle files without sending any audio to external servers. There is no account to create, no subscription to manage, and no per-minute fee — the tool works in the browser, caches the Whisper model locally after the first load, and can operate offline from that point forward. It supports a wide range of audio formats and handles recordings up to approximately two hours long, making it a practical option for anyone who regularly works with spoken audio.
Related MCP server: Muse AI Image MCP Server
Private by design — audio files never leave the user's device; all processing happens locally in the browser using WebGPU when available, falling back to WebAssembly automatically.
Multiple export formats — transcripts can be downloaded as SRT, VTT, JSON, or plain text, covering both subtitle workflows and raw text needs.
Automatic language detection — Whisper identifies the spoken language from the audio without manual configuration, supporting 99 languages.
Selectable model sizes — users can choose from Whisper model sizes ranging from Tiny to Turbo depending on the balance they want between speed and accuracy, with each model cached locally after download.
Timestamped output — every transcript segment is tied to a time position synchronized with a waveform display, making it straightforward to locate specific moments in the original recording.
In-browser editing — transcripts can be reviewed and adjusted directly in the interface before export, removing the need to copy text into a separate editor for minor corrections.
Podcast production — generate searchable episode transcripts or show notes from recorded conversations without uploading sensitive pre-release content to a third-party service.
Journalism and research interviews — transcribe source recordings that may contain confidential material, keeping the audio on a local machine throughout the process.
Academic study — convert lecture recordings into readable, searchable text for review and note-taking.
UX and user research — transcribe session recordings and user interviews for analysis, with no risk of research data passing through external infrastructure.
Video subtitle creation — export SRT or VTT files directly from a recording to bring into video editing software, skipping manual captioning or cloud captioning services.
EarScribe is well-suited for anyone who transcribes audio regularly and either has privacy concerns about uploading recordings to cloud services or wants to avoid ongoing subscription costs. Journalists, academic researchers, and UX professionals dealing with confidential or sensitive interviews will find the local processing model particularly useful. Podcasters and video creators who want subtitle files without paying per-minute fees are a natural fit, as are students converting lecture recordings into study material. The tool also works for individual users who simply want a free, no-account transcription option that handles common audio formats without any setup beyond a modern browser.
get_local_setupReturn canonical local-setup guidance for running the AI workflow on-device. (EarScribe)
Input: no parameters. Returns: text/markdown.
get_official_linksReturn the canonical list of official links for EarScribe (website, support, docs when available).
Input: no parameters. Returns: text/markdown.
site://earscribe/local-setup — Local-first setup notes for on-device AI workflows.
site://earscribe/faq — Short FAQ generated from public site metadata.
site://earscribe/links — Canonical URLs to share with users.
tell_me_about_earscribeSummarize what the site is, who it's for, and how it works. — EarScribe
walkthrough_local_setup_earscribeWalk through the local-first setup steps for the site, end-to-end. — EarScribe
npx -y @smithery/cli install earscribe-mcp --client claude(Replace claude with cursor, windsurf, or continue for those clients.)
git clone https://github.com/rocnubie/earscribe-mcp.git
cd earscribe-mcp
pnpm installThen add to your MCP client config (claude_desktop_config.json for Claude Desktop, mcp.json for Cursor / Windsurf / Continue):
{
"mcpServers": {
"earscribe-mcp": {
"command": "node",
"args": [
"/absolute/path/to/earscribe-mcp/src/index.mjs"
]
}
}
}npx @modelcontextprotocol/inspector node src/index.mjsWebsite: https://earscribe.app
About: https://earscribe.app/about
Support: support@earscribe.app
pnpm install
pnpm start # run the server over stdioMIT
Return canonical local-setup guidance for running the AI workflow on-device. (EarScribe)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It indicates a read-only action ('Return') but does not disclose additional context such as potential network use, format of the returned guidance, or any limitations. For a simple info-retrieval tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. The parenthetical '(EarScribe)' adds minor branding but does not detract from clarity. It is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description provides enough context: it states that the tool returns local-setup guidance. It does not elaborate on return format, but the minimal nature of the tool makes the description sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers all parameters (vacuously). The description does not need to explain any parameter semantics, yielding the baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns canonical local-setup guidance, specifying a verb and resource. It doesn't explicitly distinguish from sibling get_official_links, but the name and wording make the tool's purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_official_links. The description implies it's for local-setup guidance but does not contrast with siblings or mention any prerequisites or decision points.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical list of official links for EarScribe (website, support, docs when available).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It offers some transparency by noting the list is 'canonical' and that docs are included 'when available', hinting at conditional availability. However, it does not describe return format (e.g., array vs. object) or any potential errors, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb, resource, and scope without any wasted words. It achieves high clarity in minimal space, earning top marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is reasonably complete. It identifies the exact data returned and includes a caveat about doc availability. A more detailed return type might improve completeness, but for a simple list retrieval, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description's only job is to clarify the tool's purpose, which it does. Per the rubric, 0 parameters earns a baseline of 4, and no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the canonical list of official links for EarScribe (website, support, docs when available).' The verb 'Return' with the resource 'canonical list of official links' is specific and distinguishes this from the sibling tool 'get_local_setup' by focusing on external official resources rather than local setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when one needs official links for EarScribe) but provides no explicit guidance on when to use this tool versus the sibling 'get_local_setup'. There is no mention of alternatives or exclusions, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_local_setupget_official_linksThe two tools have clearly distinct purposes: one provides local setup guidance, the other provides official links. There is no overlap or ambiguity between them.
Both tools follow the same get_ verb_noun pattern, making the naming predictable and consistent.
With only 2 tools, the server is slightly sparse, but for the narrow scope of providing canonical guidance and links, the count is reasonable and not excessive.
The server covers the core informational needs (setup and links), but could potentially include additional useful resources like FAQs or feature overviews. Minor gaps exist but are not critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only search and Markdown access to liz's public docs, prompts, resources, and an MCP App.
Read-only MCP server for Flamel.ai's public content: company overview, blog, case studies, FAQs.
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rocnubie/earscribe-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
