Whisper Valet

by yashkotha

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: folder queueing, single-file pipeline, status, clip listing, transcript retrieval, report retrieval, configuration, quick transcription, and model listing. While process_audio and transcribe_quick both handle audio, their descriptions draw a clear line between full pipeline and plain synchronous transcription.
Naming Consistency4/5
Most tools follow a verb_noun pattern (process_folder, list_clips, get_transcript, list_models), but a few deviate: 'status' is a bare noun, 'configure' is a bare verb, and 'transcribe_quick' uses an adjective modifier instead of a noun. This is readable and close to consistent, but not perfectly uniform.
Tool Count5/5
With 9 tools, the set is well-scoped for a transcription pipeline. Each tool fills a necessary role in the workflow—from intake (process_*) to monitoring (status) to output retrieval (get_*)—without redundancy or bloat.
Completeness4/5
The core workflow is fully covered: queueing, processing, status, results, and configuration. Missing are management operations like deleting/canceling clips or controlling the watcher, but these are optional extras rather than gaps that would break the primary use case.
Average 3.9/5 across 9 of 9 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the report is per-segment and confidence-related, but does not mention any side effects, permissions, error behavior, or prerequisites beyond the clip being processed.
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?
The description is a single, concise sentence. It is front-loaded with the key output type and scope, with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description does not need to explain return values. It covers the core purpose and a prerequisite (processed clip), but lacks guidance on when to use it vs siblings and does not disclose behavioral details due to missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the burden for parameter meaning. It alludes to the 'clip' being a processed clip, but does not explicitly describe the parameter format, expected identifier, or relationship to the schema property.
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?
The description clearly states the tool returns a 'Full per-segment speaker-confidence report' for a processed clip, which distinguishes it from siblings like get_transcript. The verb is implied but the resource and scope are specific enough.
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?
The description implies usage requires a 'processed clip', giving some context. However, it does not explicitly state when to use this tool versus alternatives such as get_transcript or status, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond what the name implies. With no annotations, it does not state whether the operation is read-only, whether it has side effects, or any performance characteristics.
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?
The description is a single, clear sentence that efficiently communicates the tool's function without unnecessary words.
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?
While minimal, the tool has no parameters and an output schema exists to cover return-value details. The description covers the essential listing purpose, though a bit more context about what 'processed' means could help.
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 has zero parameters, so the description does not need to explain parameter semantics. Schema coverage is 100% vacuously, and the baseline for zero-parameter tools is 4.
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?
The description clearly states the tool lists all processed clip folders with their status, using a specific verb and resource. It distinguishes from sibling tools like status (which likely targets a single clip) and process_folder (which processes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as status. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It indicates the output includes speaker labels and requires a processed clip, but doesn't mention error conditions, permissions, or read-only nature. Significant gap for a tool with no annotations.
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?
The description is a single, front-loaded sentence with no filler. It conveys the resource and a cross-reference efficiently.
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?
The tool is simple with one parameter and an output schema exists, so the description doesn't need to detail return values. It covers what the tool returns, the input requirement, and points to where to get the input. It's adequate for a getter, though it doesn't address error handling.
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?
The schema has zero description coverage for the 'clip' parameter. The description compensates by indicating it should be a processed clip from list_clips(), which adds meaning beyond the bare parameter name. However, it doesn't specify the expected format or types beyond the schema's string type.
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?
The description clearly identifies the tool as returning a speaker-labeled transcript for a processed clip. It points to list_clips() for context, which helps distinguish it from listing tools. However, it lacks an explicit verb like 'retrieves'.
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?
The reference to list_clips() implies the prerequisite of having a processed clip ID, but it doesn't explicitly state when to prefer this over alternatives like get_report. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not explicitly confirm read-only behavior or other side effects, but the term 'status' and the listed observation categories suggest a non-mutating overview. It does not describe output format or potential delays, leaving some behavioral uncertainty.
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?
The description is a single, compact sentence with a colon-separated list. Every word contributes; no filler.
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 no-parameter status tool with an output schema, the description sufficiently enumerates the data categories returned. It lacks explicit usage notes, but that's covered elsewhere. It's appropriately complete for its simplicity.
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 has zero parameters, so the schema is inherently complete. The description adds no parameter semantics but none are needed. Baseline 4 applies.
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?
The description clearly identifies the tool as providing pipeline status and enumerates specific components (inbox queue, watcher activity, recent clips, log tail). This distinguishes it from siblings like process_folder or list_clips, though it lacks an explicit verb like 'retrieve' or 'display'.
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?
No explicit usage guidance is provided; it's implied that this is for checking overall pipeline health rather than using specific getter tools. There's no exclusion or alternative mention, so it's merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It states that files are queued and non-recursive, but does not disclose side effects (e.g., whether it mutates state by adding jobs), permissions required, error behavior, or handling of unsupported formats. 'Queue' implies an action but leaves behavioral outcomes ambiguous.
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?
The description is a single sentence with no filler words. It is front-loaded with the action and resource, making it highly scannable.
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 simple tool with one parameter and an existing output schema, the description covers the primary function. It lacks notes on error conditions or prerequisites, but the core behavior is clear. Given the low complexity and presence of output schema, it is sufficiently complete.
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 schema has 0% description coverage, leaving the meaning of 'path' open. The description compensates by clarifying that the path is a folder containing audio/video files. However, it does not specify path format, requirements, or edge cases. For a single parameter, this is adequate but not exhaustive.
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 uses a specific verb 'Queue' and identifies the resource: every audio/video file in a folder, with the qualifier 'non-recursive.' It goes beyond the name by specifying the file types and the non-recursive scope, which distinguishes it from sibling tools like process_audio that likely handle individual files.
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?
The description does not explicitly state when to use this tool over alternatives like process_audio. It implies usage for folder-level batch queuing but provides no exclusions or alternative guidance. The only context is the 'non-recursive' qualifier, which informs scope but not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It usefully discloses synchronous behavior and lack of enhancement/diarization, but it does not mention potential side effects, file writes, permissions, or failure behavior. That leaves a meaningful transparency gap.
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?
The description is three short sentences, front-loaded with the core purpose. Every sentence adds value: what the tool does, when not to use it, and how to override the model. No filler or redundancy.
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?
Given the simple tool shape (2 parameters, output schema present) and clear alternative hint, the description is mostly complete. The main gaps are explicit path semantics and side-effect disclosure, but overall it provides enough context for a small tool.
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 coverage is 0%, so the description must compensate. It explains the model parameter with the engine:model-id format, and 'short clip' implies path points to an audio/video file, but the path parameter is not explicitly defined and no default model behavior is described. Partial compensation.
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 clearly states a specific verb and resource: 'plain synchronous transcription of a short clip via the MacWhisper CLI.' It distinguishes itself from sibling tools by explicitly saying 'no enhancement, no diarization, just text now' and even names process_audio as the alternative.
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?
The description provides explicit usage guidance: use this tool for quick, plain transcription; use process_audio() instead for noisy audio or speaker labels. This gives clear when-to-use vs. alternative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature ('List'), the scope ('downloaded'), and the key output detail ('active one marked'). This is sufficient for a zero-parameter list operation where no destructive or side-effect behavior exists.
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?
A single, front-loaded sentence with no wasted words. It states exactly what the tool does and adds one useful detail about the active model marker.
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 the zero-parameter simplicity and the presence of an output schema, the description is fully complete. It covers the tool's purpose and output nuance with no gaps.
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 has zero parameters, and the schema reflects that with empty properties. The description correctly omits parameter details; baseline 4 applies as no parameter explanation is needed.
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 uses the specific verb 'List' with a clear resource: 'MacWhisper's downloaded transcription models'. The parenthetical '(active one marked)' adds distinguishing detail, separating it from sibling tools like list_clips or status.
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?
The tool's use is self-evident: listing models. There is no explicit alternative or exclusion, but the description implies clear context—if you need to see downloaded models, this is the tool. No competing sibling tool covers this function, so additional guidance is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the async behavior ('Returns immediately'), the delayed result location ('<outbox>/<clip>/'), and the polling pattern. This is strong behavioral disclosure, though it omits error cases or permissions, which would require additional context.
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?
The description is two focused sentences: the first states the purpose and pipeline, the second explains the asynchronous workflow and where results land. No filler words, and all information is valuable.
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?
For a tool with one parameter, no annotations, and an output schema, the description covers the essential workflow: what is queued, the pipeline stages, the immediate return, the output location, and how to retrieve results. It is complete for a user to use correctly without further documentation.
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 schema only shows a required 'path' string with 0% coverage. The description compensates by clarifying that 'path' points to an audio/video file to be queued for the pipeline. Although it doesn't detail format constraints, it gives sufficient meaning for the single parameter.
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 states a specific verb ('Queue') and resource ('one audio/video file') with explicit pipeline steps: voice isolation -> transcription -> speaker diarization. This clearly distinguishes it from siblings like process_folder (for folders) and transcribe_quick (likely a lighter pipeline).
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?
The description gives clear context: use for a single audio/video file requiring the full pipeline, and it instructs to poll status() for results. It doesn't explicitly name alternatives or exclusions, but the sibling set and phrasing make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It details the behavior of num_speakers modes (auto, forced N, MIN-MAX), the matching rule for labels, the fallback to generic names, the semantics of passing empty strings, and the return of the active configuration. This is rich, non-obvious behavioral disclosure.
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?
The description is front-loaded with the core purpose and then systematically explains parameters. Each sentence provides necessary information: examples, edge cases, and default behavior. There is no filler or redundancy; the length is justified by the complexity of the two parameters.
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?
The tool has no annotations and a sparse schema, but the description fully compensates. It explains all parameter semantics, the tool's persistence effect, and its return value. Output schema exists, so the absence of return format details is not a gap. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain the parameters and does. It defines valid formats for num_speakers with examples, explains labels structure and ordering, and describes conditional behavior. This exceeds the schema's minimal type-only information.
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 opens with the specific action 'Adjust diarization for FUTURE clips', clearly identifying the resource (diarization settings) and scope (future clips). This distinguishes configure from siblings like process_folder, process_audio, and status, which handle processing or retrieval rather than configuration.
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?
The description clearly indicates that this tool affects future clips, providing the context of when to use it. It also explains how to leave a setting unchanged (pass ""), which is a usage guideline. However, it does not explicitly compare itself to alternatives or state when not to use it, though the 'FUTURE' qualifier gives solid contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![whisper-valet MCP server](https://glama.ai/mcp/servers/yashkotha/whisper-valet/badges/card.svg)](https://glama.ai/mcp/servers/yashkotha/whisper-valet)

Score Badge

Copy to your README.md:

[![whisper-valet MCP server](https://glama.ai/mcp/servers/yashkotha/whisper-valet/badges/score.svg)](https://glama.ai/mcp/servers/yashkotha/whisper-valet)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yashkotha/whisper-valet'

If you have feedback or need assistance with the MCP directory API, please join our Discord server