Proton MCP Server

by cogghaus

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific email operations: listing, reading, sending, replying, searching, moving, deleting, and folder management. There is no overlap in functionality, making tool selection straightforward for an agent.
Naming Consistency5/5
All tool names follow a consistent 'proton_verb_noun' pattern using snake_case, such as proton_list_emails and proton_send_email. This uniformity enhances readability and predictability across the toolset.
Tool Count5/5
With 8 tools, the server is well-scoped for email management, covering essential operations like CRUD (create, read, update via move/reply, delete), search, and folder handling. Each tool serves a clear purpose without redundancy.
Completeness5/5
The toolset provides complete coverage for email workflows, including listing, reading, sending, replying, searching, moving, deleting, and folder management. There are no obvious gaps, enabling agents to handle full email lifecycle tasks effectively.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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 failing
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?
Annotations indicate this is a non-readOnly, non-destructive operation, but the description doesn't add meaningful behavioral context beyond that. It mentions format support (plain text/HTML) and recipient flexibility, but fails to disclose critical traits like rate limits, authentication requirements, error handling, or whether emails are sent immediately or queued. With annotations covering basic safety, the description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, consisting of two efficient sentences that directly state the tool's function and key features. There's no unnecessary verbiage, though it could benefit from more structured information to improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 6-parameter email-sending tool with no output schema and 0% schema coverage, the description is insufficient. It omits details on parameter usage, error conditions, response format, and integration with sibling tools. For a mutation tool with rich functionality, this leaves significant gaps in understanding how to effectively invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters lack documentation in the schema. The description only vaguely mentions recipients ('single string or array of strings') and formats, but doesn't explain the purpose or semantics of key parameters like 'to', 'cc', 'bcc', 'subject', 'body', or 'html'. It fails to compensate for the schema gap, leaving parameters largely unexplained.
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 verb ('Send') and resource ('email'), specifying it's for sending new emails with format support. It distinguishes from siblings like delete, list, move, read, reply, and search by focusing on creation rather than manipulation or retrieval, though it doesn't explicitly contrast with 'proton_reply_email' which also sends emails.
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 like 'proton_reply_email' for responding to existing emails or 'proton_list_emails' for checking sent items. The description lacks context about prerequisites, such as needing valid recipient addresses or authentication, and doesn't mention exclusions or typical use cases.
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 cover key traits (destructiveHint: true, idempotentHint: true, readOnlyHint: false), but the description adds valuable context by specifying that deletion moves the email to the Trash folder, clarifying the actual behavior beyond just 'delete.' It does not contradict annotations, as 'delete' aligns with destructiveHint: true.
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 concise sentences with zero waste: the first states the purpose and method, the second specifies parameter usage. It is front-loaded and appropriately sized for the tool's complexity.
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 the destructive nature (annotations indicate destructiveHint: true) and no output schema, the description adequately covers the basic operation but lacks details on outcomes (e.g., confirmation of deletion, error handling) and full parameter context. It is minimally viable but has gaps in completeness for a mutation 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 description coverage is 0%, so the schema provides no parameter descriptions. The description adds some meaning by mentioning 'folder name and email UID,' but it does not detail semantics (e.g., what UID represents, default folder behavior). It partially compensates for the coverage gap but leaves parameters under-specified.
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 specific action ('Delete an email by moving it to the Trash folder') and identifies the resource ('email'), distinguishing it from siblings like proton_move_email (which moves emails elsewhere) and proton_list_emails (which only reads). The verb 'delete' is precise and not tautological with the name/title.
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 by specifying 'Use the folder name and email UID,' but it does not explicitly state when to use this tool versus alternatives (e.g., proton_move_email for moving to other folders, proton_list_emails for reading). It provides basic context but lacks explicit guidance on exclusions or prerequisites.
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 indicate this is a non-readOnly, non-destructive, non-idempotent, non-openWorld operation, covering basic safety. The description adds value by specifying threading behavior ('Properly sets In-Reply-To and References headers') and reply options, but it lacks details on permissions, error handling, or rate limits. No contradiction with annotations 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?
The description is two sentences with zero waste: the first states the core purpose and technical detail, and the second clarifies usage options. It is front-loaded and efficiently structured, making it easy to parse.
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 no output schema and annotations covering basic traits, the description is moderately complete. It explains the tool's action and threading but lacks details on return values, error cases, or dependencies like email access permissions. For a mutation tool with 4 parameters, more context would improve completeness.
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 0%, so the description must compensate. It mentions 'reply to all or just the sender,' which relates to the 'reply_all' parameter, but does not explain other parameters like 'folder' or 'uid.' The description adds some meaning but does not fully cover the four parameters, resulting in a baseline score.
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 specific action ('Send a reply') and resource ('to an existing email'), distinguishing it from siblings like proton_send_email (new email) and proton_read_email (read-only). It includes technical details about threading headers, which adds precision.
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 context for usage ('reply to an existing email') and distinguishes between 'reply to all or just the sender,' but it does not explicitly state when to use this tool versus alternatives like proton_send_email for new emails or mention prerequisites such as needing a valid UID. This omission prevents a perfect score.
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 read-only, non-destructive, and idempotent behavior, but the description adds valuable context by specifying that multiple criteria use AND logic, which isn't covered by annotations. No contradictions with annotations are present.
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 key behavioral detail (AND logic) in two concise sentences. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 10 parameters with 0% schema coverage and no output schema, the description provides basic search criteria but lacks details on parameter interactions, default behaviors, or result format. It's adequate for a read-only tool with good annotations but has gaps in parameter explanation.
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 0%, so the description carries the burden. It lists search criteria (sender, recipient, etc.) which map to parameters like 'from', 'to', but doesn't explain all 10 parameters (e.g., 'folder', 'limit', 'offset'). The description adds some meaning but doesn't fully compensate for the low coverage.
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's purpose with specific verbs ('Search emails') and resources ('emails'), listing multiple search criteria. It distinguishes from siblings like proton_list_emails by specifying filtering capabilities, not just listing.
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 for searching emails with specific criteria but doesn't explicitly state when to use this vs. alternatives like proton_list_emails (which might list without filtering) or proton_read_email (for viewing a single email). No exclusions or prerequisites are mentioned.
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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds useful context about pagination, displayed fields (sender, subject, date, read status), and sorting (newest first), but does not disclose additional behavioral traits like rate limits, authentication needs, or error conditions beyond what annotations imply.
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 concise sentences with zero waste: the first states the core action and key features (pagination, displayed fields), and the second adds ordering information. It is front-loaded and appropriately sized for the tool's complexity.
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 tool's moderate complexity (3 parameters, no output schema), rich annotations (covering safety and idempotency), and the description's coverage of purpose, fields, and ordering, it is mostly complete. However, it lacks details on error handling, authentication requirements, or output format, which could be useful since there is no output schema.
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 0%, so the schema provides no parameter descriptions. The description mentions 'specific folder' and 'pagination', which loosely relate to the folder, limit, and offset parameters, but does not add detailed meaning (e.g., default values, constraints, or semantics like offset for pagination). With 3 parameters and no schema descriptions, the description compensates minimally, meeting the baseline for adequate but incomplete coverage.
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') and resource ('emails in a specific folder'), specifies the scope ('with pagination'), and distinguishes it from siblings like proton_search_emails by focusing on listing rather than searching. It explicitly mentions what information is shown (sender, subject, date, read status) and the ordering (newest first).
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 for listing emails in a folder with pagination, but does not explicitly state when to use this tool versus alternatives like proton_search_emails or proton_list_folders. It provides clear context (specific folder, pagination) but lacks explicit exclusions or named 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?
Annotations already indicate read-only, non-destructive, and idempotent behavior, but the description adds useful context by specifying the output includes message counts and unread counts, which helps the agent understand the return format. It does not contradict 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, efficient sentence that front-loads the core purpose and includes all necessary details (folders, counts) without redundancy. Every word adds value, making it highly concise 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 the tool's low complexity (one optional parameter), rich annotations covering safety and behavior, and no output schema, the description is mostly complete. It specifies the output content (folders with counts), though it could mention the response_format parameter's effect on output structure.
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 input schema has one parameter (response_format) with 100% coverage via enum values, but the description provides no additional parameter information. Since schema_description_coverage is 0%, the baseline is 3 as the schema fully documents the parameter without description 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 the specific action ('List all mailbox folders') and resource ('Proton Mail folders'), distinguishing it from siblings like proton_list_emails (which lists emails) and proton_search_emails (which searches emails). It specifies the scope includes standard folders (INBOX, Sent, etc.) with message and unread counts.
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 for retrieving folder metadata, but does not explicitly state when to use this tool versus alternatives like proton_list_emails or proton_search_emails. No guidance is provided on prerequisites, exclusions, or specific contexts where this tool is preferred.
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 provide key behavioral traits (non-readOnly, non-destructive, idempotent), and the description adds context by specifying the action of moving an email between folders. It does not contradict annotations, and while it doesn't detail side effects like rate limits or auth needs, it offers useful operational context beyond the 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, efficient sentence that front-loads the core action and lists parameters without unnecessary words. Every part earns its place, making it highly concise and well-structured for quick understanding.
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 the tool's moderate complexity (mutation with idempotency), no output schema, and annotations covering safety, the description is adequate but lacks details on return values, error conditions, or folder validation. It meets minimum viability but has clear gaps in completeness for a mutation tool.
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 0% schema description coverage, the description compensates by explaining the semantics of all three parameters (source folder, email UID, destination folder), adding meaning beyond the bare schema. It clarifies what each parameter represents, though it doesn't specify formats or constraints like folder naming rules.
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 specific action ('Move an email') and resources involved ('from one folder to another'), distinguishing it from siblings like delete, list, read, reply, search, and send operations. It precisely defines the tool's function without being vague or tautological.
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 by specifying the required parameters, but it does not explicitly state when to use this tool versus alternatives (e.g., when moving versus deleting or replying to an email). No exclusions or prerequisites are mentioned, leaving usage context somewhat implicit.
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 read-only, non-destructive, and idempotent behavior, which the description does not contradict. The description adds useful context by specifying what content is read (headers, body, attachments) and mentioning folder and UID parameters, enhancing transparency beyond the annotations without providing extra details like rate limits or auth needs.
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 in the first clause and efficiently specifies content and parameters in a single, waste-free sentence. Every element earns its place, making it highly concise and well-structured for quick understanding.
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 tool's moderate complexity (2 parameters, no output schema), the description covers the purpose and parameters adequately. It lacks details on return values or error handling, but with annotations providing safety context, it is mostly complete. A higher score would require more behavioral or output information.
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 0%, so the description must compensate. It mentions the parameters (folder and email UID) but does not add meaning beyond the schema, such as explaining folder options or UID significance. With no param details in the description, it partially compensates but leaves semantics unclear, aligning with the baseline for low coverage.
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 specific action ('Read the complete content of an email') and resource ('email'), distinguishing it from siblings like proton_list_emails (list) or proton_delete_email (delete). It explicitly mentions what content is included (headers, body, attachments), making the purpose unambiguous and distinct.
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 context by specifying that it reads a full email, implying it should be used when detailed content is needed versus proton_list_emails for summaries. However, it does not explicitly state when not to use it or name alternatives, such as proton_search_emails for filtered searches, leaving some guidance implicit.
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:

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

Score Badge

Copy to your README.md:

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

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/cogghaus/proton-mcp-server'

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