Loading ToolBench
MCP server for managing multiple Elasticsearch instances with raw Dev Tools-style query execution, per-instance memory, and shared docs
This Elasticsearch MCP server has 7 tools with generally clear names and functional descriptions, but significant gaps in schema completeness, parameter documentation, and error handling. Tool names follow verb-noun conventions well (run_query, list_instances, get_docs, write_docs, get_memory, write_memory, init). Descriptions are present for all tools and range from adequate to good (average ~150 chars). However, critical issues emerge: (1) The 'body' parameter in run_query lacks a schema definition, it's declared as type 'object' with minimal constraint documentation, inviting LLM hallucination of invalid JSON structures. (2) write_memory's 'memory_type' enum is tightly constrained (info|lessons_learned), but the description does not explain when to use each, guidance is weak. (3) No output schemas are documented for any tool, callers do not know what fields to expect. (4) Error handling is absent, no guidance on retryability, user-fixable errors, or recovery paths. (5) The init() tool accepts an optional instance_name but the description does not clarify what happens if omitted (user will be asked). (6) Large result handling (80KB cap, file path fallback) is described in system instructions but not in the tool itself. A production-grade implementation would document output shapes and error categories explicitly.
Read the global documentation about all configured Elasticsearch instances, their purposes, cross-instance relationships, and usage guidance.
Read all persistent memories for a specific Elasticsearch instance. Returns past lessons learned, field mappings, data patterns, and other discovered knowledge about this instance.
Run guided discovery across Elasticsearch instances. Backs up existing docs/memories automatically, then provides a discovery framework to explore and document all instances (or a single specified instance). Returns discovery tasks and phase guidance.
List all configured Elasticsearch instances with their names, environments, query rules, and index patterns.
Execute a raw Elasticsearch query on a specific instance, exactly like Elasticsearch Dev Tools / Kibana console. Supports all HTTP methods (GET, POST, PUT, DELETE) and arbitrary paths with optional JSON body.
Write or append to global documentation. Use this to document instance purposes, patterns, and setup-level knowledge that applies across instances.
No output schemas documented for any tool. LLMs cannot predict response structures (fields, types, nesting) and must infer from description text alone, leading to parsing errors and wasted context tokens.
run_query 'body' parameter is type 'object' with no structural constraints. No guidance on valid keys, method-specific requirements (GET vs POST), or what happens if the body is malformed. Invites LLM hallucination of invalid JSON.
No error handling guidance across any tool. No documentation of retryable errors, user-fixable errors, or recovery paths. When a tool fails (e.g., instance not found, permission denied), LLMs have no actionable next step.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Write a memory entry for a specific Elasticsearch instance. Append genuinely useful discoveries (field mappings, data patterns, query gotchas, useful query patterns) to the instance's persistent knowledge base.
Destructive operations (write_docs with overwrite mode, write_memory, init) lack confirmation/dry-run steps. No guard against accidental data loss. Agent mistakes can silently overwrite documentation or memories.
write_memory's 'memory_type' enum (info|lessons_learned) lacks semantic guidance. Description should explicitly state when to use each option.
init() tool's optional instance_name and 'user will be asked' behavior is vague. Unclear how LLM elicitation works in MCP context (no Multi Round-Trip Requests pattern visible). Interaction flow is not formalized.
No input validation constraints documented for parameters (instance_name, content length, path format). LLMs may pass invalid inputs without guidance on acceptable ranges or formats.
System instructions mention 80KB result size limit and file path fallback, but this behavior is not documented in the run_query tool definition itself. LLMs relying on the tool definition alone will not know about this limit.