The alderpost-mcp server provides 8 pay-per-call intelligence endpoints (via USDC on Base mainnet) covering domain security, company research, threat analysis, compliance, sales prospecting, sports, property, and health.
domain_shield — Scan a domain for SPF, DKIM, DMARC, SSL, MX, DNSSEC, and malware (VirusTotal), returning a 0–100 security score.
company_xray — Get company intelligence including industry, employees, revenue, tech stack, social presence, and verified contacts from 9 premium sources.
threat_pulse — Analyze an IP/domain for blacklists, open ports, SSL issues, malware, and abuse reports across 7 sources.
compliance_check — Audit IT security compliance covering email authentication, OWASP headers, cookies, privacy policies, and DNSSEC, with letter grades.
prospect_iq — Generate sales intelligence for a domain including web presence, tech stack, verified contacts, and social signals, scored 0–100.
sports_edge — Access pre-game sports intelligence with standings, odds from 15+ bookmakers, and AI-generated analysis for NBA, NFL, MLB, NHL, MLS, or EPL.
property_intel — Analyze a physical address for amenities, schools, demographics, elevation, and walkability from 7 sources, scored 0–100.
health_signal — Look up drugs or food items for FDA labels, adverse events, recalls, drug interactions, and nutrition information with a risk score.
Incorporates OWASP security standards for web application security assessments, specifically checking OWASP headers as part of the compliance_check tool's comprehensive security audit capabilities.
Integrates with Qualys SSL Labs for comprehensive IT security compliance audits, including SSL/TLS analysis, email authentication, OWASP headers, cookies, privacy, and DNSSEC checks as part of the compliance_check tool.
Leverages VirusTotal's malware scanning capabilities for domain security analysis (SPF, DKIM, DMARC, SSL, MX, DNSSEC + 70+ malware engines) and threat intelligence (blacklists, ports, SSL analysis, IP abuse reports).
MCP server for Alderpost Intelligence API — 8 bundled intelligence endpoints powered by premium data sources. Pay-per-call via x402 USDC on Base.
Tool | Price | Premium Sources | Description |
| $0.12 | VirusTotal | SPF, DKIM, DMARC, SSL, MX, DNSSEC + malware scan (70+ engines). Scored 0-100. |
| $0.15 | People Data Labs, Hunter.io | Industry, employees, revenue, tech stack, verified contacts. 9 sources. |
| $0.10 | VirusTotal, AbuseIPDB | Blacklists, ports, SSL + malware detection + IP abuse reports. 7 sources. |
| $0.15 | Qualys SSL Labs | Email auth, OWASP headers, cookies, privacy, DNSSEC. 8 checks letter graded. |
| $0.12 | People Data Labs, Hunter.io | Web presence, tech stack, verified contacts, social signals. Sales scored. |
| $0.12 | ESPN, The Odds API, Claude AI | Standings, odds from 15+ bookmakers, AI-generated game analysis. |
| $0.10 | US Census, OpenWeather | Amenities, schools, demographics, elevation, walkability. 7 sources. |
| $0.10 | NIH RxNorm, FDA | Drug interactions, adverse events, recalls, nutrition. Risk scored. |
Related MCP server: x402-api
Add to your MCP config:
{
"mcpServers": {
"alderpost": {
"command": "npx",
"args": ["-y", "alderpost-mcp"]
}
}
}npx -y alderpost-mcpEach tool calls an Alderpost x402 endpoint. Endpoints return scored JSON with findings and recommendations. Payment is handled via x402 protocol — USDC on Base mainnet.
One call to Alderpost replaces 5-8 individual API lookups. Example: domain_shield checks SPF, DKIM, DMARC, SSL, MX, DNSSEC, WHOIS, and VirusTotal in a single $0.12 request.
MIT — Alderpost LLC
Company intelligence: tech stack, infrastructure, social presence, business signals. 8 data sources scored 0-100. Price: $0.50 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain (e.g. stripe.com) |
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.
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.
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.
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.
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.
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.
IT security compliance audit: email auth, SSL/TLS, OWASP headers, cookies, privacy, DNSSEC. 8 checks letter graded. Price: $0.85 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to audit (e.g. stripe.com) |
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.
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.
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.
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.
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.
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.
Domain security scan: SPF, DKIM, DMARC, SSL, MX, DNSSEC. 7 checks scored 0-100. Price: $0.25 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan (e.g. example.com) |
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.
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.
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.
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.
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.
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.
Health intelligence: FDA drug labels, adverse events, recalls, nutrition. Risk scored. Price: $0.30 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Drug name or food item (e.g. ibuprofen) | |
| type | No | drug, food, or auto (default: auto) |
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.
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.
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.
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.
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.
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.
Location intelligence: geocoding, amenities, schools, elevation, walkability. Scored 0-100. Price: $0.75 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full address (e.g. 123 Main St Milwaukee WI) |
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.
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.
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.
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.
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.
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.
Sales intelligence: web presence, tech stack, social signals, contact readiness. 7 data sources scored 0-100. Price: $0.40 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to analyze (e.g. example.com) |
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.
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.
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.
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.
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.
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.
Pre-game sports intelligence: standings, odds, AI-generated analysis. Price: $0.50 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | Yes | Sport key: nba, nfl, mlb, nhl, mls, epl | |
| team | No | Team name filter (e.g. lakers) |
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.
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.
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.
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.
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.
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.
Threat intelligence: blacklists, open ports, SSL analysis, email security. 6 DNSBLs scored 0-100. Price: $0.35 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | IP address or domain (e.g. 8.8.8.8 or example.com) |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0company_xraycompliance_checkdomain_shieldhealth_signalproperty_intelprospect_iqsports_edgethreat_pulseScored across 8 tools
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.
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.
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.
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.
8 pay-per-call web intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.