This server has critical definition quality gaps. All three tools lack proper MCP tool registration with explicit schemas. Tool names are generic verbs without clear action semantics (summarize, grammar_check, keywords). Descriptions are present but minimal (34-72 chars, below the 194-char baseline). Input parameters lack type definitions in a formal schema structure, only inferred from Pydantic models. No output schema is documented. The routing mechanism (string matching on prompt text) is fragile and not MCP-compliant. Tools are not registered via MCP's tool registration protocol; they exist only as FastAPI endpoints. This is a custom HTTP wrapper, not a proper MCP server.

• Implement proper MCP tool registration. Define each tool with explicit JSON Schema for inputs and outputs. Use the MCP SDK or protocol to register tools, not FastAPI routes.
• Rename tools to action-verb form: 'generate_summary', 'correct_grammar', 'extract_keywords'. This clarifies intent and helps LLMs select the right tool.
• Expand tool descriptions to 100 - 200 chars. Include: what the tool does, when to use it (vs. similar tools), input constraints (max text length), and output format. Example: 'Generates a concise summary (30 - 130 tokens) of input text using BART. Use when you need a brief overview. Input must be 50+ chars.'
• Document input and output schemas formally. For inputs: specify that 'context' is a string (min 50 chars, max 10000 chars) and 'prompt' is a routing hint. For outputs: return a structured object with 'summary' (string), 'token_count' (int), and 'model' (string).
• Replace string-matching routing with explicit tool parameters. Instead of parsing the prompt to guess which tool to call, let the client specify the tool name and pass parameters directly. This eliminates ambiguity and aligns with MCP semantics.