FastAgent exposes 5 tools with basic schemas and descriptions, but significant gaps limit production readiness. Tool names lack consistent verb prefixes (map_search, route_planning, trending_search are acceptable; mcp_tool is generic). Descriptions exist but are minimal (10-50 chars) and lack context on when/why to use each tool. Parameter descriptions are present but sparse. database_query has good input validation (SQL injection checks, SELECT-only enforcement) but no documented output schema. mcp_tool is a meta-tool that proxies to other MCP servers, unusual and risky. Error handling is basic (try/catch with string returns). No tool annotations (readOnlyHint, destructiveHint). Overall: functional but below production baseline.

• Remove or redesign mcp_tool. If the goal is to compose other MCP servers, use explicit tool registration instead of a generic proxy. If needed, document exactly which MCP servers are supported and what tools they expose.
• Expand tool descriptions to 100-200 chars. Include: what the tool does, when to use it (vs similar tools), what it returns, and any prerequisites. Example: 'Search for a location by name using Amap API. Returns the first matching POI with address and coordinates. Use this before route_planning to resolve place names to coordinates.'
• Document output schemas for all tools. Define structured return types (e.g., {location: string, address: string, coordinates: string} for map_search) so LLMs know what fields to expect.
• Add tool annotations to MCP tool definitions. Mark database_query and trending_search with readOnlyHint=true. Mark mcp_tool with destructiveHint=true if it can execute write operations.
• Improve error messages with recovery guidance. Instead of 'Error executing query: syntax error', return 'SQL syntax error in query. Check that the query starts with SELECT and contains no DROP/ALTER/DELETE keywords. Retry with a corrected query.'

Inferred effective spec: <=2025-11-25.

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