Two tools with adequate schemas and descriptions, but significant gaps in parameter documentation and error guidance. Both tools have clear names (run_suzieq_show, run_suzieq_summarize) starting with action verbs, and descriptions of 150-200 chars explaining what they do. However, the 'filters' parameter lacks type specificity (object with no property schema), and neither tool documents expected output structure or error recovery paths. Error handling exists in code (httpx exceptions caught) but responses are generic JSON strings without actionable guidance for LLMs. No pagination, no result limits documented, no per-item error reporting for batch-like operations.

• Define filters parameter schema with explicit properties: {type: 'object', properties: {hostname: {type: 'string'}, vrf: {type: 'string'}, state: {type: 'string'}, ...}, additionalProperties: false}. Document which filters are valid for each table.
• Document output schema in tool descriptions. E.g., 'Returns a JSON object with fields: data (array of records), count (total rows), error (if applicable).' Include example structure.
• Enhance error messages with recovery guidance. E.g., 'HTTP 404: Table "bgp" not found. Valid tables: device, bgp, interface, route. Try a different table.' or 'Configuration error: SUZIEQ_API_ENDPOINT not set. Add SUZIEQ_API_ENDPOINT=http://suzieq-api:8000 to .env file.'
• Add limit and offset parameters to both tools. Document default limit (e.g., 50) and maximum (e.g., 1000). Return total count in response so LLMs can paginate if needed.
• Add tool annotations (readOnlyHint: true) to both tools since they only query data and do not modify state. This signals to agents that these calls are safe to retry.