spamtitan-mcp

Server Quality Checklist

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

Latest release: v1.3.3
Disambiguation5/5
Each tool has a clearly distinct purpose covering quarantine management (view, release, delete), list management (allow/block), statistics, status, and a discovery helper. No overlapping functionality.
Naming Consistency5/5
All tools use a consistent 'spamtitan_verb_noun' snake_case pattern, e.g., delete_message, get_queue, manage_allowlist. Even 'status' follows the convention as a noun-only name, which is acceptable.
Tool Count5/5
8 tools is appropriate for a spam filtering server, covering all essential operations: queue inspection, release/delete, allow/block list management, statistics, and status. No bloat or deficiency.
Completeness4/5
The tool set covers the main lifecycle of quarantine management and list management, but lacks advanced features like searching within the queue or exporting logs. However, core workflows are complete.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior2/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 of behavioral disclosure. 'Show' implies a non-mutating read, but the description does not disclose whether the tool performs authentication, refreshes tokens, queries a live server, or has side effects. Failure modes and permission requirements are also absent.
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. Both key outputs, 'credentials status' and 'available domains', are front-loaded and easy to scan.
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 empty schema, no annotations, and no output schema, the description is the only contextual source. It names the two outputs but does not define what credentials refer to, what the domain list represents, or how this tool fits into the workflow with siblings. It is minimally usable but leaves meaningful 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, so the empty schema already captures all parameter semantics. The description does not need to explain parameters. This meets the baseline for a parameterless tool.
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 uses the verb 'Show' with a clear resource: 'credentials status and available domains'. This is specific enough to distinguish it from siblings like spamtitan_release_message or spamtitan_manage_allowlist, which clearly perform different actions. However, it does not explicitly differentiate itself from spamtitan_get_stats, which could also be a status-like tool.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is a pre-flight credential check, whether it should be used before other SpamTitan operations, or when a user would need the domain list. No exclusions or alternative tool routing are provided.
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, description must disclose all behavioral traits. It only states the basic action without mentioning side effects (e.g., does it remove the quarantine entry?), failure modes, idempotency, or permissions required.
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?
Extremely concise single sentence with no unnecessary words. Action verb is front-loaded, making it efficient for quick consumption.
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?
For a simple tool with one parameter and no output schema, the description covers the core functionality but omits important context such as success response, error handling, and prerequisites (e.g., message must be quarantined).
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 has 100% parameter description coverage, so the description adds no new information about the single parameter beyond what the schema already provides. Baseline of 3 is appropriate.
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 the action (release) and the resource (quarantined message) with the outcome (delivery to recipient). It distinguishes itself from sibling tools like delete_message and navigation tools.
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 explicit guidance on when to use release vs. delete or other actions. Sibling tool 'spamtitan_delete_message' is an alternative, but description does not clarify when to choose one over the other.
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?
No annotations provided, so description must disclose behavior. It only states basic function and effect, but omits details like idempotency, duplicate handling, removal matching, permissions, or output format on 'list'.
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 with clear structure: first states action and resource, second explains consequence. No 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?
Tool is simple with 3 params, 1 required, enum for action. Description covers purpose and effect. Lacks info on 'list' output format but overall adequate for a straightforward management 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 100%, so schema fully describes parameters. Description adds context about the overall effect (bypass filtering) but no additional parameter-specific meaning.
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 the tool manages allowlist entries (add/remove) in SpamTitan and explains the effect (bypass spam filtering). It distinguishes from sibling spamtitan_manage_blocklist by specifying allowlist.
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?
Implied usage from name and sibling tools, but no explicit guidance on when to use vs blocklist, no prerequisites or exclusions. Schema enum covers actions but description lacks context.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does state what is returned (quarantined messages with sender, recipient, subject, and reason) and implies a non-mutating list operation, but it does not mention permissions, rate limits, or any side effects beyond listing.
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 with no filler. The action and resource are front-loaded, and the return-value summary is concise but informative. The description earns its place without 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?
For a simple list tool with zero required parameters and fully documented schema, the description plus schema covers what the agent needs: return fields, optional filters, and pagination defaults. The only notable gap is the absence of explicit guidance about preferring sibling tools for message-level actions, keeping it just below top-tier.
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 100%, so all six parameters are already documented with their defaults, filters, and constraints. The description adds only marginal context about the output including 'reason for quarantine,' which maps to the reason filter, but it does not need to compensate for schema gaps.
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 action verb 'List' and a specific resource, 'the email quarantine queue,' then names the returned fields: sender, recipient, subject, and reason. This clearly distinguishes it from siblings like spamtitan_get_message, spamtitan_release_message, and spamtitan_delete_message.
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 verb 'List' implies this is the browsing/listing tool, so the basic usage context is clear. However, the description does not explicitly say when not to use it or point to spamtitan_get_message for individual message details and release/delete for actions, so alternative routing is left to inference.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It does not state whether the operation is read-only, any authentication or authorization requirements, rate limits, or error handling for invalid domains. The description covers statistics categories and filtering but omits important behavioral 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 sentences, front-loading the main purpose and key details in the first sentence, with additional filtering context in the second. Every phrase adds value without 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?
For a tool with two parameters and no output schema, the description covers the essential purpose, statistics categories, and filtering options. It could mention the return format (e.g., aggregated counts) to enhance completeness, but overall it provides adequate context.
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 input schema already describes both parameters with 100% coverage. The description adds value by listing the types of statistics returned (received, blocked, quarantined, delivered) and reinforcing the filtering capability, which goes beyond the schema's basic 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 clearly states the tool retrieves email flow statistics from SpamTitan, listing specific metrics (received, blocked, quarantined, delivered) and indicating time period filtering. This distinguishes it from sibling tools, which handle deletion, queue, allow/block lists, etc.
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 use for fetching statistics but does not explicitly state when to use it over alternatives or provide exclusions. It lacks guidance on scenarios where other tools might be more appropriate.
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 disclosure burden. It communicates the return payload (sender, recipient, subject, reason, spam score, status) and adds an unexpected behavioral detail about rendering as an interactive card in MCP Apps hosts. It stops short of stating read-only nature explicitly or handling for invalid/not-found IDs, but the 'Get' verb and output-focused language make the behavior reasonably clear.
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 compact and well-structured: the action is front-loaded, the return fields are listed in a natural sequence, and the rendering note is appended without redundancy. Every sentence adds distinct information and no filler is present.
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 single-parameter read tool with no output schema, the description adequately covers what the tool does and what it returns. It does not mention error cases or how to obtain a message_id, but these are minor gaps given the simplicity of the operation and the strong parameter coverage.
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 100% and the single parameter 'message_id' is already documented as 'The quarantined message ID to fetch'. The tool description reiterates 'by ID' but adds no additional semantic detail such as ID format, source, or validation constraints, so the schema already carries the necessary meaning.
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 ('Get') with a clear resource ('a single quarantined message by ID') and enumerates the returned fields. This explicitly distinguishes it from sibling tools like spamtitan_get_queue (list) and mutation tools like spamtitan_release_message or spamtitan_delete_message.
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 the tool should be used when a specific quarantined message ID is known and its details are needed, but it does not explicitly state when to prefer this over alternatives such as spamtitan_get_queue. There is no exclusion guidance or when-not-to-use condition.
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?
Description adds value beyond annotations: explicitly labels action as 'DESTRUCTIVE — IRREVERSIBLE', states permanence, and confirms removal from quarantine storage. Annotations already have destructiveHint=true, so the description reinforces and adds confirmation requirement without contradiction.
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?
Extremely concise: two short sentences plus an emoji warning. Critical information (destructiveness, permanence, confirmation requirement) front-loaded. No unnecessary words.
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 destructive tool with one parameter and no output schema, the description covers all necessary context: action, resource, irreversibility, and user confirmation. Sibling tools provide alternative actions, but the description is sufficient for this 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 100% for the single parameter 'message_id', so the description does not need to explain parameters. The description does not repeat or enhance parameter meaning, which is adequate given high schema 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?
Tool name 'spamtitan_delete_message' combined with description 'Permanently delete a quarantined message by ID' clearly specifies verb (delete) and resource (quarantined message). Distinguishes from siblings like 'spamtitan_release_message' which implies a different action.
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 includes explicit instruction to 'Confirm with the user before invoking', providing usage context. However, it does not explicitly state when not to use or mention alternative tools, but the warning implies cautious invocation.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that this is a read-only discovery aid, states what it returns, and clarifies that it does not gate access to other tools. This is meaningful transparency for a simple navigation tool, though it could mention error handling or output format.
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 with no filler. The first sentence states the core purpose and return value; the second adds the crucial 'not a prerequisite' behavioral note. Information is front-loaded and every sentence earns its place.
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, single-parameter discovery tool with no output schema and no annotations, this description is complete. It explains what the tool does, what it returns, how the domain parameter selects content, and that it has no operational side effects or prerequisites. Nothing essential is missing.
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 100%, and the enum values already provide detailed explanations for each domain. The description adds no new parameter meaning beyond the phrase 'by domain', so the schema is doing the heavy lifting. Baseline 3 is appropriate.
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 states a clear verb ('Discover') and resource ('available SpamTitan tools by domain'), and explains the return value: tool names and descriptions. It also explicitly distinguishes itself from tools that perform actual operations by calling itself a 'help/discovery aid' rather than a prerequisite, separating it from the sibling operation tools.
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 makes clear when to use it: to explore tools available for a domain. It also provides an important exclusion: it is not a prerequisite and all tools are callable at any time. However, it does not explicitly name alternative tools or provide more detailed guidance on when to prefer this over the actual operation tools.
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?
Description adds behavioral context beyond annotations, such as 'modifies email delivery policy', 'affects deliverability', and 'reversible by removing entries'. Consistent with destructiveHint=true and idempotentHint=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?
Very concise: three sentences with front-loaded warning symbol. Every sentence adds essential context without 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?
Covers impact, reversibility, and confirmation need. However, lacks description of output for 'list' action, which could be inferred but not explicit.
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 100%, and main description adds no new parameter-specific details beyond what the schema provides. Baseline 3 is appropriate.
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 modifies SpamTitan blocklist entries, distinguishing it from the sibling 'manage_allowlist'. The verb 'manage' with 'blocklist' is specific.
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?
Provides explicit warning about high impact and necessity for user confirmation. Describes consequences (rejection/quarantine) and reversibility. Lacks explicit 'when not to use' or direct alternative mention, but 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:

[![spamtitan-mcp MCP server](https://glama.ai/mcp/servers/WYRE-AI/spamtitan-mcp/badges/card.svg)](https://glama.ai/mcp/servers/WYRE-AI/spamtitan-mcp)

Score Badge

Copy to your README.md:

[![spamtitan-mcp MCP server](https://glama.ai/mcp/servers/WYRE-AI/spamtitan-mcp/badges/score.svg)](https://glama.ai/mcp/servers/WYRE-AI/spamtitan-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/WYRE-AI/spamtitan-mcp'

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