Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PostureCheck MCP Is example.com protected against email spoofing?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Domain security checks for MCP-capable assistants — SPF, DKIM, DMARC, MTA-STS, TLS certificates and protocol support, and HTTP security headers.
An assistant can explain what DMARC is perfectly well. What it can't do is tell you whether your domain has it — that needs a live DNS lookup. This fills that gap.
> Is example.com protected against email spoofing?
[PASS] SPF: SPF record found
[FAIL] SPF policy: ~all (softfail — consider upgrading to -all)
[PASS] DKIM: DKIM found (selector: google), 2048-bit
[PASS] DMARC: DMARC record found
DMARC policy: p=none (monitoring only — provides no protection against spoofing)No installation needed — it runs via npx.
Add to claude_desktop_config.json:
{
"mcpServers": {
"posturecheck": {
"command": "npx",
"args": ["-y", "posturecheck-mcp"]
}
}
}On macOS that file lives at ~/Library/Application Support/Claude/claude_desktop_config.json.
Same shape, in whichever config file that client uses:
{
"mcpServers": {
"posturecheck": {
"command": "npx",
"args": ["-y", "posturecheck-mcp"]
}
}
}Restart the client afterwards.
Related MCP server: External Reconnaissance MCP Server
scan_domainFull posture check in one call. Email authentication, TLS, and HTTP security headers, with an overall score.
Useful for: "Is acme.com configured securely?", "Can anyone spoof email from our domain?", "Review the security of these five domains."
check_tlsTLS detail. Certificate validity, expiry, issuer, key strength, the full chain, and — importantly — which protocol versions the server actually accepts, tested with a separate handshake per version.
That last point matters. Most tools report the protocol that got negotiated, which is always the best one both sides support. Whether TLS 1.0 is still enabled is a different question, and it's the one a PCI DSS assessor asks.
Useful for: "Which TLS versions does example.com accept?", "When does this certificate expire?", "Why does this site work in my browser but fail in curl?"
analyse_spfResolves the complete SPF include tree, counts DNS lookups against the RFC 7208 limit of 10, and names the services authorised to send mail.
SPF silently fails with a PermError above 10 lookups, and nested includes make the count hard to eyeball — a record with five includes can easily be at eleven.
Useful for: "Why is our SPF failing?", "How many DNS lookups is our SPF using?", "Which services can send mail as our domain?"
Email — SPF presence and policy, DNS lookup count, DKIM key detection and strength, DMARC policy and reporting address, MTA-STS.
TLS — certificate validity, expiry, issuer, key type and size, hostname coverage, full chain with missing-intermediate detection, protocol support for TLS 1.0 through 1.3, forward secrecy, CAA records.
HTTP — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
Checks read publicly published DNS records and make standard HTTPS connections — the same information any browser or mail server receives. Nothing is probed, exploited, or accessed beyond that. See the scanning policy.
Results are not stored. There is no account and no API key.
Requests are rate limited. If you're scanning a large number of domains you'll be throttled; space them out.
Results reflect externally observable configuration only. A good score doesn't mean a domain is secure — it means the things visible from the public internet are configured sensibly.
Variable | Default | Purpose |
|
| Point at a different instance |
posturecheck.io — web interface
Methodology — what each check does and which standard it's based on
EU Domain Security Survey 2026 — 12,905 domains across 26 countries
MIT
Analyse a domain's SPF record: resolve the full include tree, count DNS lookups against the RFC 7208 limit of 10, identify which services are authorised to send mail, and flag misconfigurations such as multiple SPF records or a permissive +all. Use this for SPF PermError, "too many DNS lookups", or to find out which providers can send mail as a domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Do not include a scheme or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses the analysis scope (full include tree, DNS lookup count, authorized senders) and specific misconfigurations it flags (multiple SPF records, +all). This is substantive enough for an analysis tool, though it does not mention network behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first sentence front-loads the primary action and enumerates specific checks. The second sentence provides direct use cases. Every clause adds value, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter analysis tool with no output schema, the description explains the main behaviors and common triggers for use. It does not describe the exact output format, but the listed deliverables (lookup count, authorized services, flags) give a sufficient mental model for an agent to decide invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage on the single 'domain' parameter, including the example and instruction to exclude scheme/path. The description restates that it analyzes a domain's SPF record but does not add extra parameter-level detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Analyse a domain's SPF record' and then lists concrete capabilities (resolve include tree, count DNS lookups, identify authorized senders, flag misconfigurations). This clearly distinguishes it from sibling tools like scan_domain and check_tls by focusing exclusively on SPF analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'Use this for SPF PermError, "too many DNS lookups", or to find out which providers can send mail as a domain.' This provides clear context for when to choose this tool, though it does not mention when not to use it or name any alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a domain's TLS configuration in detail: certificate validity and expiry, issuer, key strength, the full certificate chain including whether intermediates are missing, and which TLS protocol versions the server actually accepts. Use this for certificate problems, expiry checks, "which TLS versions are enabled", PCI DSS protocol questions, or when a site works in browsers but fails in curl or other clients.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Do not include a scheme or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosing behavior. It clearly states that the tool performs a read-only inspection and lists the exact data points returned (validity, expiry, issuer, key strength, chain missing intermediates, TLS versions). This gives an agent a precise model of what will happen and what results to expect, with no unstated 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the purpose and scope with a list of details, and the second sentence gives usage guidance. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description is complete for this simple tool. It explicitly enumerates the return-relevant data (certificate validity/expiry, issuer, key strength, chain, TLS versions) and provides enough context for an agent to decide when and how to invoke it. The single parameter is well-documented in the schema, and the description fills any gaps about the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the `domain` parameter is described as 'The domain to check, e.g. example.com. Do not include a scheme or path.' The tool description adds no further parameter semantics, so the baseline score of 3 applies—the schema already provides the necessary meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and resource ('domain's TLS configuration'), and enumerates exactly what is inspected (certificate validity, issuer, key strength, chain, TLS versions). This clearly distinguishes it from sibling tools like scan_domain and analyse_spf, which target broader or different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('Use this for certificate problems, expiry checks...') and even mentions a subtle real-world scenario (works in browsers but fails in curl). It lacks explicit alternatives or when-not-to-use instructions, but the use-case list is sufficiently clear and targeted, so this is not a major gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a domain's full security posture: SPF, DKIM, DMARC and MTA-STS email authentication, TLS certificate and protocol support, and HTTP security headers. Use this whenever asked whether a domain is configured securely, whether it can be spoofed, or to review a domain's email or web security. Returns live results from public DNS records and TLS handshakes.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to check, e.g. example.com. Do not include a scheme or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context by stating the tool returns 'live results from public DNS records and TLS handshakes,' indicating a read-only, real-time scan. It also lists the specific security checks performed, giving the agent a clear model of behavior. However, it doesn't mention any potential side effects, rate limits, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: the first states the core purpose and scope, the second provides usage triggers, and the third explains the method and return type. There is no redundant content, and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple single-parameter schema and no output schema, the description provides sufficient context for an agent to select and invoke the tool correctly. It covers the tool's purpose, when to use it, what it checks, how it works, and what it returns. This is complete for the tool's complexity and complements the sibling tools effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'domain' parameter with 100% coverage, including an example and constraint ('Do not include a scheme or path'). The description adds no new semantic detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 a specific verb ('Check') and resource ('a domain's full security posture'), and enumerates concrete components (SPF, DKIM, DMARC, MTA-STS, TLS, HTTP headers). It distinguishes itself from sibling tools like check_tls and analyse_spf by offering a comprehensive security review rather than a focused check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this whenever asked whether a domain is configured securely, whether it can be spoofed, or to review a domain's email or web security.' This gives clear context, but it does not explicitly mention when to choose the specialized siblings (check_tls, analyse_spf) instead, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools share a common domain, but scan_domain is clearly a broad assessment while check_tls and analyse_spf are deep dives. Overlap exists, but the descriptions effectively guide selection for specific use cases.
All tools use a consistent verb_noun pattern with snake_case (scan_domain, check_tls, analyse_spf). The verbs differ but the structure is uniform and predictable.
Three tools is lean but appropriate for the narrow scope of domain security posture. It avoids bloat, though a few more specialized tools (e.g., for DKIM/DMARC) could round out the set.
The broad scan_domain covers email and web security comprehensively, while check_tls and analyse_spf provide deep dives for two key areas. Missing are specialized deep dives for DKIM and DMARC, but those are still accessible through scan_domain, so it's a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Email posture for any domain: can it receive mail, can it be spoofed? MX, SPF and DMARC.
Check if a domain can be email-spoofed: SPF, DMARC, DKIM, MX graded from public DNS. Authless.
Scan and fix a domain's email deliverability (SPF, DKIM, DMARC, MTA-STS, BIMI, DNS blocklists).
Monitor and manage email authentication (SPF, DKIM, DMARC, MTA-STS, BIMI) for your domains.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mvg777/posturecheck-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
