Two tools with well-structured schemas and comprehensive descriptions. Both tools have clear verb-noun naming (web_fetch, web_search) and detailed parameter documentation. Descriptions exceed 200 chars and include use cases, rules, and limits, well above the 194-char baseline. Input schemas are properly typed with required fields. However, output schemas are not formally documented, and error handling lacks recovery guidance. No tool annotations (readOnlyHint) despite both being read-only operations.
What it does: Fetches the content of a single URL and returns it as readable markdown. HTML is converted to markdown so the result is easy to read and quote. When to use: Use this tool whenever you need to retrieve or analyze live webpage content (e.g. research, quoting, summarization, checking a link, comparing pages). Use cases (in order): - Recall: The LLM recalls or selects the relevant URL(s) from the user's question, its knowledge, context, or links the user provided. Then call this tool for each URL to get up-to-date content. One URL per call. - Crawling: When you need many pages or want to crawl multiple URLs, call this tool in a loop. One tool call per URL. Do not pass multiple URLs in one call. Iterate over the list and call once per URL. Rules and limits: - The URL must be a fully-formed, valid URL (http or https). - This tool is read-only. It does not perform actions that change state or have side effects. - Results may be live or cached; the tool does not guarantee real-time freshness. - Authentication is not supported. If the URL requires login or auth, an error will be returned. - If the server returns a non-200 status (e.g. 404, 500), the tool returns an error message instead of page content. - This fetch runs from an isolated environment. Hosts like localhost and private IPs may not work. - Binary content is not supported (e.g. media files, PDFs). Only text-like responses are returned. - Requests are bounded by a maximum timeout. Very slow or unresponsive URLs will return a timeout error. - For static assets or non-webpage URLs, use another tool if available.
What it does: Runs a web search for one query via Ollama's web search API. Returns a list of results. Each result has a title, a URL, and a short text snippet. Use this to discover links by topic; then use web_fetch to get full page content for any URL you choose. When to use: Use when the user wants to search the web by query, explore a topic, or find URLs about something. After you get results, pick one or more URLs from the list and call web_fetch with that URL to retrieve the full page as markdown. Workflow: Call this tool with a query (e.g. "Ollama new engine", "Deno router tutorial"). You get back up to 10 results (title, url, snippet per result). To read a full page, call web_fetch with the url from the result. One query per call; for multiple topics, call web_search once per query. Rules and limits: - Query is required. max_results is optional (default 5, max 10). - Requires OLLAMA_API_KEY in the environment or MCP server config (e.g. from your Ollama account). - Read-only, no side effects. Results may be cached by the search provider.
Output schemas not documented. Tool descriptions explain inputs but do not specify what fields/structure the LLM should expect in responses. This forces LLMs to infer output structure, risking parsing errors and downstream tool chaining failures.
Error handling lacks recovery guidance. Code returns generic error messages (e.g., 'Invalid params') without actionable next steps. Per pattern:recovery-guide, errors should tell the LLM what to do: 'URL requires authentication, try a different URL or use web_search to find an alternative source.'
Tool annotations missing. Both tools are read-only (marked with Risk: READ_ONLY in metadata) but lack readOnlyHint in schema. Per current MCP spec (2026-07-28), tool annotations enable clients to optimize UI and prevent accidental destructive calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
No pagination support documented for web_search. Tool returns 'up to 10 results' but does not expose offset/limit parameters or next_cursor. Per pattern:paginated-result, tools returning lists should support pagination to avoid context window exhaustion.
Parameter max_results lacks validation constraints in schema. Description states 'default 5, max 10' but schema has no minimum/maximum bounds.