Paid MCP web research for agents: search, extraction, citations, and x402 payment discovery.
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 2.8/5 across 5 of 5 tools scored.
Most tools have distinct purposes (audit, extraction, diff monitor, search, combined pack). The research_pack overlaps with search and extract_page but is explicitly a combined tool, so some confusion is possible but descriptions help.
All tool names follow a consistent snake_case pattern (codex_audit, extract_page, monitor_diff, research_pack, search). No mixing of styles.
With 5 tools, the set is well-scoped for a research pack. Each tool serves a distinct function without unnecessary bloat.
Covers key research actions: search, extraction, diff monitoring, and a Codex audit. A potential minor gap is lack of a tool for managing or storing research results, but core workflows are present.
codex_auditCInspectPaid x402 Codex audit entrypoint. Use the REST /codex/jobs endpoint to queue execution.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Code, configuration, or architecture review prompt for the paid Codex audit. | |
| payment | Yes | x402 payment proof payload containing resource, amount, wallet, and settlement metadata. | |
| facilitator_id | No | Settlement facilitator id. Use evm-base for Base USDC payments. | evm-base |
| payment_identifier | No | Optional idempotency key. Reuse it on retries to return the cached paid result. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is minimal. It does not disclose whether the tool is a read or write operation, side effects, authentication needs, or rate limits. The phrase 'paid' hints at payment but lacks specifics.
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 very short but under-specified. It sacrifices clarity for brevity, and the mention of a REST endpoint feels out of 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 an output schema and full parameter coverage, the description lacks essential context about the tool's workflow, payment handling, and idempotency. It is incomplete for an agent to confidently invoke.
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 covers 100% of parameters with descriptions, so the description adds no extra semantic value. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'paid x402 Codex audit entrypoint' but does not clearly state what action the tool performs. The reference to a REST endpoint is ambiguous and fails to differentiate this tool from siblings.
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 explicit guidance on when to use or avoid this tool. The description mentions using a REST endpoint but provides no context compared to alternatives like extract_page or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_pageCInspectPaid x402 page extraction for one to twenty URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | HTTP URLs to extract. Limited to 20 pages per request. | |
| payment | Yes | x402 payment proof payload containing resource, amount, wallet, and settlement metadata. | |
| facilitator_id | No | Settlement facilitator id. Use evm-base for Base USDC payments. | evm-base |
| payment_identifier | No | Optional idempotency key. Reuse it on retries to return the cached paid result. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the operation is paid and limited to 20 URLs, but does not explain payment mechanics, failure modes, or authorization requirements. This is insufficient for a paid tool.
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 with a single sentence. It front-loads key information (paid, x402, range). However, it could be slightly more informative without being verbose, e.g., mentioning the payment requirement leads to a score of 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a paid extraction tool with an output schema and nested objects, the description is too sparse. It lacks details about the x402 protocol, payment flow, and appropriate use cases relative to sibling tools. The output schema exists but the description should still provide high-level 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 description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides (e.g., URL count is already in minItems/maxItems). No extra context on payment or facilitator_id semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs paid x402 page extraction for 1-20 URLs. It specifies the verb 'extraction' and resource 'page'. However, it does not explicitly differentiate from sibling tools like search or research_pack, though the 'paid' hint sets it apart.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or typical scenarios. The description only states what it does, not when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
monitor_diffCInspectPaid x402 page diff monitor.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTP URL to fetch and compare for the diff monitor. | |
| payment | Yes | x402 payment proof payload containing resource, amount, wallet, and settlement metadata. | |
| previous_hash | No | Optional previous content hash to compare against the current page. | |
| previous_text | No | Optional previous page text to compare against the current page. | |
| facilitator_id | No | Settlement facilitator id. Use evm-base for Base USDC payments. | evm-base |
| payment_identifier | No | Optional idempotency key. Reuse it on retries to return the cached paid result. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'Paid x402' but does not disclose key behavioral traits such as required permissions, data handling, or side effects beyond the payment aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise but lacks sufficient detail. It is front-loaded but at the cost of completeness.
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 6 parameters and an output schema, the description provides minimal context. It fails to explain core functionality, return behavior, or how the payment integrates with the diff monitoring.
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?
Input schema covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline expectation.
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 'Paid x402 page diff monitor' vaguely indicates it monitors page differences, but lacks a specific verb and clear resource object. It does not differentiate from siblings like extract_page or research_pack.
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 versus alternatives (codex_audit, extract_page, etc.). No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
research_packBInspectPaid x402 research pack: search plus extraction and citations.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to run through the paid research API. | |
| payment | Yes | x402 payment proof payload containing resource, amount, wallet, and settlement metadata. | |
| max_results | No | Maximum number of ranked search results to return. | |
| extract_pages | No | Number of top search results to extract for the research pack. | |
| facilitator_id | No | Settlement facilitator id. Use evm-base for Base USDC payments. | evm-base |
| payment_identifier | No | Optional idempotency key. Reuse it on retries to return the cached paid result. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'paid x402' but does not disclose how payment is processed, what happens on failure, or any other behavioral traits (e.g., idempotency via payment_identifier is only in the schema).
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 very concise (one sentence) but lacks structure or front-loading. It could be expanded to better serve the agent without being verbose.
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 an output schema and 100% parameter coverage, the description still lacks completeness. It does not explain the payment process or when to use this tool over free alternatives, leaving gaps for an AI agent.
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 minimal value beyond the schema; it just says 'search plus extraction and citations' which is already implied by 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?
The description clearly states it's a paid research pack that includes search, extraction, and citations. It distinguishes from siblings like 'search' (only search) and 'extract_page' (only extraction).
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 it is a paid tool but does not explicitly state when to use it versus alternatives (e.g., the free search tool). There is no guidance on when not to use it or mention of prerequisites like having a wallet for payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchCInspectPaid x402 web search for autonomous agents.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to run through the paid research API. | |
| payment | Yes | x402 payment proof payload containing resource, amount, wallet, and settlement metadata. | |
| max_results | No | Maximum number of ranked search results to return. | |
| facilitator_id | No | Settlement facilitator id. Use evm-base for Base USDC payments. | evm-base |
| payment_identifier | No | Optional idempotency key. Reuse it on retries to return the cached paid result. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the payment requirement (x402) but omits other important traits such as caching behavior (only hinted by the idempotency key in schema), rate limits, or failure handling. The description is too brief to be transparent.
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 (one sentence) and front-loaded with the key paid aspect. However, it is under-specified for a tool with 5 parameters and an output schema; a slightly longer description with critical details would be more helpful.
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 (5 params, payment payload, output schema) and lack of annotations, the description is insufficient. It does not cover the meaning of the output, how to construct the payment object, or practical usage context, leaving the agent with gaps.
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 clear descriptions for all parameters, so the baseline is 3. The description adds no additional parameter context beyond what the schema provides, meaning it does not enhance understanding but also does not detract.
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 states it's a paid web search for autonomous agents, clearly indicating the tool's function and its paid nature. It distinguishes from siblings like research_pack and extract_page, which serve different purposes, but lacks detail on the specific resource or result type.
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 is provided on when to use this tool versus alternatives. The description implies it's for paid searches but does not specify scenarios or exclusions, leaving the agent without decision rules.
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!
Sign in to create a connector for this server.