Search1API MCP Server

Ask across sources

ask

Read-only

Search multiple sources at once from a natural-language query when the right engine is unclear, returning ranked citable results plus inferred intent and failed engines.

Instructions

Search several sources at once from a natural-language request when the right engine is unclear. Search1API picks up to five engines (web, Hacker News, Reddit, GitHub, X, arXiv, Wikipedia, and more) and a time window from the wording, then returns up to 10 citable results ranked by relevance, plus the intent it used and any engines that failed. Costs 5 credits per call; use search when you already know the engine.

Input Schema

Name	Required	Description	Default
`query`	Yes	What the user is looking for, in their own words; naming a platform ("on Reddit", "papers") or a period ("this week") steers which engines and time window are used

Output Schema

Name	Required	Description
`errors`	Yes	Engines that failed while others completed
`intent`	Yes	Keywords, engines, and time window that were used
`results`	Yes	Up to 10 sources across the chosen engines, most relevant first

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.9.0Oct 29, 2026

changedInput schema / properties / query / description

Previous value: -"The request in natural language; platform hints (\"on Reddit\", \"papers\") and time hints (\"this week\") steer the search"New value: +"What the user is looking for, in their own words; naming a platform (\"on Reddit\", \"papers\") or a period (\"this week\") steers which engines and time window are used"

addedOutput schema / properties / intent / properties / search_query / description
```
Added value: +"Keywords sent to the engines"
```
addedOutput schema / properties / intent / properties / sources / description
```
Added value: +"Engines that were searched"
```

addedOutput schema / properties / intent / properties / time_range / description

Added value: +"Recency window inferred from the request, or null for any time"

addedOutput schema / properties / results / description

Added value: +"Up to 10 sources across the chosen engines, most relevant first"

Addedv0.8.0Oct 14, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that up to five engines and a time window are inferred from wording, up to 10 results are returned ranked by relevance, the response includes the inferred intent and any failed engines, and each call costs 5 credits. The failed-engines and cost disclosures are operationally important and appear nowhere in the structured fields.

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?

Three sentences, each carrying distinct payload: what it does, what it returns, and what it costs versus the alternative. The disambiguating condition is front-loaded in the first sentence and nothing is redundant.

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?

Despite an output schema existing, the description still usefully previews the result shape (results, intent, failed engines) and adds the credit cost, which no structured field carries. For a single-parameter, read-only tool this leaves no meaningful gap.

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?

With one parameter at 100% schema coverage, the schema already explains that naming a platform or period steers engine and window selection. The description corroborates this and adds that up to five engines are chosen automatically, though it introduces no new syntax or constraints (e.g., the 500-character limit stays in 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?

States a specific verb and resource ("Search several sources at once") with the distinguishing scope: natural-language federated search across up to five engines. It names the sibling tool `search` and the condition that separates them, so an agent can disambiguate without opening either schema.

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?

Explicit routing guidance in both directions: use this "when the right engine is unclear" and "use search when you already know the engine." It pairs that with a concrete cost tradeoff (5 credits per call), which is exactly the kind of information needed to choose between the two.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server