alderpost-mcp

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 different domains: company intelligence, compliance, domain security, health data, property intelligence, sales intelligence, sports analysis, and threat intelligence. The descriptions specify unique data sources and checks, leaving no ambiguity about which tool to use for each task.
Naming Consistency5/5
All tool names follow a consistent noun_adjective or noun_noun pattern (e.g., company_xray, compliance_check, domain_shield), with clear and descriptive terms. There are no deviations in style or convention across the set.
Tool Count5/5
With 8 tools, the count is well-scoped for a server offering diverse intelligence and security services. Each tool covers a specific niche, and the number is neither too sparse nor overwhelming for the broad domain of data analysis and risk assessment.
Completeness4/5
The tool set provides comprehensive coverage across multiple domains (business, security, health, property, sales, sports, threats), with each tool offering detailed analysis. A minor gap is the lack of tools for post-analysis actions like reporting or integration, but the core intelligence-gathering functions are complete.
Average 3.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is 'risk scored' which implies some analysis beyond raw data retrieval, but doesn't specify what the scoring entails, how results are formatted, or any limitations (e.g., data freshness, coverage). The pricing information ('Price: $0.30 USDC on Base') suggests a transactional cost but doesn't clarify if this is per call or has other implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but has structural issues. The first sentence packs multiple concepts (FDA sources, risk scoring), while the pricing information feels tacked on rather than integrated. It's front-loaded with the core functionality, but the pricing detail might be better placed elsewhere in tool metadata rather than in the description.
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 health intelligence data and the absence of both annotations and output schema, the description is insufficient. It doesn't explain what 'risk scored' means in practice, what format results take, or any limitations of the FDA data coverage. For a tool with 2 parameters and no structured output documentation, more guidance on expected results and behavioral characteristics is needed.
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 the schema already documents both parameters (query and type) adequately. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how the 'type' parameter affects results or provide examples beyond the schema's 'drug, food, or auto' enum. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 tool provides health intelligence data from FDA sources (drug labels, adverse events, recalls, nutrition) with risk scoring. It specifies the resource domain (FDA-regulated health information) and the action (intelligence gathering with scoring), though it doesn't explicitly differentiate from sibling tools like 'compliance_check' or 'threat_pulse' which might also involve risk assessment.
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. While it mentions the data sources (FDA drug labels, adverse events, etc.), it doesn't specify use cases, prerequisites, or exclusions. There's no comparison to sibling tools like 'compliance_check' that might also handle regulatory data.
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 provided, the description carries full burden for behavioral disclosure. It mentions pricing ($0.50 USDC on Base) which hints at a paid service, but doesn't describe authentication requirements, rate limits, error conditions, or what happens when the tool is invoked. The description doesn't contradict any annotations (none exist), but provides minimal behavioral context beyond the commercial aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but has structural issues. The first sentence clearly states the purpose, but the second sentence about pricing feels tacked on and doesn't help the AI agent understand tool functionality. While not verbose, the description isn't optimally front-loaded with only the most essential information for tool selection.
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?
For a tool with 2 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the AI-generated analysis includes, how standings and odds are presented, or what format the output takes. The pricing information doesn't compensate for these gaps in understanding the tool's behavior and output.
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 the schema already fully documents both parameters (sport with allowed values, team as filter). The description adds no parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, with no value added by the description.
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 tool's purpose: providing pre-game sports intelligence including standings, odds, and AI-generated analysis. It specifies the resource (sports data) and verb (intelligence gathering), but doesn't differentiate from sibling tools since all siblings appear to be in different domains (company, compliance, health, etc.). The mention of pricing is extraneous but doesn't obscure the core purpose.
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. While the domain is clearly sports-related, there's no mention of specific use cases, prerequisites, or comparisons to other sports data tools that might exist elsewhere. The pricing information hints at a commercial context but doesn't constitute usage guidance.
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 provided, the description carries the full burden of behavioral disclosure. It mentions '6 DNSBLs scored 0-100' and a price, but doesn't describe what the tool actually does behaviorally (e.g., how it performs the analysis, what the output looks like, rate limits, or authentication needs). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but somewhat disorganized, mixing functional details (blacklists, open ports) with operational details (price, DNSBL scoring) without clear front-loading of the core purpose. It could be more structured to prioritize the tool's main function.
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 no annotations and no output schema, the description is incomplete for a tool that performs threat intelligence analysis. It lists features but doesn't explain what the tool returns, how results are formatted, or any behavioral traits, leaving the agent with insufficient context to use it effectively.
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 description coverage is 100%, so the schema already documents the single 'target' parameter. The description adds no additional meaning or context about the parameter beyond what's in the schema, such as examples of valid inputs or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
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 tool provides threat intelligence services (blacklists, open ports, SSL analysis, email security) and mentions DNSBL scoring, which gives a specific scope. However, it doesn't distinguish this from sibling tools like 'domain_shield' or 'compliance_check' that might also handle security-related functions, so it lacks sibling differentiation.
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 mentions a price point ($0.35 USDC on Base), which implies a cost consideration, but doesn't specify scenarios, prerequisites, or exclusions compared to sibling tools like 'domain_shield' or 'compliance_check'.
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 provided, the description carries the full burden of behavioral disclosure. It mentions the cost and data sources, but fails to describe critical behaviors: whether this is a read-only operation, if it requires authentication, rate limits, latency, error handling, or what the output format looks like (beyond scores 0-100). For a paid tool with potential side effects, this is a significant gap.
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 efficiently structured in two sentences: one outlining the intelligence scope and data sources, and another stating the price. It's front-loaded with key information and avoids unnecessary details, though the price mention could be integrated more smoothly.
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 (paid tool with multiple data sources) and lack of annotations or output schema, the description is incomplete. It doesn't explain the return values, how scores are interpreted, error conditions, or authentication needs. This leaves significant gaps for an agent to use the tool effectively.
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 100% description coverage, with the single parameter 'domain' clearly documented. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't clarify if subdomains are allowed or format constraints). Baseline 3 is appropriate when the schema does the heavy lifting.
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 tool provides 'company intelligence' across specific categories (tech stack, infrastructure, social presence, business signals) and mentions 8 data sources with scores. It distinguishes from siblings like 'compliance_check' or 'threat_pulse' by focusing on general business intelligence rather than specialized domains. However, it doesn't specify the exact verb (e.g., 'analyze' or 'retrieve') which prevents a perfect score.
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 like 'property_intel' or 'prospect_iq'. It mentions the price ($0.50 USDC on Base), which hints at cost considerations, but doesn't explain the trade-offs, prerequisites, or specific use cases that would help an agent choose between sibling tools.
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?
With no annotations provided, the description carries the full burden. It discloses the 7 security checks performed and the scoring range (0-100), which adds useful behavioral context. However, it doesn't mention rate limits, authentication needs, error handling, or what happens during the scan process beyond the listed checks.
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 appropriately sized with two sentences that efficiently convey the scan purpose, checks, scoring, and pricing. Every element serves a purpose, though the pricing information could be considered slightly extraneous to the core functionality.
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 single-parameter tool with no annotations and no output schema, the description provides adequate context about what the tool does and what it returns (7 checks scored 0-100). However, it lacks details on output format, error cases, or how results are structured, leaving some gaps in 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?
The input schema has 100% description coverage with a clear parameter description for 'domain'. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, so it meets the baseline of 3 for high schema coverage.
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 tool performs a 'Domain security scan' with specific checks listed (SPF, DKIM, DMARC, SSL, MX, DNSSEC), which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'threat_pulse' or 'compliance_check' that might also involve security assessments.
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 mentions a price of $0.25 USDC, which implies a cost consideration, but doesn't specify when this tool is appropriate compared to other security-related sibling tools or general contexts.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pricing, which adds useful context about cost, but lacks details on rate limits, authentication needs, error handling, or what specific 'location intelligence' entails beyond listed features. The description doesn't contradict annotations, but it's incomplete for a tool with potential complexity.
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 front-loaded with key functionality and includes pricing in a single, efficient sentence. It avoids unnecessary details, but could be more structured by separating features from cost information. Overall, it's concise with minimal waste, though minor improvements in organization are possible.
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 annotations and no output schema, the description provides basic functionality and cost, but lacks details on return values, error cases, or behavioral traits. For a tool with one parameter and moderate complexity (scoring multiple aspects), it's adequate but has clear gaps in completeness, such as not explaining the scoring methodology or output format.
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 100% description coverage, with the 'address' parameter well-documented. The description doesn't add any parameter-specific semantics beyond what the schema provides, such as format examples or constraints. However, it does imply that the address is used for geocoding and scoring, which slightly enhances understanding, but not enough to exceed the baseline.
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 tool provides location intelligence services including geocoding, amenities, schools, elevation, and walkability with scoring. It specifies the resource (location data) and outputs (scores 0-100). However, it doesn't explicitly differentiate from sibling tools like 'company_xray' or 'health_signal' that might also provide location-related data, keeping it from a perfect score.
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 includes pricing information ($0.75 USDC on Base), which implies a cost context, but provides no guidance on when to use this tool versus alternatives. There are no explicit instructions on use cases, prerequisites, or comparisons with sibling tools, leaving the agent without clear selection 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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it aggregates data from '7 data sources', provides scores '0-100', and has a cost ('Price: $0.40 USDC on Base'). However, it doesn't mention rate limits, authentication needs, error handling, or what happens with invalid domains, leaving gaps for a tool with financial implications.
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 appropriately sized and front-loaded with the core purpose ('Sales intelligence'). The second sentence adds useful details (data sources, scoring, price) without redundancy. However, the price information could be more integrated with the purpose, and there's minor room to tighten phrasing.
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 complexity (sales intelligence with scoring and cost), no annotations, and no output schema, the description is moderately complete. It covers the purpose, data sources, scoring, and cost, but lacks details on output format, error cases, or performance characteristics, which are important for a paid tool with no structured output documentation.
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 100% description coverage, with the single parameter 'domain' well-documented. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., no examples of valid domains beyond the schema's 'e.g. example.com'), so it meets the baseline of 3 for high schema coverage without compensating value.
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 tool performs 'Sales intelligence' with specific capabilities: analyzing web presence, tech stack, social signals, and contact readiness. It provides a specific verb ('Sales intelligence') and resource (domain analysis), though it doesn't explicitly differentiate from sibling tools like 'company_xray' or 'domain_shield' which might have overlapping domains.
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 mentions 'Sales intelligence' which implies usage in sales contexts, but provides no explicit guidance on when to use this tool versus alternatives like 'company_xray' or 'domain_shield'. There are no when/when-not statements or named alternatives, leaving the agent to infer usage from the general domain.
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 provided, the description carries full burden. It discloses key behavioral traits: it's a paid service ($0.85 USDC on Base), performs 8 specific security checks, and outputs letter grades. However, it doesn't mention rate limits, authentication requirements, or what happens if the domain is invalid.
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 appropriately sized and front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second adds pricing details. However, the list of checks could be slightly more structured.
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 annotations and no output schema, the description adequately covers the tool's purpose and cost, but lacks details on output format (beyond 'letter graded'), error handling, or integration context. For a paid auditing tool with 8 checks, more completeness would be helpful.
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 the schema already documents the single 'domain' parameter. The description adds no additional parameter semantics beyond what the schema provides, maintaining the baseline score of 3.
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 performs an IT security compliance audit with 8 specific checks (email auth, SSL/TLS, OWASP headers, cookies, privacy, DNSSEC) and provides letter grades. It distinguishes itself from siblings like 'threat_pulse' or 'domain_shield' by focusing on comprehensive compliance auditing rather than threat detection or domain protection.
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 security compliance auditing of domains, but doesn't explicitly state when to use this versus alternatives like 'domain_shield' or 'threat_pulse'. It mentions the price ($0.85 USDC on Base), which suggests a paid service context, but lacks clear guidance on prerequisites or exclusions.
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:

[![alderpost-mcp MCP server](https://glama.ai/mcp/servers/8randonpickart5/alderpost-mcp/badges/card.svg)](https://glama.ai/mcp/servers/8randonpickart5/alderpost-mcp)

Score Badge

Copy to your README.md:

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

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