Objective-driven deep research for AI agents, paid per request via MPP (Tempo mainnet USDC.e) - no account or API key. Free daily-limited quick search across global news and arXiv papers. Paid deep research: send an objective, get an exact quote with a planned source list, pay the challenge, and poll a tracker for a cross-source report from a real cloud Chromium browser plus AI synthesis. Optional notify_email delivers the report by email. No CAPTCHA, login, or paywall bypass.
Free first-level search, limited per day across all callers: current news coverage (100+ languages, 250K+ sources) or scholarly papers (arXiv). Returns structured results immediately with no payment. When the daily quota is exhausted, or when you need live browsing and synthesis across sources, use a9n9_research_quote for paid deep research.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| domain | No | news (default): global news articles. papers: arXiv preprints. | |
| payer_address | No | Optional Tempo payer address so free usage counts toward loyalty pricing on paid research. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations: it discloses the daily quota limit, free usage, the returned result format ('structured results immediately'), and scope (100+ languages, 250K+ sources). Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false, so the description complements these with operational constraints.
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 with no wasted words. It front-loads the purpose, limits, and scope, then immediately provides an alternative tool. 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?
Given the low complexity (3 params, no nested objects, no output schema), the description covers the core behavior, limits, and boundaries well. It does not describe the return structure in detail, but since no output schema exists, a brief note on immediate structured results is sufficient. The additional context on languages and sources adds confidence for the 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 coverage is 67%, and the description does not explicitly detail parameters beyond saying 'first-level search' and mentioning domains. However, the domain parameter's enum values (news, papers) are documented in the schema's description, and the query parameter's purpose is clear from the context. The description could add more syntax details for payer_address, but overall it adds context about the free tier, reducing the need for exhaustive param docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'free first-level search' across two distinct domains (news and scholarly papers), using specific verbs like 'search' and 'returns.' It distinguishes from siblings by naming a9n9_research_quote as the alternative for paid deep research.
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 explicitly tells when to use this tool (current news or arXiv papers) and when not to, by naming a9n9_research_quote for paid deep research when quota is exhausted or live browsing is needed. This provides clear context and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a deep-research objective and return the exact current price, limits, planned start URLs, request hash, expiry, payment requirements, and cloud-browser capabilities without charging or starting a job. targetUrl is optional: omit it and the quote derives and binds a bounded plan of public start URLs from the objective.
| Name | Required | Description | Default |
|---|---|---|---|
| job_key | Yes | job_key identifies a research session. Reuse it with a new objective to run a follow-up iteration that references the session's prior results (each iteration is a separate paid job); an identical request retries idempotently. Sessions are referenceable for 7 days, then results are cleared. | |
| objective | Yes | ||
| targetUrl | No | Optional public HTTPS focus hint; when omitted the service plans up to 5 public start URLs from the objective and binds them into the quote. | |
| payer_address | No | Optional Tempo payer address for loyalty pricing: 10% off after $2.00 of reconciliation-confirmed on-chain spend from that address. Settlement must then come from it. |
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| price | Yes | |
| limits | Yes | |
| chainId | Yes | |
| network | Yes | |
| payment | Yes | |
| quoteId | Yes | |
| currency | Yes | |
| nextStep | Yes | |
| expiresAt | Yes | |
| rationale | No | |
| cloudBrowser | Yes | |
| walletPayment | Yes | |
| requestBodyHash | Yes | |
| paymentChallenge | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral nuance: it binds a bounded plan of start URLs when targetUrl is omitted, and clarifies that the quote does not trigger payment or job start. This complements the annotations without contradicting 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 two sentences, front-loaded with the core purpose and immediately followed by the key optionality. Every sentence carries critical information with no filler.
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 fairly complex quote tool with an output schema (present but not shown), the description covers the essential behavior, optional parameters, and outcomes without redundancy. It does not need to describe return values since the output schema exists, and the description is sufficiently complete in 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 covers 75% of parameters with descriptions. The tool description adds meaning beyond the schema: it explains the optionality of targetUrl and its effect (planning up to 5 start URLs) and hints at job_key reuse for follow-ups. Since schema coverage is high, the baseline is 3, but the description's added nuance earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze a deep-research objective and return the exact current price, limits, planned start URLs, request hash, expiry, payment requirements, and cloud-browser capabilities without charging or starting a job.' This distinguishes it from siblings like a9n9_research_start (which starts a job) and a9n9_quick_search (a different search 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?
The description implies when to use this tool: before starting a job, as it explicitly says 'without charging or starting a job.' It also explains the optional targetUrl behavior, giving context on how to influence planning. However, it does not explicitly name alternatives or state 'do not use when...' which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start bounded paid research in a real remotely hosted Browserbase Chromium session with JavaScript rendering, DOM interaction, scrolling, and dynamic-content extraction, followed by gpt-5.6-luna synthesis. targetUrl is optional; without it the quoted plan of public start URLs derived from the objective is executed. Call a9n9_research_quote first when price visibility is needed. The service does not bypass CAPTCHAs, logins, paywalls, access controls, or site terms.
| Name | Required | Description | Default |
|---|---|---|---|
| job_key | Yes | job_key identifies a research session. Reuse it with a new objective to run a follow-up iteration that references the session's prior results (each iteration is a separate paid job); an identical request retries idempotently. Sessions are referenceable for 7 days, then results are cleared. | |
| objective | Yes | ||
| targetUrl | No | Optional public HTTPS focus hint; when omitted the service plans up to 5 public start URLs from the objective and binds them into the quote. | |
| notify_email | No | Optional: email the completed report to this address from a9n9@agentmail.to. Delivery preference only; not part of the payment-bound request hash. | |
| payer_address | No | Optional Tempo payer address for loyalty pricing: 10% off after $2.00 of reconciliation-confirmed on-chain spend from that address. Settlement must then come from it. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| result | No | |
| status | Yes | |
| quoteId | No | |
| createdAt | No | |
| statusUrl | No | |
| trackerCode | Yes | |
| progressStage | Yes | |
| progressPercent | Yes | |
| requestBodyHash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it is 'paid' and 'bounded', uses a 'real remotely hosted Browserbase session', and explicitly states limitations: 'The service does not bypass CAPTCHAs, logins, paywalls, access controls, or site terms.' It also mentions session persistence ('Sessions are referenceable for 7 days') and idempotency ('identical request retries idempotently' in the schema). These details go beyond annotations and provide full transparency.
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 focused paragraph that packs essential details—purpose, limitations, usage hint, and parameter nuance—without redundant elaboration. It is appropriately sized for a complex tool, balancing completeness with brevity.
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 description covers limitations, usage, and session behavior, but does not describe the tool's return value (what the client receives after starting research). Given that an output schema exists (has_output_schema: true), this gap is acceptable, but it slightly reduces completeness for a self-contained understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already includes descriptions for each parameter, and the tool description adds extra meaning for targetUrl: 'without it the quoted plan of public start URLs derived from the objective is executed.' It also clarifies job_key's role in reuse and idempotency. However, the description does not independently explain 'objective' or 'payer_address' beyond what the schema provides, so it only partially adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Start bounded paid research...' and distinguishes it from sibling tools like quick_search, research_quote, and status. The verb 'Start' and specific resource 'paid deep research' make the purpose unambiguous.
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 direct usage hint: 'Call a9n9_research_quote first when price visibility is needed.' It also implies the tool is for initiating research after planning, and mentions the optional targetUrl. However, it doesn't explicitly state when to use this tool over others for all scenarios, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return milestone progress and the final result for an opaque tracker code.
| Name | Required | Description | Default |
|---|---|---|---|
| trackerCode | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | |
| result | No | |
| status | Yes | |
| quoteId | No | |
| createdAt | No | |
| statusUrl | No | |
| trackerCode | Yes | |
| progressStage | Yes | |
| progressPercent | Yes | |
| requestBodyHash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as false. The description adds that the tool returns 'milestone progress and the final result', which is consistent but does not reveal additional behavioral traits such as error handling, authentication requirements, or rate limits. It offers marginal value beyond the 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 a single sentence of 12 words, front-loaded with the key action and result. Every word is necessary; there is no redundancy or filler. It is optimally concise for the information it conveys.
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 read-only tool with one parameter and an output schema, the description is minimally adequate. It states what is returned but omits context like expected behavior for invalid tracker codes, or the relationship between milestones and final result. The output schema presumably covers the return structure, but the description could still provide more helpful hints.
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 0%, so the description must compensate. It refers to 'trackerCode' as an 'opaque tracker code' but does not explain where to obtain it, how to interpret the pattern, or what happens if the code is invalid. This adds minimal semantic value; the agent learns little more than the schema already 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 specifies a clear verb ('Return') and resource ('milestone progress and the final result') for an 'opaque tracker code'. It distinguishes this tool from siblings like a9n9_research_start or a9n9_research_submit_payment by focusing on retrieval of status, not creation or payment.
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 does not mention prerequisites (e.g., 'Use after starting a research'), nor does it exclude cases (e.g., 'Not for general search'). The agent must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a separately broadcast Tempo mainnet push-mode payment and continue the quoted research job. Use the paymentChallenge and walletPayment returned by a9n9_research_quote, then provide the transaction hash, payer address, and same job_key.
| Name | Required | Description | Default |
|---|---|---|---|
| job_key | Yes | ||
| notify_email | No | Optional: email the completed report to this address from a9n9@agentmail.to. | |
| payer_address | Yes | ||
| transaction_hash | Yes | ||
| payment_challenge | Yes | Unmodified paymentChallenge returned by a9n9_research_quote. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| result | No | |
| status | Yes | |
| quoteId | No | |
| createdAt | No | |
| statusUrl | No | |
| trackerCode | Yes | |
| progressStage | Yes | |
| progressPercent | Yes | |
| requestBodyHash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: the payment must be 'separately broadcast' before calling this tool, and it 'continues the quoted research job.' It also specifies the network (Tempo mainnet) and mode (push-mode). This goes beyond the annotations, though it does not detail failure modes or the exact verification process.
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, front-loading the purpose and then specifying the inputs. It is efficient, but the mention of 'walletPayment' (which is not a parameter) adds an unnecessary confusing element. Otherwise, it is concise and to the point.
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 5 parameters (including a nested object), an output schema, and a complex flow (payment verification and job continuation), the description provides a reasonable overview but is not fully complete. It does not explain what happens if verification fails, how the output looks, or the exact role of 'walletPayment' (not in schema). The missing clarity on 'walletPayment' and the lack of detail on error states make it slightly incomplete.
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 40%, with only notify_email and payment_challenge having descriptions. The tool description adds meaning for job_key, transaction_hash, and payer_address by stating they come from the quote and transaction. It also clarifies that payment_challenge must be the 'unmodified' value from the quote. However, the description mentions 'walletPayment' which is not a parameter in the schema, causing slight confusion. Overall, it 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's purpose: 'Verify a separately broadcast Tempo mainnet push-mode payment and continue the quoted research job.' It specifies the verb (verify and continue), the resource (payment and research job), and distinguishes this tool from siblings like a9n9_research_quote (which provides the inputs) and a9n9_research_start (which initiates a job). The mention of 'push-mode payment' and 'Tempo mainnet' adds specificity.
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 explicit prerequisites: 'Use the paymentChallenge and walletPayment returned by a9n9_research_quote, then provide the transaction hash, payer address, and same job_key.' This tells the user exactly when to use this tool (after receiving a quote) and what inputs are needed. It does not include explicit 'when not to use' exclusions, but the context is clear enough that it should only be used after a quote and after broadcasting the payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
a9n9_research_quote1 field changedInput schema / properties / job_key / descriptionPrevious value: -"Caller-generated unique key for one intended job; reuse only for retries."New value: +"job_key identifies a research session. Reuse it with a new objective to run a follow-up iteration that references the session's prior results (each iteration is a separate paid job); an identical request retries idempotently. Sessions are referenceable for 7 days, then results are cleared."a9n9_research_start1 field changedInput schema / properties / job_key / descriptionPrevious value: -"Caller-generated unique key for one intended job; reuse only for retries."New value: +"job_key identifies a research session. Reuse it with a new objective to run a follow-up iteration that references the session's prior results (each iteration is a separate paid job); an identical request retries idempotently. Sessions are referenceable for 7 days, then results are cleared."a9n9_research_quote1 field changedInput schema / properties / payer_addressAdded value: +{
+ "description": "Optional Tempo payer address for loyalty pricing: 10% off after $2.00 of reconciliation-confirmed on-chain spend from that address. Settlement must then come from it.",
+ "pattern": "^0x[a-fA-F0-9]{40}$",
+ "type": "string"
+}a9n9_research_start1 field changedInput schema / properties / payer_addressAdded value: +{
+ "description": "Optional Tempo payer address for loyalty pricing: 10% off after $2.00 of reconciliation-confirmed on-chain spend from that address. Settlement must then come from it.",
+ "pattern": "^0x[a-fA-F0-9]{40}$",
+ "type": "string"
+}a9n9_quick_searcha9n9_research_quotea9n9_research_starta9n9_research_statusa9n9_research_submit_paymentClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Add one secure layer between your agents and this server.
Each tool has a distinct role: quick_search is the free tier, while research_quote, research_start, research_status, and research_submit_payment form a clear paid workflow. No two tools could be plausibly confused.
All tools share the a9n9_ prefix and snake_case convention. Minor inconsistency exists because quick_search breaks the research_* pattern used by the other four tools, but the verb/noun usage is otherwise predictable.
Five tools is well-scoped for a research service: one free entry point and four lifecycle steps (quote, start, payment, status). Each tool serves a necessary and non-redundant function.
The core deep-research workflow is fully covered: free quick search, quote, paid start, payment submission, and status/result retrieval. Minor gaps like cancellation or job listing are absent but not essential to the primary purpose.