a9n9 Deep Research

Server Details

Objective-driven deep research: free daily quick search plus MPP-paid cross-source browser reports.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 41 days
Last Tested: 2026-09-27 12:34
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-09-09 18:26 across 5 tools

Disambiguation5/5

Each tool maps to a distinct stage of the research workflow: free quick search, pricing/planning, starting paid research, checking status, and submitting payment. There is no meaningful overlap between them, and cross-references between tools reduce ambiguity further.

Naming Consistency4/5

The a9n9_ prefix is consistent, and four of five tools follow the a9n9_research_<action> pattern. a9n9_quick_search is the only deviation, but it still reads naturally and fits the search functionality.

Tool Count5/5

Five tools cover the full paid research lifecycle plus a free tier entry point. The surface is compact and every tool has a clear role, with no redundant or filler tools.

Completeness5/5

The set covers quote creation, payment submission, starting research, and retrieving status/results, which is the complete core workflow advertised. Quick search provides a free fallback, and no obvious dead ends or missing lifecycle steps are apparent.

Available Tools

5 tools

a9n9_quick_searchFree Quick SearchA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 ResearchA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`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.

Output Schema

ParametersJSON Schema

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

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond annotations: no charge is incurred, no job is started, and omitting targetUrl causes the service to derive and bind a bounded plan of public start URLs from the objective.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with front-loaded purpose and no filler. Each clause contributes either output details, side-effect guarantees, or targetUrl behavior, making the description efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema, annotations, output schema, and sibling tool names, the description is complete: it enumerates the quote's returned fields, clarifies the optional targetUrl behavior, and leaves no major ambiguity about the tool's role.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75% and the schema already details job_key, targetUrl, and payer_address. The description adds value by explaining that targetUrl is optional and that omitting it triggers plan derivation/binding, which enriches the schema's format-only definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Analyze a deep-research objective and return...') and lists concrete outputs: price, limits, planned start URLs, request hash, expiry, payment requirements, cloud-browser capabilities. It also distinguishes itself from siblings with 'without charging or starting a job.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly establishes the quoting/planning use case and explains what happens when targetUrl is omitted. It does not explicitly name sibling alternatives or state when not to use it, but the 'without charging or starting a job' phrasing implies pre-flight use before research_start.

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 ResearchA

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`result`	No
`status`	Yes
`quoteId`	No
`createdAt`	No
`statusUrl`	No
`trackerCode`	Yes
`progressStage`	Yes
`progressPercent`	Yes
`requestBodyHash`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds behavioral context beyond annotations by specifying 'bounded paid research' and stating it does not bypass CAPTCHAs, logins, paywalls, access controls, or site terms. No contradiction with annotations; idempotency and open-world hints align with description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences) and front-loaded with the core purpose, followed by key behavioral notes. Every word contributes, with no unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the tool's purpose, key parameters, prerequisite (quote), and limitations, while relying on the output schema for return details. Sufficient for a complex paid research tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description clarifies targetUrl's optional behavior and gives context to the objective parameter, which lacks a schema description. Adds meaning beyond the schema's per-parameter notes, compensating for the 80% coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (start bounded paid research), the environment (real Browserbase Chromium session), and the process (interaction, extraction, synthesis). It distinguishes itself from siblings by naming quote as a prerequisite and implying a deeper scope than quick_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call a9n9_research_quote first for price visibility and explains the optional targetUrl behavior. Does not explicitly compare to all siblings, but the 'deep research' label and quote guidance provide sufficient context.

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 StatusB

Read-onlyIdempotent

Inspect

Return milestone progress and the final result for an opaque tracker code.

ParametersJSON Schema

Name	Required	Description	Default
`trackerCode`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`result`	No
`status`	Yes
`quoteId`	No
`createdAt`	No
`statusUrl`	No
`trackerCode`	Yes
`progressStage`	Yes
`progressPercent`	Yes
`requestBodyHash`	No

TDQS

B3.4/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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 PaymentA

Idempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description
`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.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`result`	No
`status`	Yes
`quoteId`	No
`createdAt`	No
`statusUrl`	No
`trackerCode`	Yes
`progressStage`	Yes
`progressPercent`	Yes
`requestBodyHash`	No

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesAug 19, 2026

Changeda9n9_research_quote1 field changed

changedInput schema / properties / job_key / description

Previous 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."

Changeda9n9_research_start1 field changed

changedInput schema / properties / job_key / description

Previous 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."

2 tool updatesAug 18, 2026

Changeda9n9_research_quote1 field changed

addedInput schema / properties / payer_address

Added 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"
+}

Changeda9n9_research_start1 field changed

addedInput schema / properties / payer_address

Added 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"
+}

1 tool updateAug 17, 2026

Changeda9n9_quick_search1 field changed

addedInput schema / properties / payer_address

Added value: +{
+  "description": "Optional Tempo payer address so free usage counts toward loyalty pricing on paid research.",
+  "pattern": "^0x[a-fA-F0-9]{40}$",
+  "type": "string"
+}

5 tool updatesAug 17, 2026
- First observeda9n9_quick_search
- First observeda9n9_research_quote
- First observeda9n9_research_start
- First observeda9n9_research_status
- First observeda9n9_research_submit_payment

Related MCP Connectors

MultiScrape Contextual Web Research
io.github.Arsh-Kashyap
Live web research with related queries, browser-rendered sources, images, and evidence.
Browser Automation Web Scraping Search
1
Concordance
io.github.Vohlsyr
Cross-source search across 18 real-time data sources, source-cited and corroboration-checked.
Search Research & Data Data Platforms
1
WebhoundOAuth
ai.webhound
Budgeted reports and datasets with Hound, Webhound's DeepSeek V4 Pro + GPT-5.4 research harness.
Web Scraping Search Research & Data
2
Tru8 Evidence Research A
io.github.SamYatesSmith
Source-traced evidence research for AI agents. We organise the evidence; you decide.
Research & Data Search RAG Systems
31

Related MCP Servers

GPT Researcher MCP Server
RAG Systems Search Research & Data
deepresearch329-debug
A
license
Not graded
quality
C
maintenance
Enables deep web research and report generation through an MCP interface, providing tools for comprehensive research, quick search, and source management.
Updated 3 months ago (2026-07-08 07:24 UTC)
MIT
Infobroker
Knowledge & Memory Research & Data Search
flukeatzerocool
A
license
A
quality
B
maintenance
An MCP-native research assistant — search backend, intent-routing, and writing pipeline that carries a question through search, verification, and writing, delivering whatever research you need: quick answers, verified sources, or a finished document.
Updated 12 days ago (2026-09-15 00:53 UTC)
2
7
94 npm
MIT
MCPSearch
Search Web Scraping Research & Data
JonusNattapong
A
license
Not graded
quality
C
maintenance
AI-powered multi-source research and crawling platform with MCP integration, enabling web search, crawling, social source aggregation, and structured research workflows.
Updated 6 months ago (2026-03-26 08:04 UTC)
1
MIT
Deep Research MCP Server
RAG Systems Web Scraping Search
teelaitila
A
license
Not graded
quality
D
maintenance
Enables iterative deep research by integrating AI agents with search engines, web scraping, and large language models for efficient data gathering and comprehensive reporting.
Updated 8 months ago (2026-01-28 10:48 UTC)
2 npm
324
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?