Skip to main content
Glama
Sign In
ollama-search-mcp

ollama-search-mcp

by anaconda110
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Web fetch

web_fetch
Read-only

Fetch a URL and return its readable text plus outgoing links, so you can read a page found by web_search.

Instructions

Fetch one URL and return its readable text plus outgoing links. Use it to read a page found by web_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": {
      "url": "<url>"
    },
    "name": "web_fetch"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL to fetch.
max_charsNoTotal text budget in characters (default 20000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and network-access profile is covered. The description adds that it returns readable text plus outgoing links, which annotations do not convey, but it says nothing about truncation, non-HTML content, or failure behavior for unreachable URLs.

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 short sentences, zero filler, with the purpose and the return value front-loaded before the usage pointer. Every clause 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?

With no output schema, the description carries the return-value burden and does so at a high level (readable text plus outgoing links). Parameter edge cases are covered by the schema, but failure modes for unreachable or non-HTML URLs remain unspecified.

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 description coverage is 100%, with url and max_chars each documented inline including the default and minimum, so the baseline is 3. The description adds no additional meaning about the parameters, which is acceptable given the schema does the work.

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 (fetch), a specific resource (one URL), and the return payload (readable text plus outgoing links). The second sentence routes it against the sibling web_search by casting web_fetch as the read step for a page search discovered, so an agent can separate the two 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 Guidelines4/5

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

Explicitly says when to reach for it ('read a page found by web_search') and effectively names the alternative tool. It stops short of stating exclusions, e.g. that it should not be used for discovery/searching or that non-HTML or blocked pages may fail.

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

Deploy Server

Other Tools