Accurate meeting transcription through the Model Context Protocol (MCP): speaker labels, multilingual coverage, and hosted Whisper-class models without running GPUs locally.
GhostMinutes MCP is an audio transcription MCP that pairs beautifully with assistants: paste a URL, poll status, summarize transcripts, and inspect credits without leaving your IDE.
Use this Cursor MCP server snippet inside Cursor → Settings → MCP → JSON editor:
{
"mcpServers": {
"ghostminutes": {
"command": "npx",
"args": ["-y", "ghostminutes-mcp"],
"env": {
"GHOSTMINUTES_API_KEY": "gm_replace_with_your_key"
}
}
}
}Removing GHOSTMINUTES_API_KEY keeps you on the anonymous tier while you evaluate meeting transcription workflows.
Related MCP server: audio-transcription-mcp
Drop the following Claude MCP server stanza into claude_desktop_config.json:
{
"mcpServers": {
"ghostminutes": {
"command": "npx",
"args": ["-y", "ghostminutes-mcp"],
"env": {
"GHOSTMINUTES_API_KEY": "gm_replace_with_your_key"
}
}
}
}Restart Claude Desktop after edits so stdio transports reconnect cleanly.
Continue reads the same stdio definition:
{
"experimental": {
"modelContextProtocolServers": [
{
"transport": {
"type": "stdio",
"command": "npx",
"args": ["-y", "ghostminutes-mcp"],
"env": {
"GHOSTMINUTES_API_KEY": "gm_replace_with_your_key"
}
}
}
]
}
}Swap in absolute paths only if npx is unavailable inside your sandbox.
ChatGPT custom connectors vary by rollout region. Where MCP-over-stdio is unavailable, proxy through your MCP host or paste transcripts retrieved via get_transcript. When stdio bridging is supported, mirror the Claude snippet:
{
"command": "npx",
"args": ["-y", "ghostminutes-mcp"],
"env": {
"GHOSTMINUTES_API_KEY": "gm_replace_with_your_key"
}
}Document any gateway ports carefully—secrets stay local while transcripts upload through GhostMinutes APIs.
This npm package exposes stdio MCP using @modelcontextprotocol/sdk. Generic HTTP integrations should terminate TLS upstream (Streamable HTTP lives on GhostMinutes infrastructure separately). Point automation at:
GHOSTMINUTES_API_URL=https://ghostminutes-backend-production.up.railway.app/apiThen attach whatever MCP gateway your ChatOps stack expects.
Speaker diarization differentiates voices for meeting transcription summaries.
99+ languages cover global teams without swapping Whisper MCP forks.
Hosted infrastructure avoids shipping massive models with every developer laptop.
Free starter credits keep hobbyists unblocked while Pro unlocks heavier audio loads.
Model Context Protocol native tooling means one install for Cursor, Claude, Continue, or any spec-compliant host.
Compared with a barebones Whisper MCP, GhostMinutes MCP layers account management, credits, summarization helpers, and consistent job tracking.
Pair transcribe_audio_url with get_transcription_status whenever assistants cannot await five-minute synchronous polls—most Cursor MCP server automations prefer this split because it mirrors asynchronous CI patterns.
Need deterministic summaries? Fetch transcripts first (get_transcript), stash them in version control redacted snippets, then feed curated excerpts into summarize so Model Context Protocol audit trails stay reproducible.
Meeting transcription pipelines benefit from tagging URLs with HTTPS endpoints only; GhostMinutes rejects flaky redirects early to save Whisper MCP troubleshooting loops.
Because MCP-compatible hosts sandbox stdio pipes differently, keep logs on stderr inside downstream forks—GhostMinutes MCP itself never prints informational noise on stdout.
When benchmarking GhostMinutes MCP versus generic Whisper MCP integrations, capture wall-clock latency for both anonymous and authenticated tiers separately—credit-aware queues behave differently under burst uploads.
Power users orchestrating ChatGPT custom connector gateways should terminate TLS at their proxy while forwarding Authorization: Bearer gm_* headers verbatim to preserve quota attribution.
Finally, bookmark examples/ for ready-to-paste snippets tailored to Cursor, Claude Desktop, and Continue—each file mirrors best practices validated against @modelcontextprotocol/sdk v1.x transports.
Tool | Description | Parameters | Auth required |
| Submit a public audio/video URL for asynchronous transcription |
| No (optional key) |
| Submit a URL and poll up to five minutes |
| No (optional key) |
| Poll transcription job metadata |
| No (optional key) |
| List saved jobs for the signed-in workspace | (none) | Yes |
| Download a transcript payload by id |
| Yes |
| Remove a transcript |
| Yes |
| Hosted AI summarization via |
| Yes |
| Inspect remaining GhostMinutes quota | (none) | Yes |
Anonymous traffic is perfect for prototypes; authenticated tiers unlock persistence and collaboration.
Tier | Monthly credits | Typical best for | Notes |
Anonymous | 10 credits / month / IP | Quick experiments without signup | Ideal for Whisper MCP comparisons |
Free (signed in) | 10 credits / month | Individuals testing meeting transcription | Includes dashboard access |
Pro | 300 credits / month ($9.99) | Agencies & power users | Predictable throughput |
Rule of thumb: 1 GhostMinutes credit ≈ 6 minutes of audio. Actual usage varies with diarization complexity and retries.
Need more? Visit ghostminutes.com for the latest bundles and promotions.
Exec recap — “Call transcribe_audio_url_sync on this all-hands MP4, then summarize with focus CEO decisions only.”
Support QA — “List transcripts via list_transcripts, fetch #472 with get_transcript, highlight escalations.”
Localization smoke test — “Send transcribe_audio_url with language es, poll using get_transcription_status, verify diarized segments.”
Budget guardrail — “Run get_credits, refuse further audio transcription MCP jobs if fewer than two credits remain.”
These prompts showcase how GhostMinutes MCP complements Cursor MCP server workflows without bouncing between terminals.
Anonymous usage works for lightweight Whisper MCP comparisons. Sign up when you want authenticated tools (list_transcripts, summarize, higher reliability dashboards).
GhostMinutes stores transcripts according to the production privacy policy linked from ghostminutes.com. Prefer ephemeral URLs or rotate keys after audits.
The backend mirrors Whisper-class multilingual coverage—omit language for autodetection or pass ISO 639-1 codes for forced alignment.
Upgrade inside the GhostMinutes billing portal or rotate teams onto Pro seats when meeting transcription volumes spike.
This repo focuses on the hosted GhostMinutes stack. Enterprise self-hosting questions should route through Rocketech support channels.
Dimension | GhostMinutes MCP | Typical Whisper MCP |
Speaker diarization | First-class job metadata | Rarely bundled |
Credits & auth | Built-in GhostMinutes API | Bring-your-own infra |
Summaries | Native | Usually manual prompts |
Meeting transcription UX | Designed around job lifecycle | Often single-shot |
Claude / Cursor parity | Same config across hosts | varies per template |
Variable | Required | Description |
| No | API key ( |
| No | Override API base if you proxy through a private edge. Defaults to Railway production |
Reference server.json for the canonical MCP Registry manifest submitted to registry.modelcontextprotocol.io.
Batch URL ingestion for playlist-style meeting transcription imports.
Richer structured outputs for diarization segments and per-speaker timelines.
Tooling for redacted exports (PII masking) prior to summarization.
Expanded automated tests covering edge cases from the hosted API.
Additional documentation for IDE-specific authentication patterns.
Companion observability dashboards describing MCP traffic separately from HTTP dashboards.
Issues and PRs are welcome in Rocketech-Software-Development/ghostminutes-mcp. Please include repro steps, sample URLs (sanitized), and expected MCP tool outputs. CI runs npm run build and npm test on every push to main.
MIT — see LICENSE.
GhostMinutes MCP remains independent from upstream Whisper releases; Rocketech ships compatibility-tested bundles so Cursor MCP server upgrades stay boringly predictable.
Commercial support, custom SLAs, and private Model Context Protocol gateways are available—email the GhostMinutes team via the website contact form.
Delete a transcription job from your GhostMinutes account (destructive).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transcription job id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only (readOnlyHint=false). The description adds the explicit '(destructive)' label, which is helpful, but lacks details on irreversibility, permissions, or effects on related data.
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 concise sentence that immediately conveys the action and resource, with no superfluous words.
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?
For a simple delete operation with one parameter and no output schema, the description adequately covers purpose and destructiveness. However, it omits mention of outcome (e.g., success response) or error cases, which would be helpful.
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?
Schema description coverage is 100% (the 'id' parameter is described as 'Transcription job id'). The tool description does not add any additional semantics beyond what the schema already provides.
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 explicitly states the action 'delete' and the resource 'transcription job', and distinguishes it from sibling tools like get_transcript or list_transcripts by noting destructiveness.
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 on when or why to use this tool beyond stating it deletes a job. Does not mention prerequisites, conditions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show remaining GhostMinutes credits for the authenticated API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only (readOnlyHint=true). The description adds context that it shows credits specific to the authenticated API key, which is helpful. No contradictions.
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 sentence that efficiently communicates the tool's purpose without any extraneous content.
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?
For a simple read-only tool with no parameters and no output schema, the description sufficiently covers its function. It is complete enough for an agent to understand and use correctly.
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?
No parameters exist in the schema, and the description does not need to add parameter information. Baseline score of 4 is appropriate.
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 uses a specific verb ('Show') and resource ('remaining GhostMinutes credits'), clearly indicating what the tool does. It distinguishes itself from sibling tools which are all about transcripts.
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 does not provide explicit guidance on when to use this tool versus alternatives. While the lack of alternatives for credits makes it somewhat obvious, the description doesn't state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a saved transcription job by id from your GhostMinutes account.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transcription job id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true). Description adds nothing beyond, e.g., no mention of error behavior or required job state.
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?
One sentence, front-loaded with key information, no wasted words.
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?
Adequate for a simple fetch tool with one param and annotations, but lacks description of return content, which is useful since no output schema.
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?
Schema coverage is 100%, so description need not add much. It repeats 'id' as 'Transcription job id', providing no additional semantics.
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?
Description clearly states verb 'fetch', resource 'transcription job', and scope 'by id from GhostMinutes account'. It distinguishes from siblings like 'delete_transcript' and 'list_transcripts'.
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 explicit when-to-use or alternatives. Implied by purpose, but lacks guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll GhostMinutes for transcription progress and results using job_id returned by transcribe_audio_url.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | job_id returned by transcribe_audio_url |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes polling behavior and that it returns progress and results, complementing readOnlyHint and openWorldHint annotations. No contradictions.
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?
Single sentence with clear verb (Poll) and resource (transcription progress/results). No extraneous text.
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?
Functional but lacks detail on return structure (e.g., progress fields, result format) given no output schema. Adequate for basic usage.
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?
Schema coverage is 100% and description adds no extra meaning beyond schema's job_id description. Baseline 3 applies.
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?
Clearly specifies polling for transcription progress/results using job_id from transcribe_audio_url. Differentiates from siblings like transcribe_audio_url (creation) and get_transcript (final output).
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?
Explicitly states prerequisite: job_id from transcribe_audio_url, implying post-creation usage. Lacks explicit when-not-to-use or alternatives like get_transcript, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your transcription jobs on GhostMinutes (authenticated accounts only).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only (readOnlyHint=true). The description adds a critical behavioral constraint: 'authenticated accounts only'. No contradictions with annotations. Additional context about listing scope is provided.
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 conveys the essential purpose and constraint. Every word earns its place; there is no fluff or redundancy.
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?
For a parameterless list operation with clear annotations, the description is complete. It includes authentication context, and the absence of output schema is acceptable for a simple listing tool. No additional information is necessary.
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 schema coverage is 100% trivially. According to rules, baseline for 0 parameters is 4. No parameter information is needed, and the description does not add any, which is appropriate.
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 verb 'list', the resource 'transcription jobs', and the context 'on GhostMinutes (authenticated accounts only)'. This differentiates it from sibling tools like 'get_transcript' (single) and 'delete_transcript'.
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 by noting authentication requirement, but does not provide explicit guidance on when to use this tool versus alternatives like 'get_transcript' or 'delete_transcript'. No when-not-to-use or alternative names mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize transcript text via GhostMinutes hosted AI (/api/ai/chat). Paste transcript content or downstream output from get_transcript.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Transcript or notes text to summarize. | |
| focus | No | Optional guidance (e.g. "action items only", "executive summary"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only is false and open-world is true. Description adds that it uses a specific AI endpoint (/api/ai/chat), but does not detail potential costs, rate limits, or text length constraints.
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?
Two sentences, no wasted words. Purpose and source guidance are front-loaded and clear.
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?
Tool is simple with two parameters. Description mentions the AI endpoint, which implies cost or side effects. Lacks return format details, but schema is complete and tool is straightforward.
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?
Schema covers both parameters with descriptions. The description adds minimal value beyond the schema, such as example values for the focus parameter.
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 summarizes transcript text via GhostMinutes hosted AI, distinguishing it from sibling tools like get_transcript which retrieves raw text.
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?
Explicitly advises to paste transcript content or use output from get_transcript, providing clear context. Does not mention when to avoid using it, but purpose is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a publicly-accessible audio or video URL for transcription with speaker diarization. Returns a job_id you can poll with get_transcription_status, or use transcribe_audio_url_sync to wait synchronously.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL of audio/video file (mp3, m4a, wav, mp4, webm, etc.) Max 200 MB. | |
| language | No | ISO 639-1 code, e.g. "en", "es". Auto-detected if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation) and openWorldHint=true (unknown side effects). The description adds that transcription creates a job and returns a job_id, but does not elaborate on potential side effects or permissions needed. With moderate annotation coverage, the description adds minimal behavioral context beyond the async nature.
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 efficiently communicates the core action, return value, and a key alternative. Every part serves a purpose with no waste.
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?
For a simple tool with 2 parameters (one required) and no output schema, the description covers the purpose, async behavior, and how to handle the result. It lacks details on error scenarios or limits, but is otherwise complete enough for an agent to use correctly.
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?
Schema description coverage is 100%, so baseline is 3. The description does not add meaningful information beyond what the schema already provides for the parameters. It mentions 'publicly-accessible' and 'speaker diarization' but these are not parameter-specific.
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 action ('Submit a publicly-accessible audio or video URL') and the purpose ('transcription with speaker diarization'). It also distinguishes the asynchronous nature from the synchronous sibling tool transcribe_audio_url_sync and mentions the resulting job_id for polling with get_transcription_status.
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 provides explicit guidance on when to use this tool (async submission) versus alternatives: poll with get_transcription_status or use transcribe_audio_url_sync for synchronous waiting. It does not explicitly state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a URL for transcription and poll until completion (up to 5 minutes). Prefer transcribe_audio_url for faster handoff when clients can poll.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL of audio/video file (mp3, m4a, wav, mp4, webm, etc.) Max 200 MB. | |
| language | No | ISO 639-1 code, e.g. "en", "es". Auto-detected if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses polling behavior and timeout up to 5 minutes, adding value beyond annotations (readOnlyHint=false, openWorldHint=true). No contradiction; description is consistent and informative.
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?
Two sentences, front-loaded with action and time limit, no wasted words. Efficient and clear structure.
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?
Tool description is complete for a synchronous transcription poll, but lacks mention of return format or error handling. Adequate given no output schema.
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?
Schema covers 100% of parameters with descriptions for 'url' and 'language'. Description does not add extra parameter details beyond schema, so baseline 3 is appropriate.
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?
Description clearly states 'Submit a URL for transcription and poll until completion', giving a specific verb+resource. It distinguishes from sibling transcribe_audio_url by noting the synchronous nature.
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?
Explicit advice to prefer transcribe_audio_url for faster handoff when clients can poll, and mentions polling up to 5 minutes, providing clear context for when to use this versus the alternative.
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.1delete_transcriptget_creditsget_transcriptget_transcription_statuslist_transcriptssummarizetranscribe_audio_urltranscribe_audio_url_syncEach tool has a distinct purpose: delete, list, get, status polling, credit check, summarize, and two transcribe options differentiated by sync/async. No overlap.
Most tools follow verb_noun pattern (e.g., delete_transcript, get_credits), but 'summarize' is a single verb and 'get_transcription_status' uses 'transcription' instead of 'transcript', introducing slight inconsistency.
8 tools is well-scoped for a transcription service: CRUD operations, credits, status, AI summarization, and both async/sync submission. No bloat or deficiency.
Covers full workflow: submit (both modes), poll, get, list, delete, summarize, and credits. Missing an update operation, but that is not essential for transcripts. Minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
Memoket — access your recording transcripts, summaries, and key takeaways over MCP.
AI transcription from URLs or files. 119 languages, diarization, SRT/VTT/text export.
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rocketech-Software-Development/ghostminutes-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
