x402tools MCP Server

Server Quality Checklist

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

Latest release: v1.8.0
Disambiguation5/5
Each tool targets a clearly distinct purpose: QR generation (but two variants), screenshots, DNS, document parsing, security screening, email validation, OCR, prospect enrichment, and word stats. The only minor overlap is between qr.generate and qr.generate_styled, but the styling distinction is explicit enough. No tools could be confused despite the varied domains.
Naming Consistency3/5
Tools follow a dotted namespace convention (category.verb), which is somewhat consistent, but the verbs vary: generate, screenshot, lookup, parse, screen, validate, render_pdf, ocr, enrich, wordstats. Some are nouns (screenshot, ocr, wordstats) rather than verbs, and generate_styled mixes into the verb form. The namespace prefixing helps, but verb usage is internally inconsistent across all tools.
Tool Count5/5
Eleven tools is well within an appropriate range and each serves a distinct paid utility purpose. This is a pay-per-call API toolkit where breadth across domains is intentional; the count feels well-scoped and not bloated for a general-purpose utility server.
Completeness4/5
For a general utility server, the coverage is reasonable, offering generation, capture, lookup, parsing, validation, security, OCR, enrichment, and text analysis. Minor gaps exist: there's no tool to delete/update results (not applicable since stateless), and no obvious companion for image.screenshot (e.g., file storage) or for document.parse (image extraction). But as a stateless utility surface it feels complete enough for its purpose.
Average 4.1/5 across 11 of 11 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds the $0.05 cost disclosure, which is genuinely useful behavioral context beyond annotations. It does not contradict annotations. However, it doesn't disclose the payment-required behavior trait (that calls without _payment will fail on first attempt) in the main description, though this is partly covered in the parameter description. With annotations already covering safety, a 3 is fair.
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 a single efficient sentence that captures purpose and cost without waste. It's appropriately brief given the rich schema coverage. Not quite a 5 because it could use the front-loading opportunity to add one more differentiator (e.g., 'Use for branded/visually customized QR; use qr.generate for standard QR'), but it's lean and effective.
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?
The tool has 10 params, 100% schema coverage, an output schema, and strong annotations. The description covers the styling angle and cost. The payment workflow is the main gap - the agent needs to understand the two-step payment flow (call without _payment, get requirements, retry), which is only hinted in the parameter description, not the tool description. Still, the combination of schema + annotations + 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?
Schema coverage is 100%, so the schema documents all 10 parameters with descriptions. The description adds the pricing detail and the payment flow hint but doesn't add meaning to individual parameters beyond schema descriptions. Baseline 3 for high coverage is appropriate - the description doesn't need to repeat parameter detail.
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 it generates an artistic/styled QR code with custom shapes, colors, and gradients - a specific verb+resource. It distinguishes from the sibling qr.generate by emphasizing styling/customization, though it could be more explicit about how it differs from the plain version.
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 cost mention ('Costs $0.05 USDC') and the _payment parameter guidance ('Get the requirements from a first call without _payment, then retry.') give useful contextual guidance. However, there's no explicit statement of when to use this vs qr.generate (plain QR) or when NOT to use it, leaving the agent to infer the differentiation from the word 'styled.'
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile well. However, the description carries additional burden for the payment mechanism. It mentions the cost ($0.05 USDC on Base) but does NOT explain the two-step payment flow in the description itself—this is only buried in the _payment parameter description. For a tool that requires a complex payment handshake, this is a significant behavioral disclosure gap.
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 tightly-written sentence followed by a cost note. Every word earns its place—it states the input, output, and cost in minimal space. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (6 params, payment mechanism, output schema present). The description covers the core purpose and cost. The output schema exists, so return values need not be explained. The main gap is that the payment flow (two-step process with _payment) is not disclosed at the description level, but this is partially compensated by the schema and the fact that it's discoverable. Given output schema presence and 100% param coverage, a 4 is appropriate.
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 all 6 parameters with descriptions. The tool-level description adds marginal value by naming the two input modes (html OR url). However, it does not clarify the relationship or precedence between html and url, nor does it explain the payment flow that the _payment parameter requires beyond what the schema says. The schema carries most of the burden here.
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 ('Convert') with clear resources ('raw HTML or a public URL') and a clear output ('PDF document'). It clearly distinguishes this from sibling tools like document.parse, image.screenshot, and image.ocr. The purpose is immediately obvious and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the input types (raw HTML or public URL), which helps with when to use it. It also mentions the payment cost which sets expectations. However, it doesn't explicitly state when NOT to use it or name alternative tools for similar rendering tasks (like image.screenshot for image output), though sibling differentiation is largely implied by the distinct output type.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the cost ($0.03 USDC on Base) as behavioral/financial disclosure, which is useful beyond annotations. However, it doesn't disclose rate limits, response format details, or failure behavior when checks fail — but does note the paid POST first-call-then-retry pattern in the _payment schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences plus a cost line. Every word earns its place: lists the checks performed, notes the risk score output, and quotes the exact price. No filler, no repetition of the title.
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?
Output schema exists, reducing burden on description. Tool complexity is moderate (validation checks + paid access + optional SMTP probe). The description covers the core checks, the cost, and the two-call payment flow is covered in the schema. Slightly lacking clarity on risk score scale/output format, but output schema presumably handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all 3 parameters are documented in the schema. The description adds the notion that checkSmtp is optional enrichment and that _payment requires a first call to obtain requirements, but the schema already explains the two-step signing flow well. The description's main added value is signaling which checks are default (syntax, MX, disposable) vs optional (SMTP).
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?
Clear specific verb (validate/verify) with resource (email address) and enumeration of what checks occur (syntax, MX records, SMTP, disposable domains, risk score). Distinct from all 11 siblings, none of which do email validation. The risk score and cost details further differentiate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use (when you need to validate/verify an email) but doesn't explicitly name alternatives or exclusions. The _payment parameter details a clear two-step flow (first call without _payment, then retry with signed payload) which is valuable operational guidance. Lacks explicit 'use X instead when...' guidance but context is reasonably clear.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true — the safety profile is fully covered. The description adds value by disclosing the cost ($0.05 USDC on Base), which is genuinely useful behavioral information an agent wouldn't know from annotations alone. The _payment parameter flow is also referenced in the schema though not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. The first sentence states the core function and the second adds the key cost information. Every word earns its place and the description is front-loaded with the primary purpose.
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?
The tool has a full input schema covering 5 params, an output schema exists, and annotations fully cover read-only/idempotent/open-world behavior. With an output schema present, the description needn't explain return values. The only potential gap is guidance on format choices or language nuances, but given the rich schema and annotations, the description is adequate for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 5 parameters are already documented in the input schema. The description adds no additional parameter context beyond what the schema provides — baseline 3 is appropriate when the schema carries the full documenting burden. It doesn't clarify format semantics (text vs json vs hocr) beyond what the schema enumerates, but that's not required at 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('Extract text from an image using OCR'), which is specific and unambiguous. The description distinguishes it from siblings like image.screenshot (which captures screenshots) and document.parse (which likely parses documents). The tool name image.ocr — with section 'image.' separating it from qr.* and document.* siblings — plus an explicit OCR purpose leaves no ambiguity.
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 states what the tool does but provides no explicit when-to-use guidance or exclusions versus alternatives. There's no mention of alternatives like document.parse for document-based extraction. The payment context ('Costs $0.05 USDC on Base') is helpful contextual usage guidance but doesn't address when to reach for this tool versus siblings.
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?
Annotations declare readOnlyHint=true, destructiveHint=false, and the description aligns. It discloses the $0.05 USDC cost and the two-phase payment flow (call without _payment first, then retry), which is valuable behavioral transparency. However, it doesn't detail failure modes, rate limits, or output format beyond what the output schema covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero wasted words. The feature list (dark mode, full-page, element selection) and the cost disclosure deliver maximum information per sentence.
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?
With 100% schema coverage, an output schema present, and readOnly annotations, the description is complete for its complexity. The intentional two-phase payment flow is adequately explained, and the feature set is well covered. No major gaps identified.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the _payment parameter's workflow (sign locally, call without it first to get requirements, then retry), which significantly aids correct invocation. The two-phase payment protocol is meaningful additional semantics beyond the schema.
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 action ('Capture a screenshot of any website') and lists key capabilities (dark mode, full-page, element selection). It distinguishes well from siblings like image.ocr and document.render_pdf, though it doesn't explicitly name alternatives.
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 gives clear context on what the tool does but does not explicitly state when to use it vs alternatives or when NOT to use it among the sibling tools. The pricing disclosure adds useful context for when to deploy (cost-aware decisions), but no alternative tool is named.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is well-covered. The description adds value by disclosing the payment cost ($0.01 USDC) which is a genuine behavioral trait beyond annotations. It also reveals the return format (PNG base64). No contradiction with annotations found.
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?
Three short sentences with zero waste. Each sentence earns its place: purpose, output format, and cost. Information is front-loaded with the core purpose stated first.
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 relatively simple generate tool, the description is complete: it states purpose, output format, and cost. The output schema exists, so return values don't need elaboration. The _payment parameter is complex but already thoroughly documented in the schema itself. Could mention pagination/limits but none apply to QR generation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 4 parameters are already documented in the schema, including the size default, format enum, and _payment instructions. The description adds the output-format detail (PNG base64) and cost context, but doesn't add meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Generate a QR code') with clear scope ('from text or URL'). It also states the output format (PNG image as base64) and distinguishes from the sibling tool qr.generate_styled by implying standard QR generation. Purpose is fully clear.
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 context (encode text/URL into QR) but offers no explicit when-to-use vs alternatives guidance. There's no mention of when to use qr.generate vs qr.generate_styled, or exclusions. The cost mention ($0.01 USDC on Base) adds a practical usage signal but not comparison guidance.
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?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. Description adds meaningful context: costs $0.01 USDC, requires public URL (not private/auth-needed pages), auto-detects doc type. However, it doesn't disclose pagination, size limits, rate limits, or failure modes (e.g., what happens with unsupported formats). Since annotations carry the safety burden, a 3 is appropriate.
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 main description is a tight two-sentence summary with zero waste. The cost info and input types are efficiently packed. The _payment parameter description is longer but earns its length by explaining the signing flow and security guarantee (private key never leaves machine). Slightly verbose in the payment param, but justifiably so.
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 an output schema present, return format need not be described. The four parameters are fully documented. The description covers input restrictions (public URL), cost, auto-detection, and the payment flow. Gaps: doesn't mention size limits, supported doc complexity, or error handling for unparseable content, but for a single-required-param tool with rich annotations and full schema coverage, this is quite complete.
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?
Schema description coverage is 100%, so the schema documents all four parameters. The description adds value by noting 'Auto-detects doc type' which clarifies the output_schema=auto default behavior, and the payment parameter description in the schema provides rich signing guidance. The description itself doesn't add param detail beyond the 100% coverage, but the baseline 3 plus the auto-detection clarification around output_schema justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb+resource: 'Parse any public HTML page or PDF URL into clean structured JSON.' It names the input types (HTML/PDF URLs), the output format (structured JSON), and auto-detection of doc type. Clear differentiation from siblings like image.ocr (image OCR) and document.render_pdf (PDF creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies the input requirement ('public' URL), which implies the access constraint. It notes cost and payment (USDC on Base), giving context. However, it does not explicitly state when to use this vs. document.render_pdf or image.ocr, though the purpose clarity makes the distinction fairly obvious. The _payment parameter documentation covers the auth flow well.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read operation. The description adds valuable context about the x402 pay-per-call payment model, cost ($0.001), and chain (eip155:8453), which is significant behavioral disclosure beyond what annotations provide. It doesn't describe the output format, but the output schema exists to cover that.
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 that front-load the core function, then add essential payment context. Every sentence earns its place — no filler, no repetition of schema content. Concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple text-analysis tool with 100% schema coverage, an output schema present, and readOnly annotations declaring safety, the description covers the essential behavioral aspects: what it computes, the payment model, cost, chain, and the signing workflow. The two-call payment discovery flow is the key non-obvious behavior, and it's disclosed effectively.
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?
Schema coverage is 100%, so parameters are well-documented structurally. The description adds value by explaining the use-case context for the text parameter ('a block of text') and clarifying the _payment parameter's role as a signed payment payload with the two-call retry flow. The _payment parameter's practical mechanics (sign locally, private key never leaves machine, first-call-then-retry flow) is meaningfully explained beyond 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 verb (Return) plus the specific resource (word count, character count, average word length) for a text input. It distinguishes from siblings by describing a text-analysis function that none of the sibling tools (qr, screenshot, dns, ocr, enrich) perform.
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 explains it processes 'a block of text' and mentions the pay-per-call nature with cost/pricing details. However, it doesn't explicitly say when to use vs alternatives or provide exclusions. The payment workflow is partially described (first call without _payment, then retry) but there's no explicit guidance on when this tool is preferable to other text 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?
Annotations provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false — a strong safety profile. The description adds the critical cost disclosure ($0.02 USDC on Base), which is behavioral transparency beyond annotations. It also conveys the payment-gated nature of the call. The payment flow detail is actually in the schema parameter description rather than the main description, which slightly limits credit.
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: states the action, enumerates supported record types, scopes to any domain, and discloses cost. Every word earns its place. The payment mechanics are appropriately delegated to the parameter schema rather than bloating the description.
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?
The tool is simple (2 params, 1 required, no enums, no nesting) with a full output schema, so the description doesn't need to explain return values. The cost disclosure and record-type enumeration make it reasonably complete for agent invocation. The only gap is that no explicit note about rate limits or auth flow prerequisites beyond _payment appears in the main description, though the _payment param description covers the flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters are described in the schema). The _payment parameter has rich semantics explaining the signing process, local key handling, and the two-step retry pattern. The description adds the pragmatic cost dimension. With complete schema coverage and strong parameter descriptions, this earns a high score.
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?
Description states a clear verb+resource ('Look up DNS records') and lists specific record types (A, AAAA, MX, NS, TXT, SOA) for a domain. It's distinct from sibling tools which cover QR, images, documents, email, OCR, etc. However, it doesn't explicitly name any sibling as an alternative for related lookups, though none of the siblings are network lookup tools, so differentiation is inherently clear.
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 (looking up DNS records for any domain) and provides the cost context. It mentions the payment requirement in the schema parameter description, explaining the two-step flow (call without _payment first, then retry). No exclusionary guidance against alternatives exists, but none of the siblings do DNS lookups, so this is acceptable.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds material behavioral context beyond those annotations: it discloses the monetary cost ($0.50 USDC on Base) and hints at the paid, two-call payment flow via the _payment param description. This adds genuine value for an agent deciding whether to invoke a paid tool. Slightly room for more (e.g., what the email pattern looks like), but solid.
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?
Three concise sentences: the main capability, the use cases, and the cost. All front-loaded with the core purpose first. The description is efficient with no wasted words. The one minor deduction is that cost and payment could be positioned more prominently since it's a paid tool, but the current structure is clean and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool whose output is a rich prospect profile (seniority, persona, decision-maker probability, etc.), the description front-loads the output surface clearly. The output schema exists, so return format is covered by structured data. The paid/payment-flow nuance is addressed. What's missing: any caveats about accuracy, turnaround time, or cases where enrichment might fail (e.g., unknown domain). Given good annotations and output schema, this is reasonably complete.
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?
Schema coverage is 100%, so the schema documents all 5 parameters. The description adds meaning beyond this by explaining the output relationship (name + domain as the two required inputs that drive the enrichment). The _payment parameter, in particular, gets valuable supplementary detail in the description about signing locally with @x402/evm/@x402/fetch and the 'first call without _payment, then retry' flow — context the schema alone doesn't convey. Baseline 3 elevated for the _payment guidance.
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 ('turn... into') plus a precise resource ('a sales-ready prospect profile') and enumerates the concrete outputs: seniority, buyer persona, decision-maker probability, company intel, email pattern, and cold-email opener. This clearly differentiates it from sibling tools (qr.generate, dns.lookup, email.validate, document.parse), which are unrelated domains, and it names the use cases (AI SDRs, lead enrichment, outbound personalisation).
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 states clear contexts for use: AI SDRs, lead enrichment, and outbound personalisation. It also flags the $0.50 cost, which is important usage context. It doesn't explicitly state when NOT to use it or name alternative enrichment tools among the siblings, but the siblings are all unrelated (QR, DNS, OCR, screenshots), so there's no competing tool to disambiguate. The 'use for' phrasing gives strong 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?
Annotations declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds value by disclosing the cost ($0.03 USDC on Base) and the payment mechanism, which is a significant behavioral trait. The description also mentions detection categories (10) giving functional scope beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. States purpose, scope, and cost efficiently. Front-loaded with the core function first.
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?
Has output schema and 100% schema coverage, so the description doesn't need to explain return values or params. For a single-purpose screening tool with readOnly annotations, the description plus schema fully covers what an agent needs to invoke it correctly, including the payment requirement.
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 documents all 5 parameters well. The description adds minimal param-specific detail (char limit mentioned in schema, sensitivity enum in schema). Baseline 3 is appropriate since the schema does the heavy lifting and description doesn't need to compensate.
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+resource ('Screen text for prompt injection and jailbreak attacks') and clearly states the core function before passing to an LLM. It distinguishes itself from sibling tools (qr, image, dns, etc.) by its unique security domain. Adding the 10 attack categories and cost provides concrete scope.
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 clearly states WHEN to use it ('before passing it to an LLM') which is explicit usage context. It doesn't name alternatives or exclusions, but the domain is distinct enough from siblings that alternatives aren't obviously relevant. The payment flow is described in the schema parameter._payment.
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:

[![x402tools-mcp MCP server](https://glama.ai/mcp/servers/acrylicfiddle/x402tools-mcp/badges/card.svg)](https://glama.ai/mcp/servers/acrylicfiddle/x402tools-mcp)

Score Badge

Copy to your README.md:

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

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