Outreach Deliverability MCP

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation4/5
Most tools have distinct purposes (channel rules, sender setup, spam audit, full pack), but diagnose_campaign and interpret_benchmark both process metrics and could be confused by an agent. Descriptions are clear enough to disambiguate with careful reading.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (diagnose_campaign, get_full_pack, interpret_benchmark, get_channel_rules, get_sender_setup_checklist, audit_spam_triggers). Naming is uniform and predictable.
Tool Count5/5
Six tools is well-scoped for an outreach deliverability domain, each covering a distinct aspect: diagnostics, benchmarks, channel rules, sender setup, spam triggers, and a full reference pack. No unnecessary bloat or obvious thinness.
Completeness4/5
The set covers diagnosis, benchmark interpretation, channel rules, sender setup, and spam auditing—a strong lifecycle for deliverability analysis. Minor gaps exist, such as no tool for reputation monitoring or step-by-step fix execution beyond the fix order returned by diagnose_campaign, but core needs are met.
Average 4.1/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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?
No annotations are provided, so the description carries the transparency burden. The verb 'Get' implies a read-only operation, and the description enumerates the types of information returned, providing useful context. However, it does not explicitly state authentication requirements, behavior on invalid channel values, or the response format, leaving some ambiguity.
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 one sentence with a front-loaded verb followed by a compact list of content categories. No redundant information or filler words are included.
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 one-parameter getter, the description gives a comprehensive list of what the tool returns, which is sufficient for most use cases. It lacks details on error handling or output structure, but the tool's simplicity and the absence of an output schema make this less critical. The sibling tools suggest broader functionality, but this description is reasonably complete.
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 description lists the four allowed channel values (email, linkedin, instagram_dm, x_dm) which mirrors the schema enum, giving context that the parameter is an outreach channel. It does not explicitly name the 'channel' parameter or explain its semantics beyond the list, so with 0% schema coverage the description partially compensates but doesn't fully define the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get' and specifies exactly what is returned: safe volume limits, account setup, warmup protocol, kill signals, personalization floor, and legal basics. This content list clearly distinguishes it from sibling tools like diagnose_campaign or get_sender_setup_checklist.
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 instead of sibling tools. The phrase 'for an outreach channel' implies the tool is channel-specific, but there are no explicit criteria, exclusions, or alternatives mentioned.
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 burden of behavioral disclosure. It transparently states that the tool returns a checklist and lists all 10 components, giving a clear expectation of the output. It does not mention side effects or prerequisites, but as a simple getter, this is sufficient.
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. It front-loads the key outcome ('Returns the 10-step checklist') and then provides a compact, comma-separated enumeration of the included items, with zero wasted 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?
Given the tool's simplicity (zero parameters, no output schema), the description is fully complete. It names the exact artifact and enumerates all steps, leaving no ambiguity about the return content. The sibling context further clarifies its niche, but the description alone is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline for no parameters is 4. The description adds value by detailing the content of the returned checklist, which is the only relevant semantic aspect. There are no parameter semantics to clarify.
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 'Returns' and identifies the exact resource: the 10-step cold-email infrastructure checklist. It clearly distinguishes itself from sibling tools by naming its unique deliverable and enumerating its contents.
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 states what the tool returns but provides no guidance on when to use it versus alternatives like diagnose_campaign or audit_spam_triggers. There is no mention of scenarios or exclusions, leaving the agent to infer usage solely from the tool's name.
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 transparently explains the core behavior—diagnosing the most likely failure layer and providing a fix order—and adds the important insight that deliverability issues can look like copy issues. Since no annotations are provided, it fully carries the burden, but it does not mention optional input behavior or any side effects, which are presumably 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 two sentences, front-loading the key information in the first sentence and adding a memorable heuristic in the second. No extraneous details are 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?
Given the tool's moderate complexity and lack of output schema, the description adequately explains the return value and the diagnostic categories. It does not specify the exact structure of the fix order, but this is likely sufficient for agent invocation. The missing channel parameter in the description is a minor gap.
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 description adds meaning to four parameters by specifying they are percents and allows any subset, which aligns with the schema's optional fields. However, it omits the required `channel` parameter entirely, leaving a gap in parameter semantics. The schema has no descriptions, so this incompleteness is notable.
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 defines the tool's function as a diagnostic for campaign failure layers, specifying the inputs (open_rate, reply_rate, bounce_rate, acceptance_rate) and outputs (failure layer and fix order). It distinguishes itself from sibling tools by highlighting the unique value of distinguishing deliverability issues from copy issues.
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 its usage scenario: when you have campaign metrics and need to determine whether the issue lies in infrastructure, list, or message. The deliverability-masquerading warning provides a strong 'when to use' hint, but it doesn't explicitly name alternatives or exclusion criteria.
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 must carry the burden. It discloses the return content and implies a read-only operation ('Returns'), but does not mention potential size, performance, or any other behavioral traits. Adequate but not rich.
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 the action and output, then adds a clear use-context clause. No wasted words or irrelevant detail.
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?
With no parameters and no output schema, the description sufficiently explains the tool's broad purpose and contents. Could specify the structure or format of the returned library, but it's not essential for a zero-param aggregate getter.
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?
Tool has zero parameters, so there is nothing to explain. Per rubric, baseline for zero params is 4; description does not need to add parameter details.
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 uses specific verb 'Returns' with resource 'complete deliverability library' and enumerates components (channel rules, sender setup, spam triggers, benchmarks), clearly distinguishing it from narrower sibling tools. The aggregate nature is unambiguous.
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?
States 'useful for full agent context' providing clear context for when to use. Does not explicitly name alternatives or exclusions, but the sibling tools list itself implies when to use specific tools instead, giving adequate guidance.
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 behavioral disclosure burden. It states the tool 'Returns healthy range, warning threshold, and the diagnostic note,' which clarifies output behavior. While it does not explicitly say it is read-only or non-mutating, the 'interpret' verb and return-focus imply a safe operation.
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-loaded with purpose and metric list, then output details. Every phrase adds value, with no filler or repetition.
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, two-parameter tool with no output schema, the description is complete: it states what the metric list is, what it returns, and the purpose. It could mention that observed_value is optional or describe error conditions, but the core usage and return values are adequately covered for 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 coverage is 50%: observed_value has a description, and metric is defined by enum but no prose description. The tool description lists the metric names (redundant with the enum) but does not explain how observed_value is used or the output format relative to parameters. It adds little beyond the schema, so 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's purpose: 'Interpret an outreach metric against practitioner benchmarks' and lists the exact metrics handled. It distinguishes the tool by focusing on metric interpretation and the specific return values (healthy range, warning threshold, diagnostic note).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use when you have one of the listed outreach metrics and want to compare it to benchmarks. It does not explicitly name alternatives or exclusions, but the metric enumeration and 'interpret' verb make the intended use obvious relative to sibling diagnostic tools.
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 burden. It discloses that the tool returns a list of hits, a 0-100 risk score, and a verdict, which is the key behavioral outcome. It does not explicitly state it is read-only or non-destructive, but the audit nature implies no side effects.
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, information-dense sentence. It leads with the verb 'Audit' and efficiently lists trigger types and output structure without any extraneous 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 single-parameter tool with no output schema, the description provides everything needed: what to audit, what triggers are checked, and what results are returned. No additional context is necessary for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the sole parameter 'text' as the full outreach copy including the subject line (100% coverage). The description adds slight context by mentioning 'subject + body' but does not significantly enhance parameter understanding 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 clearly states the tool's function: it audits outreach copy (subject + body) for specific spam-filter triggers. It lists concrete trigger categories (flagged phrases, all-caps, exclamation marks, multiple links, etc.) and distinguishes it from sibling tools by focusing exclusively on spam trigger detection.
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 context: run this audit on outreach copy before sending. It does not explicitly name alternatives or exclusions, but the focus on spam triggers makes the intended use clear.
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:

[![outreach-deliverability-mcp MCP server](https://glama.ai/mcp/servers/closermethod/outreach-deliverability-mcp/badges/card.svg)](https://glama.ai/mcp/servers/closermethod/outreach-deliverability-mcp)

Score Badge

Copy to your README.md:

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

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