fetch_pagesLike fetch_page but for up to 20 URLs in one call — the bulk-read counterpart to search_batch, so reading a page of results is one round trip instead of ten. Each page comes back with its cleaned text from the index; URLs not in the index are marked, not fatal.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs of indexed pages. | |
| maxChars | No | Truncate each body to this many characters. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral detail: each page returns cleaned text from the index, and missing URLs are marked rather than causing failure. This goes beyond the schema and helps an agent set expectations.
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 compact and front-loaded: it names the primary behavior, the relationship to fetch_page, the batching benefit, and the non-fatal missing-URL behavior in just two sentences. No filler 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?
For a read-only bulk tool with two well-described parameters and no output schema, the description sufficiently covers purpose, usage context, return content, and an important edge case. Minor missing details like response ordering or error handling for invalid URLs are not critical given the annotations and schema coverage.
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 100%, so the baseline is 3. The description reinforces the 'up to 20 URLs' limit and mentions cleaned text, but it does not add meaningful semantic detail beyond what the input schema already provides for urls and maxChars.
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 reads several indexed pages at once, specifies a limit of 20 URLs, and explicitly contrasts it with fetch_page for single-URL reads. This makes it immediately distinguishable from its closest sibling.
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?
It provides clear context for when to use this tool: when you need multiple indexed pages in one round trip, framed as the bulk-read counterpart to search_batch. It implies fetch_page is for single URLs and search_batch is for searches, but it does not explicitly state exclusions or edge cases like 'use fetch_page for one URL'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct operation: core search, batch search, product search, passage-level retrieval, similarity lookup, page fetching, watch management, and index introspection. The potentially overlapping tools are explicitly differentiated, such as search_products versus search, and the batch variants are clearly scoped.
Most tools follow a clear verb_noun snake_case pattern like fetch_page, delete_watch, list_sites, and watch_query. The pattern is slightly weakened by noun-phrase names like index_stats and source_profile, but the naming remains predictable overall.
Fourteen tools is within the ideal range for a search-focused server, and each tool covers a distinct feature: search, batch retrieval, product search, passage extraction, similarity, full-text fetching, watch lifecycle, and corpus introspection. No tool feels redundant or extraneous.
The toolset covers the full agent workflow for web search: querying, reading indexed pages, extracting citable passages, finding related content, monitoring with watches, and understanding corpus coverage and source trustworthiness. Minor conveniences like updating a watch are absent, but the lifecycle is otherwise complete.