This MCP server provides 10 tools for sales database operations via FastMCP. Tool definitions are present with basic schemas and descriptions, but significant quality gaps reduce usability for LLM-based agents. All tools have descriptions (10-70 chars), but many are too terse and lack actionable context. Input schemas are present but minimal, most lack parameter descriptions beyond the name. The `execute_sql` tool exposes a dangerous WRITE operation without safeguards, validation, or dry-run capability. Output schemas are entirely undocumented, forcing LLMs to guess at response structure. Error handling is absent, no recovery guidance or categorization. Tool composition lacks pagination for result-bearing calls (e.g., `get_top_products`, `get_distinct_values`). Names follow verb_noun convention (good), but parameter naming is inconsistent (sometimes 'table_name', sometimes implicit). This server is functional for basic use but would not pass production code review.

• Add a 4-6 sentence description to each tool explaining WHAT it does, WHEN to use it (vs. similar tools), and WHAT to expect in the response. Target 100-200 characters per description. Example: 'execute_sql' should state it runs read-only queries only, explain the table schema first, and warn that it cannot modify data.
• Document the output schema for each tool. Create a JSON Schema object describing all returned fields, types, and nesting. Include in the tool definition or a reference guide. Example: get_top_products returns {"products": [{"product_id": integer, "name": string, "revenue": number}]}.
• Add descriptions to all parameters in the JSON Schema. Every 'properties' entry should have a 'description' field. Example: 'table_name': {"type": "string", "description": "Name of the database table to query (case-insensitive; e.g., 'sales', 'customers')."}.
• Restrict execute_sql to SELECT queries only. Use a whitelist (e.g., regex /^SELECT/i) to reject INSERT, UPDATE, DELETE, DROP, or TRUNCATE. Log all queries for audit. Add a dry_run parameter to validate syntax before execution. Better: split into separate read-only execute_query and admin-only execute_ddl tools.
• Add limit and offset (or cursor) parameters to get_distinct_values, get_sales_by_store, and get_inventory_status. Include a 'total_count' in responses. Suggest pagination defaults: limit=50, max=1000. Document in description: 'Results are paginated; call again with offset=<next_offset> to fetch more.'
• Add error handling and recovery guidance. Example for execute_sql: 'If table not found, call get_all_tables() first to list available tables. If query timeout, reduce the WHERE clause or add a LIMIT.' Include in description or as a separate error reference.

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

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