Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
oreolook-mcp provides 5 tools with clear descriptions and mostly complete input schemas. All tools have descriptions in the 50-120 character range, which is appropriate for LLM parsing. Input schemas include type declarations, enums, and parameter ranges. However, output schemas are not documented in the provided code, and tool annotations (readOnlyHint, destructiveHint) are missing despite two tools being read-only and one being destructive. Error handling and recovery guidance are not evident. The server follows verb_noun naming conventions (search_web, fetch_pages, research_web, deep_research, export_research_pdf) appropriately. Parameter naming is generally clear with descriptions for each field.
Tools (5)
deep_researchread onlysource verified83/100
Trigger multi-step deep research mode with decomposition into sub-topics, independent research on each, and comprehensive synthesis. Returns structured answer with citations and evidence.
export_research_pdfwritesource verified75/100
Export research content or conversation to a professionally formatted PDF document. Use only for content already available in the conversation.
fetch_pagesread onlysource verified83/100
Fetch up to eight public HTTPS pages as clean structured text. Redirects and private network targets are blocked.
research_webread onlysource verified83/100
Research a focused question using live web sources and return a concise synthesized answer with normalized citations and evidence.
search_webread onlysource verified83/100
Search the live web and return bounded structured results. Use research_web when you need a synthesized answer.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields to expect from search_web, fetch_pages, research_web, deep_research, and export_research_pdf.
Tool annotations missing. search_web, fetch_pages, and research_web are read-only operations (marked 'Risk: READ_ONLY' in metadata), and export_research_pdf is destructive (marked 'Risk: WRITE'), but these are not conveyed to the MCP client via readOnlyHint/destructiveHint annotations in tool definitions.
No error handling or recovery guidance documented. Tools do not specify what errors they may return, how to classify them (retryable, user-fixable, fatal), or what the LLM should do next. fetch_pages has a 'browser_fallback' parameter but no documentation on when fallback is triggered or what happens on complete failure.
Recommendations
Document output schemas for all tools. For search_web, specify the fields in each result (title, url, snippet, domain, etc.). For fetch_pages, describe page_contents structure. For research_web and deep_research, document the structure of the synthesized answer (answer, sources array with url/title/snippet/confidence, evidence, etc.). For export_research_pdf, document whether it returns a file path, bytes, or a success confirmation.
Add tool annotations to each tool definition. Mark search_web, fetch_pages, research_web, deep_research as readOnlyHint: true. Mark export_research_pdf as destructiveHint: true (since it writes a file). Use idempotentHint: true for fetch_pages (assuming repeated calls with same URLs return same content).
Add explicit error handling to tool descriptions. E.g., for search_web: 'Returns empty results if no matches found or if the query is invalid. Returns an error if the API is rate-limited; retry after waiting.' For fetch_pages: 'Returns fetch errors if a URL is unreachable, blocked, or behind authentication. If browser_fallback is enabled, retries with Chromium rendering; if that fails too, returns a detailed error message with the URL and reason (timeout, certificate error, etc.). Use the error message to decide whether to try a different URL or skip it.'
Clarify pagination and result limits. Add to search_web description: 'Returns at most num_results results. If more exist, the results include a next_token for pagination (if applicable).' If pagination is not supported, state 'Results are not paginated; consider using additional query parameters to narrow results.' For fetch_pages, state: 'Fetches up to 8 URLs concurrently. If more than 8 are provided, additional URLs are queued and returned in a subsequent call.' Document how the LLM can request the next batch.
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Result limits not enforced in descriptions. research_web hardcodes max_sources 1-4 (reasonable), but search_web and fetch_pages do not state how results are paginated or capped. search_web defaults to 5 results but does not say what the maximum is or whether pagination is available. Without explicit limits, LLMs may request thousands of results, exhausting context window.
fetch_pages 'max_characters' description could be clearer. It says 'Maximum characters to extract per page' but does not explain how truncation works if content exceeds the limit (truncate silently? Include a flag? Return a note?). LLMs may not know whether truncated content is complete.
fetch_pages
Improve fetch_pages 'max_characters' documentation. Change to: 'Maximum characters to extract per page. If content exceeds this limit, it is truncated silently. Set to a higher value (e.g., 16000) for detailed content or lower (e.g., 2000) for summaries. Default 8000 is suitable for most use cases.'
Add parameter validation rules to descriptions. E.g., for search_web 'freshness': 'Must be one of: any, day, week, month, year. Determines how recent the search results must be.' For deep_research 'max_sources': 'Must be between 1 and 10; higher values return more comprehensive results but may take longer.'
Clarify the relationship between research_web and deep_research in their descriptions. E.g., research_web: 'For a quick answer from a focused set of sources.' deep_research: 'For a comprehensive answer that breaks down a complex question into sub-topics and researches each independently. Slower but more thorough than research_web.'
Document what research_web and deep_research return. Specify whether they include raw search results, synthesized text only, or both. If they include citations, document the citation format (markdown links, footnotes, etc.). Clarify what fields the LLM can extract from the response (e.g., answer text, source URLs, confidence scores).
Add idempotency guidance. If search_web with the same query always returns the same results (ignoring freshness), note this. If deep_research may produce slightly different decompositions on repeated calls due to randomness, state 'Results may vary slightly on repeated calls due to query decomposition randomness.'
Document the PDF export behavior in export_research_pdf. State whether it creates a file on disk, returns bytes, or returns a download URL. If a file, where is it stored? Can the LLM retrieve it afterward? If bytes, what encoding?