Multi-server MCP AI Assistant with tool discovery, caching, and analytics. Provides a FastAPI agent that orchestrates multiple specialized MCP servers (Note Manager, Web Search, Document Summarizer, Calculator) and uses LangChain/LangGraph with Ollama for LLM-driven tool calling.
This server exposes 13 tools across 4 microservices. Tool definitions are present and partially documented, but quality is inconsistent. Strengths: most tools have descriptions (80+ chars typically) and input schemas with type declarations. Weaknesses: parameter descriptions are often generic or missing detail; output schemas are entirely undocumented; error handling lacks recovery guidance; three tools named 'health_check' create dangerous ambiguity for LLM tool selection. The naming convention is weak (health_check, summarize_text) and several tools expose implementation details rather than user intent. No evidence of permission gating, input validation guidance, or security-focused descriptions. Tool composition is poor, related tools (web_search + fetch_url, summarize_text + extract_key_points) lack clear chaining semantics and return field alignment.
Evaluate a mathematical expression safely. Supports: +, -, *, /, ** (power), % (modulo), // (floor division), parentheses, and functions: sqrt, abs, round, min, max.
Convert a value from one unit to another. Supported conversions: - Distance: km <-> miles, meters <-> feet - Weight: kg <-> lbs - Temperature: celsius <-> fahrenheit - Volume: liters <-> gallons
Extract key points from the given text using a local LLM. Use this tool when the user wants the main ideas from a piece of text presented as a list of bullet points.
Fetch a web page and return its visible text content (cleaned, no HTML). Use this tool when the user wants to read the content of a specific URL. Scripts, styles, and navigation elements are stripped. Output is limited to 5 000 characters to keep responses concise.
Retrieve stored notes, optionally filtered by tag. Use this tool when the user wants to list or browse their saved notes. If a tag is provided, only notes with that tag are returned.
Three identically named 'health_check' tools across calculator, doc_summarizer, and note_manager create impossible disambiguation for LLM tool selection. When the LLM sees 'health_check' in the tool list, it cannot determine which service to check without reading file paths. This violates the principle that tool names alone should convey intent.
No documented output schemas for any tool. Tool descriptions explain what the tool does, but none specify what fields the response contains, their types, or how to chain outputs to downstream tools. This forces LLMs to infer structure from implicit behavior.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Check whether the Calculator server is healthy.
Check whether the Doc Summarizer server and Ollama are healthy. Use this tool to verify the server is running, and that Ollama is reachable with the expected model available.
Check whether the Web Search server is healthy. Use this tool to verify the server is running and responsive.
Check whether the Note Manager server is healthy. Use this tool to verify the server is running and responsive.
Save a new note with a title, content, and optional tags. Use this tool when the user wants to create, store, or remember a piece of information for later retrieval.
Search notes by keyword (substring match on title and content). Use this tool when the user wants to find notes related to a specific topic or keyword.
Summarize the given text using a local LLM (Ollama). Use this tool when the user wants a concise summary of a piece of text.
Search the web using DuckDuckGo and return the top results. Use this tool when the user asks a question that requires up-to-date information from the internet, or when they explicitly ask to search.
Parameter descriptions are generic or missing detail. Examples: 'from_unit' is described as 'The source unit (e.g. "km", "celsius")', not stating which units are actually valid or how to discover them. 'text' parameter in summarize_text has no example format. No validation guidance on string length limits, format patterns, or value constraints beyond what's implicit in the schema type.
No error handling guidance in any tool description. Tools reference external services (Ollama, DuckDuckGo, file I/O) with no indication of what happens on failure, whether errors are retryable, or what the LLM should do next. Example: 'summarize_text' description does not mention what happens if Ollama is unreachable or if the text exceeds 10,000 characters.
Tool composition lacks clear chaining semantics. web_search returns results with no documented field names; fetch_url accepts a URL but doesn't return structured metadata (title, author, publication date) that downstream tools might need. summarize_text and extract_key_points both take 'text' but don't indicate which upstream tool (fetch_url?) should feed them.
health_check tools are READ_ONLY diagnostics with no clear user intent. These should either be called automatically by the server, removed entirely, or renamed to service-specific names (check_calculator_health, verify_ollama_connection) to disambiguate them from each other and guide LLM selection.
Missing parameters that users would naturally provide. Example: convert_units does not document valid unit pairs. An LLM seeing 'from_unit: km, to_unit: celsius' would be invalid but the parameter descriptions don't warn against this.
save_note is a WRITE operation but its description does not explicitly state 'This tool creates and stores a new note permanently.' Agents need to know which calls have irreversible side effects so they can plan recovery if the note creation was unintended.
No pagination or result limiting documented for multi-item returns. get_notes accepts an optional 'tag' filter but no limit or offset parameters. If a user has 1000 notes, this tool would attempt to return all of them, exhausting context and tokens.