Server has 6 tools with complete input schemas and descriptions present. Naming follows verb_noun convention (configure, describe_fields, discover, filter, query). However, descriptions are terse (avg ~80 chars, below 194-char baseline) and lack actionable context for LLM selection. Parameter descriptions exist but are minimal. Output schemas are defined in separate files (not visible in provided code), so schema completeness cannot be fully verified. Error handling via KibanaRequestError is structured but recovery guidance is limited. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels declared.

• Expand tool descriptions to 100-200 chars. Add WHEN to use each tool: 'Use configure_index after discover() to set up a specific log source. Use query() for complex KQL searches; use filter() for simple field-value matches.' This disambiguates tool selection.
• Add tool annotations: mark configure and configure_index with destructiveHint=true (they replace state); mark describe_fields, discover, filter, query with readOnlyHint=true. This signals safety properties to LLMs.
• Enhance parameter descriptions with dependency hints. E.g., source_id: 'Logical source identifier (call discover() to list available sources)'. For query, add: 'Accepts KQL or Elasticsearch Query DSL, use KQL for simple filters, Query DSL for complex aggregations.'
• Add recovery guidance to error responses. When KibanaRequestError is caught, include actionable next steps: 'Kibana timeout. Retry with a smaller limit or simpler query.' instead of just the error code.
• Document output schemas inline or in a separate schema file. Specify: pagination (limit, total, next_cursor), chaining IDs (source_id, field names), and field types. Verify responses include all IDs downstream tools need.