pepys-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct operation: uploading, transcribing (single/batch), fetching results, exporting, searching, listing, and credit checking. No functional overlap exists, allowing clear selection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_transcription, list_transcriptions, upload_file). The verb transcribe is used alone for the primary action, but its derived tools (transcribe_podcast_feed) remain consistent.
Tool Count5/5
With 9 tools, the set is well-scoped for a transcription server. Each tool serves a distinct and necessary purpose without redundancy, fitting the typical optimal range of 3-15 tools.
Completeness4/5
The tool set covers the full transcription workflow: upload, transcribe (single and batch), fetch, export, search, and credit management. The only minor gap is the absence of a delete/reset tool, but this is not essential for the core use case.
Average 4.2/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
This repository includes a glama.json configuration file.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are rich: readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description confirms the read-only listing behavior but adds minimal extra context beyond the annotations. It does not contradict annotations, but it doesn't expand significantly on behavioral traits such as response format or error conditions.
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, well-structured sentence that immediately conveys the action, input, output, and purpose. Every part is necessary and efficiently communicated, with no redundant information.
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 description lists the key output fields (title, publish date, episode_guid, audio_url) and explicitly states the purpose, which is sufficient for an agent to use the tool. There is no output schema, so this fills the gap. However, it could mention ordering or pagination defaults, but it's not essential given the straightforward nature of the tool.
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?
Schema description coverage is 0%, so the description must explain parameters. While 'feed_url' is implied by the description ('Given a podcast RSS feed or Apple Podcasts show URL'), the 'limit' parameter is not mentioned or explained. The description adds value for 'feed_url' but fails to cover 'limit', leaving the agent to rely solely on schema constraints (min/max/default).
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 uses a specific verb ('list') and resource ('episodes'), specifies the input (podcast RSS feed or Apple Podcasts URL), and states the output fields (title, publish date, etc.). It also explains the purpose: to select which episode to transcribe, distinguishing it from sibling tools like 'transcribe_podcast_feed'.
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 explicitly states the input condition ('given a podcast RSS feed or Apple Podcasts show URL') and the intended use case ('pick exactly which one to transcribe'). While it doesn't list exclusions or alternatives, the context is clear as the sibling list includes related tools like 'transcribe_podcast_feed' and 'search_transcript', suggesting when to use this tool for 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns specific fields (job_id, status, title, duration) and mentions 'recent' jobs, implying ordering. It does not contradict annotations, but adds only moderate behavioral context beyond them.
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?
Two sentences, no wasted words. Every sentence adds value: first states the action and output, second states the purpose. Excellent front-loading.
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 list tool with good annotations, the description provides sufficient context (resource, fields, purpose). It lacks mention of pagination or ordering details, but overall is adequate given the tool's simplicity.
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?
Schema description coverage is 0%, meaning the description does not explain the 'limit' or 'status' parameters. While the schema itself provides clear definitions (e.g., default, min, max, enum), the description should add contextual meaning but does not. This is a gap.
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 the verb 'list', the resource 'transcription jobs', and includes a specific purpose: 'so you can resume, fetch, or export an earlier result instead of re-transcribing.' It distinguishes itself from siblings like 'get_transcription' (single) and 'search_transcript' (search within content).
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 implies when to use ('instead of re-transcribing') but does not explicitly list when not to use or name alternative tools. However, the context is clear enough for an agent to decide.
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?
Annotations confirm read-only and idempotent behavior; description adds that it returns timestamped segments and implies efficient partial retrieval. It does not contradict annotations but could further detail return format or pagination (e.g., max_results).
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?
Single sentence, front-loaded with key action and benefit. Every word serves a purpose, no extraneous information.
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?
Given 6 parameters and no output schema, description is too brief. It covers core function but omits parameter details and output structure. Adequate for basic understanding but incomplete for full agent autonomy.
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?
Schema description coverage is only 17% (only context_segments described). Description only implies 'phrase' corresponds to the 'query' parameter. No explanation of job_id, whole_word, case_sensitive, or max_results, leaving agent unclear on how to configure search.
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?
Description clearly states it searches within a transcript for a phrase and returns matching timestamped segments. It distinguishes from siblings like 'get_transcription' (whole transcript) by specifying the focused search capability, and emphasizes use for long recordings.
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?
Description hints at when to use: 'without loading the whole transcript into context' suggests it's for targeted extraction. However, it does not explicitly state when not to use or list alternative tools like 'get_transcription', leaving some ambiguity.
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?
Annotations already indicate idempotent and non-destructive behavior. The description adds 'Paid capability (throughput/abuse gate)' hinting at billing/rate limits, but does not elaborate on job creation or credit consumption. With annotations covering safety, this adds some value.
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?
Two concise sentences with no wasted words. Key information is front-loaded: batch-transcribe a whole podcast feed. Efficient and well-structured.
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 no output schema, the description mentions return of job IDs. It covers the main purpose and parameter usage adequately for a batch tool of this complexity, though could add note on 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?
Schema coverage is 50%; description clarifies that 'latest' limits episodes, but does not explain 'diarize' or provide further semantics for 'idempotency_key' beyond schema. It partially compensates for the gap but not fully.
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 it batch-transcribes a podcast feed by fanning out episodes to individual jobs, with the option to limit to latest N episodes, and returns job IDs. This distinguishes it from sibling tools like 'transcribe' which likely handles single files.
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 implies use for whole feed batch processing, and mentions it as a paid capability. However, it does not explicitly contrast with alternatives like 'transcribe' or list tools, missing a clear 'when to use' statement.
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?
The description adds context beyond annotations by mentioning the return value (file_ref) and the storage backend requirement. Annotations already indicate non-readonly and non-destructive, and the description does not contradict them.
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 sentences, front-loading the core purpose and usage guideline without extraneous information. Every sentence adds value.
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 no output schema, the description explains the return value (file_ref) and the purpose. It also mentions the storage backend requirement. It is fairly complete, though it omits failure conditions or size limits.
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?
Although schema coverage is 100% and the description mentions the alternative between path and bytes_base64, it does not add significant meaning beyond what is already in the parameter descriptions.
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 explicitly states 'Upload local audio/video' and explains the purpose: to get a file_ref for transcribing. This clearly distinguishes it from sibling tools like transcribe and export_transcript.
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?
It says 'Use this when the media has no public URL', providing a clear usage context. It also mentions the requirement for the Pepys R2 storage backend. However, it does not explicitly state when not to use or list alternatives.
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?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses the payment model: segment-level export is free, word-level timed export (word_level:true) is a paid unlock. It also notes that DOCX/PDF are unavailable, setting correct expectations. No contradictions with 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?
Three sentences, each serving a purpose: first states core function, second adds pricing context, third clarifies missing formats. No unnecessary words or repetitions. Front-loaded with the most critical information.
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 simple export tool with strong annotations (readOnly, idempotent, non-destructive), the description covers the essential: what it exports, in which formats, with timing details, pricing nuance, and exclusions. No output schema is needed as the returned file content is implied. Completely adequate given the tool's complexity.
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 low (33%, only word_level has a description). The description compensates by listing format values (SRT, VTT, TXT, MD, JSON) and explaining word_level's cost implication. job_id is not explicitly described but is self-explanatory as the identifier of the transcript to export. Overall, adds some meaning but not comprehensive.
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 the verb 'Export' and the resource 'a finished transcript', listing specific output formats (SRT, VTT, TXT, MD, JSON). It distinguishes from siblings like 'get_transcription' (which likely returns the raw transcription object) by focusing on file export with caption timings. The mention of 'DOCX/PDF are available in the Pepys web app' further clarifies the tool's scope.
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 implies usage when a transcript is finished and a file format is needed. It provides relevant context: segment-level export is free, word-level is paid, and DOCX/PDF are not available via this tool. However, it does not explicitly state when not to use it or compare to alternatives like 'get_transcription' or 'search_transcript'.
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?
Annotations indicate read-only, idempotent, non-destructive behavior. Beyond that, the description adds polling behavior details (wait_ms and polling loop) and lists the exact data returned. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first covers purpose and fields, second covers polling guidance. No redundant words, front-loaded with key information.
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 fetch tool with two parameters and no output schema, the description adequately covers purpose, return data, and polling behavior. Minor gaps like error handling are acceptable given 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?
With 50% schema coverage, the description clarifies 'job_id' as the transcription identifier (schema only has minLength) and explains 'wait_ms' as a long-poll mechanism (schema provides defaults/max). This adds meaning beyond 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?
The description explicitly states 'Fetch a transcription by job_id' and lists the return fields, making the purpose clear and specific. It distinguishes from sibling tools like 'list_transcriptions' and 'search_transcript' by being a direct fetch by ID.
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 guidance on using 'wait_ms' for long-polling and implies polling until status is 'done'. It does not explicitly compare to alternatives but provides clear usage context.
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?
Annotations already indicate idempotency and non-read-only behavior. The description adds valuable context: 'Audio is never used to train models' and the async job model. It does not cover rate limits or cost, but the additional privacy statement compensates.
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 well-structured sentences. Each sentence adds distinct value: purpose, input options, and privacy/async handling. No wasted words, and key information is front-loaded.
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 11 parameters and no output schema, the description covers core aspects: purpose, inputs, async return, and privacy. It lacks detail on parameter interactions (e.g., quality vs. diarize) but references get_transcription for results, which suffices for completeness.
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?
With 91% schema coverage, the description still adds meaning beyond the schema by explaining input types (e.g., YouTube, podcast feeds) and the return format. It also clarifies the mutual exclusivity of url and file_ref.
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 specifies the verb (transcribe), resource (audio/video), and output (speaker-labeled, timestamped transcript with SRT/VTT captions). It distinguishes from sibling tools by emphasizing 'hours-long' content and the specialized output format.
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 provides clear input options (file_ref or URL) and context (long-form media). It mentions the async return pattern and references get_transcription. However, it does not explicitly state when not to use this tool or compare with siblings like transcribe_podcast_feed.
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?
Annotations already indicate readOnlyHint and idempotentHint. The description adds behavioral context by specifying the unit (minutes) and the purpose (avoid running out mid-run), complementing the annotations well.
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 sentence that is front-loaded with the core action and efficiently explains purpose. No superfluous words or repetition.
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 zero-parameter, no-output-schema tool, the description fully covers what the tool does, what it returns, and why to use it. Nothing 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 has no parameters, so the description does not need to add parameter details. Schema coverage is 100%, and the description is clear that no inputs are required, earning a baseline of 4.
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 the tool returns remaining transcription credits in minutes, with a specific verb ('Return') and resource. It distinguishes from sibling tools by focusing on balance rather than transcription operations.
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 explicitly advises using this tool to 'check headroom before starting a large batch', providing a clear use case. It does not specify when not to use or mention alternatives, but the context is sufficient.
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:

[![pepys-mcp MCP server](https://glama.ai/mcp/servers/ankurmans/pepys-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ankurmans/pepys-mcp)

Score Badge

Copy to your README.md:

[![pepys-mcp MCP server](https://glama.ai/mcp/servers/ankurmans/pepys-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ankurmans/pepys-mcp)

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/ankurmans/pepys-mcp'

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