An MCP server implementation in Go that provides web search, Wikipedia search, and current time tools with decorator-based logging and tracing capabilities
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Three read-only tools with basic schema definitions but significant gaps. Tool names lack action verbs (WebSearchTool, WikiSearchTool instead of search_web, search_wiki). Descriptions are present but generic and under 100 chars. Input schemas are defined with enums and required fields, but parameter descriptions are minimal or missing. Output schemas are absent or trivial. Error handling and recovery guidance are not visible in the code. The decorator pattern shows logging and tracing infrastructure but does not add schema richness or error context. Overall structure is functional but lacks LLM-optimization patterns for parameter clarity and error recovery.
Tools (3)
Current Timeread only45/100
Returns the current time in the specified city
WebSearchToolread onlyauth50/100
Return a json with the result of search terms with brave search engine, with types web, news, images or videos
WikiSearchToolread only50/100
Return a json with the result of title search in Wikipedia, searchType can be summary or html(return html representation of the wikipedia page)
Tool names do not follow verb_noun convention. 'WebSearchTool' and 'WikiSearchTool' are class names, not action-oriented tool identifiers. Should be 'search_web', 'search_wiki', 'get_time' to help LLMs infer intent from the name alone.
Parameter descriptions are sparse or absent. 'searchTerms' in WebSearchTool has no description. 'searchType' has no description explaining what each enum value (web, images, videos, news) returns. LLMs cannot infer parameter semantics from names alone.
Output schemas are missing or trivial. CurrentTimeTool.GetOutputSchema() returns an empty object schema with no properties. WikiSearchTool and WebSearchTool do not expose GetOutputSchema in the provided code. LLMs cannot plan downstream calls without knowing what fields are returned.
Current TimeWikiSearchToolWebSearchTool
Recommendations
Rename tools to action verbs: 'search_web' (not WebSearchTool), 'search_wiki' (not WikiSearchTool), 'get_current_time' (not Current Time). This lets LLMs parse intent from the name alone.
Add a 1-2 sentence description to every parameter. Example for searchTerms: 'The search query (e.g. "machine learning models"). Supports boolean operators and quoted phrases.' Example for searchType: 'The result type to return: web (default search results), images (visual content), videos (video clips), news (recent news articles).'
Define and expose output schemas for all tools. Example for WebSearchTool: {'type': 'object', 'properties': {'results': {'type': 'array', 'items': {'type': 'object', 'properties': {'title': {'type': 'string'}, 'url': {'type': 'string'}, 'snippet': {'type': 'string'}, 'source': {'type': 'string'}}}}, 'total_results': {'type': 'integer'}, 'search_time_ms': {'type': 'integer'}}, 'required': ['results', 'total_results']}. This lets LLMs understand what they can extract from the result.
Add error recovery guidance. In the Call() method, when a search fails or returns no results, return a CallToolResult with error classification and next-step guidance. Example: 'No results found. Try: (1) Simplify the search terms, (2) Remove filters, (3) Use related_search tool to find alternative queries.'
Enhance tool descriptions to 150 - 250 chars. Example for WebSearchTool: 'Search the web using Brave Search. Supports multiple result types (web, images, videos, news). Returns structured results with titles, URLs, and snippets. Use this to find current information, verify facts, or discover related topics. Supports 3 languages: Spanish (es), English (en), French (fr).'
Spec posture evidence
Inferred effective spec: 2025-06-18+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error handling or recovery guidance visible. If a search returns no results, fails, or times out, there is no recovery message to guide the LLM. Tool.Call() returns (*mcp.CallToolResult, outT, error) but the CallToolResult content does not show error classification (retryable, user-fixable, fatal) or actionable next steps.
Tool descriptions are generic and under 100 chars. WebSearchTool: 'Return a json with the result of search terms with brave search engine...' does not explain WHEN to use it vs a local search, what 'brave search engine' is, or what the output structure contains. Baseline is 194 chars (p10=34, p90=392); these are around 100 - 120 chars and lack specificity.
Language/locale parameter in WebSearchTool ('lang': ['es', 'en', 'fr']) is required but has no description. LLMs do not know why lang is needed, what happens if an unsupported language is passed, or whether it affects the search or the result locale. Undocumented enums invite hallucinated values.
WebSearchTool
Add a 'max_results' or 'limit' parameter (default 10, max 50) to WebSearchTool to let agents control result count and prevent context window bloat. Document this in the parameter description: 'Maximum number of results to return (1 - 50, default 10). Use lower values for faster responses, higher values for comprehensive searches.'
For WikiSearchTool, clarify the searchType parameter: 'summary: Returns the article extract/summary (quick lookup). html: Returns the full HTML representation (for detailed parsing). Summary is recommended for LLM reasoning; html for detailed data extraction.'
Consider adding pagination support to WebSearchTool if the Brave API supports it. E.g., add 'offset' (default 0) and 'limit' (default 10, max 50) parameters so agents can iterate through large result sets without re-fetching. Document: 'Paginate through large result sets. offset=0 is the first page. Each page contains up to limit results.'
Add a 'timezone' parameter to CurrentTimeTool for completeness. Even though city-based lookup is reasonable, explicit timezone support lets agents query specific zones. Description: 'Optional IANA timezone (e.g. "America/New_York", "Europe/London"). If omitted, detected from city name. Use explicit timezone for ambiguous city names.'
Implement result capping and truncation. If WebSearchTool or WikiSearchTool returns very long text (e.g., full HTML), truncate to a reasonable token budget (e.g., 1000 chars) and include a note: 'Result truncated. Call with searchType=summary for a shorter extract.' This prevents context window exhaustion.