SpecStream

Search the web

search_web

Fast search: answers a question from the live web in seconds. Suited to one fact, or to the first rows of a list before the full table is priced. Returns kind (fact or list), the answer with the page it was read from, rows with each result's name and the facts the request asks for, each value with its page, the search results read (sources), took_ms and request_id. num (1 to 100) sets how many sources come back and page (1 to 10) continues the same list; next_page names the next page. For a list, handoff names the estimated rows and the next steps, a compiled request and a quote for the full table. A call of up to 10 results takes $0.005 from the account's balance; each started block of 10 more results adds $0.006. It needs no quote or approval. A full list is run from a compiled request and its quote, not from this search.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "q": "<q>"
    },
    "name": "search_web"
  }
}

Input Schema

Name	Required	Description
`q`	Yes	The question or the request in everyday words, in any language
`num`	No	The number of results (sources) to return, 1 to 100. Without num or page, the reply holds every result the answer read. When the first search finds fewer, SpecStream searches deeper (more engines and their next result pages) before it answers. A call of up to 10 results is $0.005; each started block of 10 more results adds $0.006 (num=100 is $0.059).
`page`	No	The page of results to return, 1 to 10, num results each (10 without num). Page 2 continues the same list as page 1. The answer and the rows are on page 1 only. next_page in the reply names the next page, or is null when the engines found no more.
`speed`	No	fast gives the search results in about a second: the first engines' results with their snippets, each with the time it was read (read_at), with no answer, rows or passages; num and page past the first 10 results come from the engines' own later pages. default also reads the results for the answer and its rows.
`passages`	No	Also return the text of the top pages closest to the request, each with its page, so a caller sees the evidence without reading a page

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / speed / description

Previous value: -"fast gives the search results in about a second: the first engines' results with their snippets, each with the time it was read (read_at), with no answer, rows or passages, at most 10 results. default also reads the results for the answer and its rows."New value: +"fast gives the search results in about a second: the first engines' results with their snippets, each with the time it was read (read_at), with no answer, rows or passages; num and page past the first 10 results come from the engines' own later pages. default also reads the results for the answer and its rows."

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / speed

Added value: +{
+  "description": "fast gives the search results in about a second: the first engines' results with their snippets, each with the time it was read (read_at), with no answer, rows or passages, at most 10 results. default also reads the results for the answer and its rows.",
+  "title": "Speed",
+  "type": "string"
+}

Changed1 schema field changedNov 8, 2026

changedInput schema / properties / num / description

Previous value: -"The number of results (sources) to return, 1 to 100. Without num or page, the reply holds every result the answer read. When the first search finds fewer, SpecStream searches deeper (more engines and their next result pages) before it answers. The price of a call does not change."New value: +"The number of results (sources) to return, 1 to 100. Without num or page, the reply holds every result the answer read. When the first search finds fewer, SpecStream searches deeper (more engines and their next result pages) before it answers. A call of up to 10 results is $0.005; each started block of 10 more results adds $0.006 (num=100 is $0.059)."

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / num

Added value: +{
+  "description": "The number of results (sources) to return, 1 to 100. Without num or page, the reply holds every result the answer read. When the first search finds fewer, SpecStream searches deeper (more engines and their next result pages) before it answers. The price of a call does not change.",
+  "maximum": 100,
+  "minimum": 1,
+  "title": "Num",
+  "type": "integer"
+}

addedInput schema / properties / page

Added value: +{
+  "description": "The page of results to return, 1 to 10, num results each (10 without num). Page 2 continues the same list as page 1. The answer and the rows are on page 1 only. next_page in the reply names the next page, or is null when the engines found no more.",
+  "maximum": 10,
+  "minimum": 1,
+  "title": "Page",
+  "type": "integer"
+}

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / passages

Added value: +{
+  "description": "Also return the text of the top pages closest to the request, each with its page, so a caller sees the evidence without reading a page",
+  "title": "Passages",
+  "type": "boolean"
+}

Changed1 schema field changedNov 4, 2026
- addedInput schema / properties / q / description
```
Added value: +"The question or the request in everyday words, in any language"
```
AddedNov 4, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations declare openWorldHint=true, destructiveHint=false and readOnlyHint=false, and the description is consistent with them by explaining the billing side effect ($0.005 for up to 10 results, +$0.006 per started block of 10) and that no quote or approval is needed. It also discloses return shape and pagination via next_page. With the safety and openness profile already covered by annotations, the remaining added value is real but modest beyond the cost detail.

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?

Front-loaded with purpose, then returns, then pagination, then pricing, then the exclusion — a sensible ordering. It is dense and sentence-heavy, and the long return enumeration reads as a run-on, but essentially every clause carries operational information the agent needs given there is no output schema.

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?

With no output schema, the description fully describes the return payload: kind, answer with source page, rows and their values with pages, sources, took_ms, request_id, next_page, and the handoff block for lists. Cost, approval requirements, and pagination limits are all disclosed, leaving nothing an agent needs missing in order to call and price a search correctly.

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

Parameters3/5

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

Schema coverage is 100%, and every parameter (q, num, page, speed, passages) is already documented in the schema, including the same cost table. The description adds only a light relational note (num sets source count, page continues the same list, next_page names the next page) and never mentions the speed or passages parameters at all. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

Opens with a specific verb and resource ('answers a question from the live web in seconds') and immediately scopes the tool to 'one fact, or the first rows of a list.' The closing sentence explicitly separates it from the compiled-request path used for full lists, so an agent can tell this apart from the paid full-table flow.

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?

States the use case ('one fact, or the first rows of a list before the full table is priced') and the exclusion ('A full list is run from a compiled request and its quote, not from this search'). The condition that diverts work elsewhere is explicit rather than inferred.

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

All SpecStream tools Inspect

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.