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.
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.2/5 across 5 of 5 tools scored. Lowest: 3.4/5.
Each tool has a clearly distinct purpose: free quick search, price quote, start paid research, check status, and submit payment. There is no overlap or ambiguity; an agent can easily select the correct tool for each step.
All tools follow a consistent pattern: the prefix 'a9n9_' followed by a snake_case verb_noun combination (quick_search, research_quote, research_start, research_status, research_submit_payment). The naming is uniform and predictable.
Five tools is well-suited for a deep research service. The set covers the full workflow (free search, quote, start, payment, status) without being too sparse or overly numerous.
The tool surface provides a complete lifecycle for the research service: a free introduction, a paid quote, job initiation, payment processing, and result retrieval. No obvious gaps are present for the advertised functionality.
a9n9_quick_searchFree Quick SearchAFree 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.
a9n9_research_quoteQuote Deep ResearchAAnalyze 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 | Caller-generated unique key for one intended job; reuse only for retries. | |
| 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. |
| 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, destructiveHint=false, and idempotentHint=true. The description adds value by clarifying that the tool does not charge or start a job, and that omitting targetUrl triggers automatic URL derivation and binding. This complements the annotations well, but there is no contradiction.
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, front-loaded with the main purpose, followed by a key detail on targetUrl behavior. Every word earns its place; no fluff or 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 an output schema exists (likely describing the returned fields), the description covers what the tool does, its no-cost nature, and parameter variability (targetUrl optional). It could optionally mention how to interpret the quote for payment submission, but the output schema likely fills that gap. Still, for a 3-param tool with good schema coverage, this is robust.
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?
With 67% schema coverage (job_key description exists, targetUrl description exists, objective has length constraints but no description), the description adds meaning beyond the schema: it explains that objective drives derived URLs and that targetUrl is a focus hint with a bounded plan scope. It compensates for the missing parameter description on objective and provides richer context.
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 precisely states the tool analyzes a deep-research objective and returns specific price, limits, start URLs, request hash, expiry, payment requirements, and cloud-browser capabilities without charging or starting a job. It clearly distinguishes from siblings like a9n9_research_start (which presumably starts the job) by emphasizing it is a no-charge, preview-only operation.
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 explains when to call this tool (before starting a research job) and hints at the optional nature of targetUrl, but does not explicitly state when NOT to use it or mention alternatives like skipping straight to start. It provides clear context for a planning step, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
a9n9_research_startStart Paid Deep ResearchAStart 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 | Caller-generated unique key for one intended job; reuse only for retries. | |
| 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. |
| 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 indicate idempotentHint=true and destructiveHint=false, so the description does not repeat those. However, the description goes beyond by disclosing key behaviors: the service does not bypass CAPTCHAs, logins, paywalls, access controls, or site terms. This adds significant behavioral context that annotations do not cover. The description also mentions job_key reuse for retries, which aligns with idempotency.
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 concise at four sentences, front-loading the core functionality in the first sentence. Every sentence adds distinct value: the first defines the tool, the second clarifies a parameter, the third provides usage guidance, and the fourth discloses important limitations. No redundancy or 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?
Given the presence of an output schema (handling return value explanation), high schema coverage, and clear annotations, the description provides all necessary additional context: it explains the bounded research process, the optional nature of targetUrl, the prerequisite to call a9n9_research_quote, and the service's limitations. The tool is moderately complex with 4 params, but the description covers its role fully without over-explaining.
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 high at 75%, so baseline is around 3. The description adds value by explaining that targetUrl is optional and that without it the service plans URLs from the objective, and it clarifies notify_email is a delivery preference not part of the payment-bound hash. This meaningfully supplements the schema's terse descriptions for these 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 the tool starts bounded paid research in a remote Browserbase Chromium session with JavaScript rendering and other capabilities, followed by gpt-5.6-luna synthesis. It specifies that targetUrl is optional and explains what happens without it, distinguishing the tool from siblings like a9n9_quick_search or a9n9_research_quote by describing a multi-step process not present in those 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?
The description explicitly advises to call a9n9_research_quote first when price visibility is needed, providing clear guidance on when to use a sibling instead. It does not state when not to use this tool (e.g., for simple queries better suited to a9n9_quick_search), but the context signals include sibling names that imply differentiation, and the exclusion is partially covered by the sibling's existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
a9n9_research_statusGet Research StatusBReturn 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.
a9n9_research_submit_paymentSubmit External Wallet PaymentAVerify 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.
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!
