Two tools with complete schemas and reasonable descriptions. web_search has good parameter constraints (enums for freshness, integer bounds for count). Descriptions are adequate (60-80 chars) but lack actionable context for LLM selection. Missing output schema documentation, LLMs cannot plan downstream calls without knowing what fields are returned. No error handling guidance. Parameter descriptions are minimal; 'The search query' lacks format/length constraints. local_search similarly lacks depth. No tool annotations (readOnlyHint present in metadata but not declared in schema). Overall: functional but below production baseline for agent-facing tools.

• Document output schema for both tools. Example: web_search returns {results: [{title, url, snippet, date}], total_count}. local_search returns {results: [{name, address, phone, rating, url}]}. This enables agents to extract and chain data.
• Enhance parameter descriptions with constraints and examples. E.g., 'query (string, 1-500 chars): The search term. Supports boolean operators (AND, OR, NOT) and quoted phrases. Example: "machine learning" AND python'.
• Add error recovery guidance in tool description. E.g., 'Returns up to 20 results. If rate-limited (HTTP 429), retry after 60 seconds. If API key invalid (401), check MCP_BRAVE_API_KEY environment variable.'
• Clarify freshness filter semantics. Describe what 'pd' (past day), 'pw' (past week), etc. mean and when to use them. E.g., 'Use pd for breaking news, pw for recent articles, pm for established trends.'
• Add tool annotations to schema. Mark both tools with readOnlyHint=true (they do not modify state). This signals to agents that these calls are safe to retry and do not require confirmation.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry