10 pay-per-call tools for AI agents: QR, screenshots, DNS, OCR, PDF, email & more. USDC on Base.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 11 of 11 tools scored. Lowest: 3.7/5.
Each tool targets a distinct service or domain (e.g., DNS, email, document parsing, OCR, QR generation, security screening). The only overlap is between qr.generate and qr.generate_styled, but the styling distinction is clear.
All tool names follow a consistent `category.operation` pattern (e.g., `dns.lookup`, `document.parse`, `image.ocr`). The operation part is always a verb or action-oriented noun, making the pattern predictable.
With 11 tools, the set covers a broad range of utility functions without being overwhelming. This count is ideal for a general-purpose pay-per-call server.
The tool set covers common web utility tasks (text, DNS, documents, email, images, QR, security, prospect enrichment) reasonably well. Minor gaps exist (e.g., no data conversion tool), but the coverage is solid for its stated purpose.
community.wordstatsWordstatsAReturn word count, character count, and average word length for a block of text. Costs $0.001 on eip155:8453. Community service (x402 pay-per-call).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Parameter "text" forwarded to the x402 service. | |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint, so the description's addition of cost and payment method adds useful context beyond annotations. It does not describe failure modes but is consistent.
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 two sentences: the first explains purpose, the second covers cost and nature. No wasted words, front-loaded with key information.
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 simple tool with full schema coverage, output schema presence, and annotations, the description covers purpose, cost, and payment. It could mention the need for a first failing call to get payment requirements, but overall complete.
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. The description does not add additional parameter-level meaning beyond what the schema provides, meeting 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 'Return word count, character count, and average word length for a block of text,' specifying the verb and resource. It distinguishes from sibling tools since no other tool offers word stats.
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 context about cost ($0.001 on eip155:8453) and the pay-per-call nature, helping the agent decide when to use it. However, it does not explicitly state when not to use or mention alternatives, though siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dns.lookupDNS LookupALook up DNS records (A, AAAA, MX, NS, TXT, SOA) for any domain. Costs $0.02 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to look up (e.g. example.com) | |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds the cost ($0.02 USDC) and the payment requirement, which is valuable beyond the annotations. No contradictions.
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 two sentences: the first states the purpose and scope, the second mentions cost. It is front-loaded and every sentence adds value with no fluff.
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?
The tool is simple (DNS lookup) with safety fully covered by annotations, an output schema present, and parameters fully described. The description efficiently conveys the operation and payment, making it complete for an agent to use correctly.
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%—both parameters (domain and _payment) have clear descriptions. The tool description does not add additional meaning beyond the schema; it mentions record types but that is about the operation, not parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and resource ('DNS records') and lists record types (A, AAAA, MX, NS, TXT, SOA). It clearly differentiates from unrelated sibling tools like document.parse or email.validate.
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 a cost and payment mechanism but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. However, the sibling tools are distinct, so confusion is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document.parseParse DocumentAParse any public HTML page or PDF URL into clean structured JSON. Auto-detects doc type. Costs $0.01 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL of HTML page or PDF to parse | |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. | |
| output_schema | No | Output schema type | auto |
| include_raw_text | No | Include raw extracted text |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds cost ($0.01 USDC on Base) and the auto-detection feature, which are valuable beyond the annotations. No contradictions.
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 extremely concise (three short sentences) covering all essential points: input type, output format, auto-detection, and cost. No fluff, front-loaded with the core purpose.
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 presence of a full output schema and rich annotations, the description is largely complete. It covers input types, output, and cost. Minor omissions like timeout or size limits are acceptable for this context.
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 coverage is 100% with detailed parameter descriptions. The description adds cost context but does not elaborate on parameter usage beyond what the schema provides. Baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses HTML pages or PDFs into structured JSON, with auto-detection of document type. It distinguishes itself from siblings like document.render_pdf by focusing on extraction rather than generation.
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 specifies when to use (for parsing public URLs of HTML/PDF) but does not explicitly mention when not to use or provide alternatives. However, the context is clear enough for an agent to select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document.render_pdfRender PDFAConvert raw HTML or a public URL into a PDF document. Costs $0.05 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public URL to render (provide html OR url) | |
| html | No | Raw HTML to render (provide html OR url) | |
| scale | No | Render scale, 0.1-2 | |
| format | No | Page size | A4 |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. | |
| landscape | No | Landscape orientation |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| encoding | No | Encoding of the binary payload (base64). |
| mimeType | No | MIME type of the returned binary payload (e.g. image/png, application/pdf). |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context: the cost ($0.05 USDC on Base) and the payment mechanism requiring two calls. This exceeds what annotations provide.
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 extremely concise: two sentences plus a contextual note on payment. Every sentence earns its place, and the purpose is front-loaded. No waste.
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 (6 parameters, payment flow, cost) and the presence of an output schema, the description covers the core purpose, cost, and key process. It lacks details on error handling or output format, but the schema covers parameters and output. Sufficiently complete for a conversion tool.
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 coverage is 100%, so the description's role is to add nuance. It clarifies the _payment parameter usage (Base64-encoded signed v2 PaymentPayload, suggesting libraries) and reiterates the html/url mutual exclusivity. This adds value beyond the schema.
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 converts raw HTML or a public URL into a PDF, using a specific verb and resource. It distinguishes from sibling tools (e.g., document.parse, image.screenshot) which have different purposes.
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 the cost and the two-step payment process (call without _payment first), providing context for usage. However, it does not explicitly state when to use this tool versus alternatives, though none of the siblings perform PDF conversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
email.validateValidate EmailAValidate and verify an email address. Checks syntax, MX records, SMTP deliverability, disposable domains, and returns a risk score. Costs $0.03 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to validate | ||
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. | |
| checkSmtp | No | Attempt an SMTP deliverability probe |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds concrete details: syntax check, MX, SMTP, disposable domain checks, and a risk score. No contradictions.
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 two sentences, efficient and front-loaded with the core purpose, then a cost note. No unnecessary words.
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 output schema exists, the description covers the tool's purpose, specific checks, cost, and parameter nuances (especially _payment). It is fully adequate for an agent to select and invoke correctly.
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 coverage is 100%, so baseline is 3. The description adds value beyond schema, especially for the _payment parameter, explaining how to obtain and use it (Base64-encoded signed payload, reference to libraries).
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 validates and verifies an email address, listing specific checks (syntax, MX, SMTP, disposable domains) and a risk score. It is distinct from sibling tools like dns.lookup or prospect.enrich.
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 a clear use case and cost ($0.03 USDC) but does not explicitly state when not to use or suggest alternatives. The context is sufficient for an informed decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image.ocrExtract Text (OCR)AExtract text from an image using OCR. Costs $0.05 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public image URL to OCR (provide url OR image) | |
| image | No | Base64-encoded image data (provide url OR image) | |
| format | No | Output format | text |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. | |
| language | No | OCR language (ISO 639-3, e.g. eng) | eng |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description adds important cost context ('Costs $0.05 USDC on Base') and hints at payment via _payment parameter, which annotations do not cover.
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?
Two sentences, zero waste. Front-loaded with purpose, then cost. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values not needed. But description lacks detail on how to choose between url and image parameters, and the payment flow is mentioned but not fully explained.
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 baseline is 3. Description adds no further meaning beyond what the schema already provides for parameters.
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?
Description clearly states 'Extract text from an image using OCR' — a specific verb and resource. Distinguishes from sibling tools like image.screenshot and document.parse.
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?
No guidance on when to use this tool vs alternatives. Siblings include document.parse and qr tools, but no comparison or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image.screenshotCapture Website ScreenshotACapture a screenshot of any website. Supports dark mode, full-page, and element selection. Costs $0.05 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to screenshot | |
| delay | No | Wait ms after page load before capture | |
| width | No | Viewport width in pixels | |
| format | No | Output image format | png |
| height | No | Viewport height in pixels | |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. | |
| darkMode | No | Emulate prefers-color-scheme: dark | |
| fullPage | No | Capture full scrollable page | |
| selector | No | CSS selector to capture specific element |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| encoding | No | Encoding of the binary payload (base64). |
| mimeType | No | MIME type of the returned binary payload (e.g. image/png, application/pdf). |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds critical behavioral details: cost ($0.05 USDC on Base), the _payment parameter flow (sign locally, retry without _payment first), and supported modes. No contradiction with annotations.
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 two sentences and a cost note, highly concise. It front-loads the purpose and uses minimal words to convey all essential information without redundancy.
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 has 9 parameters, an output schema, and a payment mechanism, the description covers the main behavior, features, and payment flow. It does not explain return values, but the output schema exists. Minor missing guidance on format selection, but overall complete.
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 baseline is 3. The description adds value beyond schema by explaining the _payment parameter in detail (signing process, retry mechanism) and mentioning features that map to parameters (darkMode, fullPage, selector).
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 'Capture a screenshot of any website' with specific verb and resource, and lists supported features (dark mode, full-page, element selection) that distinguish it from sibling tools like image.ocr or qr.generate.
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 capturing website screenshots with optional features, but does not explicitly state when to use this tool versus alternatives. However, sibling tools are very different, so the lack of explicit when-not is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prospect.enrichEnrich ProspectATurn a name + company domain into a sales-ready prospect profile: seniority, buyer persona, decision-maker probability, company intel, email pattern, and a personalised cold-email opener. Use for AI SDRs, lead enrichment, and outbound personalisation. Costs $0.50 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name of the prospect | |
| domain | Yes | Company domain, e.g. stripe.com | |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. | |
| company_name | No | Company name if known (optional) | |
| linkedin_url | No | Known LinkedIn profile URL (optional hint) |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true (safe read operation) and openWorldHint=true (results depend on external data). The description adds important behavioral context: the cost ($0.50 USDC) and the payment flow with _payment parameter. No contradictions with annotations; description adds value beyond them.
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?
Two sentences: first packs the core functionality with output examples, second adds use cases and cost. No fluff, front-loaded key info. Every sentence serves a clear purpose.
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 5 parameters (2 required), full schema coverage, annotations, and output schema presence, the description is complete: it covers purpose, inputs, payment details, and use cases. Could mention the output schema's richness, but not necessary.
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 coverage is 100% (all 5 parameters described). The description adds meaning to the _payment parameter by explaining the signing process and the two-step retry, and clarifies that company_name and linkedin_url are optional hints. This goes beyond the schema descriptions.
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 primary function: 'Turn a name + company domain into a sales-ready prospect profile' and lists specific outputs like seniority, buyer persona, email pattern. This distinguishes it from sibling tools which are unrelated (e.g., community.wordstats, dns.lookup). Verb 'enrich' aligns with action on a prospect.
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 specifies use cases: 'Use for AI SDRs, lead enrichment, and outbound personalisation.' It also mentions the cost and implies a two-step process (first call without _payment, then retry). However, it does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qr.generateGenerate QR CodeAGenerate a QR code from text or URL. Returns PNG image as base64. Costs $0.01 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Image width/height in pixels | |
| text | Yes | Content to encode in QR code | |
| format | No | Output format | base64 |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| encoding | No | Encoding of the binary payload (base64). |
| mimeType | No | MIME type of the returned binary payload (e.g. image/png, application/pdf). |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost ($0.01 USDC on Base) and return format (PNG as base64), adding value beyond annotations. No contradiction with readOnlyHint.
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?
Extremely concise, one sentence plus cost note. Front-loaded with key action and output.
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?
Covers purpose, cost, return type. Output schema exists to handle return details. Could mention error scenarios but not necessary for a simple tool.
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 coverage is 100% and the description does not add extra meaning to parameters beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it generates a QR code from text or URL, and distinguishes from sibling 'qr.generate_styled' (not explicitly but by omission of styling). Verb+resource is specific.
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?
Describes when to use (for text or URL) but no explicit alternatives or when-not-to-use. Implicitly covers common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qr.generate_styledGenerate Styled QR CodeAGenerate an artistic/styled QR code with custom shapes, colors, and gradients. Costs $0.05 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Image width/height in pixels | |
| text | Yes | Content to encode in QR code | |
| format | No | Output format | base64 |
| dotType | No | Shape of QR modules | rounded |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. | |
| dotColor | No | Hex color for dots (e.g. #6366f1) | |
| gradientTo | No | Gradient end color (hex) | |
| cornerColor | No | Hex color for finder pattern corners | |
| gradientFrom | No | Gradient start color (hex) | |
| backgroundColor | No | Hex background color | #ffffff |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| encoding | No | Encoding of the binary payload (base64). |
| mimeType | No | MIME type of the returned binary payload (e.g. image/png, application/pdf). |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context not covered by annotations: the operation costs $0.05 USDC on Base, implying a payment requirement. Annotations indicate safe read-only/idempotent behavior, which aligns with generating a QR code, and the description does not contradict them.
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 a single sentence that concisely conveys purpose and cost. It is front-loaded with the key action. However, it could be broken into multiple sentences for improved readability, though it remains efficient.
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 rich schema, output schema, and annotations, the description adequately covers the core functionality and cost. However, it does not explicitly explain the two-call payment flow (though the _payment parameter documentation does). The sibling tool context helps differentiate usage.
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, so the description adds minimal extra meaning. It broadly mentions custom shapes, colors, and gradients, which summarizes the parameter groups but does not detail individual parameters beyond what the schema provides.
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 'Generate an artistic/styled QR code' with specific customizations (shapes, colors, gradients). It effectively distinguishes from the sibling 'qr.generate' by emphasizing the 'styled' aspect.
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 styled QR codes and mentions cost, but does not explicitly state when to use this tool versus the basic 'qr.generate' sibling or when not to use it. The cost and payment hint provide some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
security.screenScreen for Prompt InjectionAScreen text for prompt injection and jailbreak attacks before passing it to an LLM. Detects 10 attack categories. Costs $0.03 USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to screen for prompt injection (max 50,000 chars) | |
| source | No | Origin of the text (user_input, email, form, etc.) | |
| _payment | No | Base64-encoded signed v2 PaymentPayload (the value you'd put in the PAYMENT-SIGNATURE HTTP header). Use @x402/evm or @x402/fetch to sign locally with your own wallet — your private key never leaves your machine. Get the requirements from a first call without _payment, then retry. | |
| redacted | No | Redact flagged snippets in the response | |
| sensitivity | No | Detection sensitivity | medium |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call failed. |
| result | No | Raw JSON payload returned by the x402 service on a successful, paid call. |
| network | No | Settlement network for the x402 payment (base). |
| service | No | Underlying x402tools service that handled the call. |
| price_usdc | No | Price charged for this call, in USDC on Base. |
| requirements | No | x402 payment requirements (scheme, network, amount, payTo, asset) when payment_required is true. |
| payment_required | No | True when the call needs an x402 payment before it will run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, idempotentHint true, etc. The description adds valuable behavioral context: it detects 10 attack categories and costs $0.03 USDC. This goes beyond the annotations by detailing the tool's specific function and pricing.
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 extremely concise: two sentences that cover purpose and key details (cost, attack categories). It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and an output schema, the description includes critical context (cost, detection count, use case). The output schema is expected to explain return values, so the description is complete enough for an AI agent to understand usage.
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 baseline is 3. The tool description does not add additional meaning to the parameters beyond what the schema provides. The parameters are adequately documented in the schema itself.
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 explicitly states the verb 'Screen' and the resource 'text for prompt injection and jailbreak attacks', clearly defining its purpose. It distinguishes itself from sibling tools which are all unrelated (e.g., dns.lookup, qr.generate), leaving no ambiguity.
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 phrase 'before passing it to an LLM' provides clear usage context. While it does not explicitly exclude alternatives, the sibling tools are sufficiently diverse that no confusion arises. A score of 4 reflects clear but not exhaustive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!