Dieses Repository enthält experimentelle Funktionen, die für Forschung und Evaluierung bestimmt sind und nicht produktionsreif sind.
Stellen Sie mithilfe des Model Context Protocol (MCP) direkt von jedem MCP-Client (wie Claude Desktop) eine Verbindung zu Ihren Elasticsearch-Daten her.
Dieser Server verbindet Agenten über das Model Context Protocol mit Ihren Elasticsearch-Daten. Er ermöglicht Ihnen die Interaktion mit Ihren Elasticsearch-Indizes über natürliche Sprachkonversationen.
list_indices : Listet alle verfügbaren Elasticsearch-Indizes auf
get_mappings : Ruft Feldzuordnungen für einen bestimmten Elasticsearch-Index ab
search : Führen Sie eine Elasticsearch-Suche mit der bereitgestellten Abfrage-DSL durch
get_shards : Shard-Informationen für alle oder bestimmte Indizes abrufen
Related MCP server: Elasticsearch MCP Server
Eine Elasticsearch-Instanz
Elasticsearch-Authentifizierungsdaten (API-Schlüssel oder Benutzername/Passwort)
MCP-Client (z. B. Claude Desktop)
https://github.com/user-attachments/assets/5dd292e1-a728-4ca7-8f01-1380d1bebe0c
[!TIP] Am einfachsten lässt sich der Elasticsearch MCP-Server über das veröffentlichte npm-Paket verwenden.
MCP-Client konfigurieren
Öffnen Sie Ihren MCP-Client. Sehen Sie sich die Liste der MCP-Clients an. Hier konfigurieren wir Claude Desktop.
Gehen Sie zu Einstellungen > Entwickler > MCP-Server
Klicken Sie auf Edit Config und fügen Sie einen neuen MCP-Server mit der folgenden Konfiguration hinzu:
{
"mcpServers": {
"elasticsearch-mcp-server": {
"command": "npx",
"args": [
"-y",
"@elastic/mcp-server-elasticsearch"
],
"env": {
"ES_URL": "your-elasticsearch-url",
"ES_API_KEY": "your-api-key"
}
}
}
}Eine Unterhaltung beginnen
Öffnen Sie eine neue Konversation in Ihrem MCP-Client
Der MCP-Server sollte automatisch eine Verbindung herstellen
Sie können jetzt Fragen zu Ihren Elasticsearch-Daten stellen
Der Elasticsearch MCP-Server unterstützt Konfigurationsoptionen zum Herstellen einer Verbindung mit Ihrem Elasticsearch:
[!NOTE] Sie müssen zur Authentifizierung entweder einen API-Schlüssel oder sowohl Benutzernamen als auch Kennwort angeben.
Umgebungsvariable | Beschreibung | Erforderlich |
| Die URL Ihrer Elasticsearch-Instanz | Ja |
| Elasticsearch-API-Schlüssel zur Authentifizierung | NEIN |
| Elasticsearch-Benutzername für die Basisauthentifizierung | NEIN |
| Elasticsearch-Passwort für die Basisauthentifizierung | NEIN |
| Pfad zum benutzerdefinierten CA-Zertifikat für Elasticsearch SSL/TLS | NEIN |
[!NOTE] Wenn Sie den MCP-Server ändern oder erweitern möchten, befolgen Sie diese lokalen Entwicklungsschritte.
Verwenden Sie die richtige Node.js-Version
nvm useAbhängigkeiten installieren
npm installErstellen des Projekts
npm run buildLokal in der Claude Desktop App ausführen
Öffnen Sie die Claude Desktop App
Gehen Sie zu Einstellungen > Entwickler > MCP-Server
Klicken Sie auf Edit Config und fügen Sie einen neuen MCP-Server mit der folgenden Konfiguration hinzu:
{
"mcpServers": {
"elasticsearch-mcp-server-local": {
"command": "node",
"args": [
"/path/to/your/project/dist/index.js"
],
"env": {
"ES_URL": "your-elasticsearch-url",
"ES_API_KEY": "your-api-key"
}
}
}
}Debuggen mit MCP Inspector
ES_URL=your-elasticsearch-url ES_API_KEY=your-api-key npm run inspectorDadurch wird der MCP Inspector gestartet, mit dem Sie Anfragen debuggen und analysieren können. Folgendes sollte angezeigt werden:
Starting MCP inspector...
Proxy server listening on port 3000
🔍 MCP Inspector is up and running at http://localhost:5173 🚀Wir freuen uns über Beiträge aus der Community! Weitere Informationen dazu, wie Sie beitragen können, finden Sie in den Richtlinien für Beiträge .
[!TIP] Hier sind einige Abfragen in natürlicher Sprache, die Sie mit Ihrem MCP-Client ausprobieren können.
„Welche Indizes habe ich in meinem Elasticsearch-Cluster?“
„Zeigen Sie mir die Feldzuordnungen für den Index ‚Produkte‘.“
„Finden Sie alle Bestellungen über 500 $ vom letzten Monat.“
„Welche Produkte haben die meisten 5-Sterne-Bewertungen erhalten?“
Der MCP-Client analysiert Ihre Anfrage und ermittelt, welche Elasticsearch-Operationen erforderlich sind.
Der MCP-Server führt diese Vorgänge aus (Auflisten von Indizes, Abrufen von Zuordnungen, Durchführen von Suchvorgängen).
Der MCP-Client verarbeitet die Ergebnisse und präsentiert sie in einem benutzerfreundlichen Format.
[!WARNING] Vermeiden Sie die Verwendung von Clusteradministratorberechtigungen. Erstellen Sie dedizierte API-Schlüssel mit begrenztem Umfang und wenden Sie eine differenzierte Zugriffssteuerung auf Indexebene an, um unbefugten Datenzugriff zu verhindern.
Sie können einen dedizierten Elasticsearch-API-Schlüssel mit minimalen Berechtigungen erstellen, um den Zugriff auf Ihre Daten zu kontrollieren:
POST /_security/api_key
{
"name": "es-mcp-server-access",
"role_descriptors": {
"mcp_server_role": {
"cluster": [
"monitor"
],
"indices": [
{
"names": [
"index-1",
"index-2",
"index-pattern-*"
],
"privileges": [
"read",
"view_index_metadata"
]
}
]
}
}
}Dieses Projekt ist unter der Apache-Lizenz 2.0 lizenziert.
Stellen Sie sicher, dass Ihre MCP-Konfiguration korrekt ist.
Stellen Sie sicher, dass Ihre Elasticsearch-URL von Ihrem Computer aus zugänglich ist.
Überprüfen Sie, ob Ihre Authentifizierungsdaten (API-Schlüssel oder Benutzername/Passwort) über die erforderlichen Berechtigungen verfügen.
Wenn Sie SSL/TLS mit einer benutzerdefinierten Zertifizierungsstelle verwenden, überprüfen Sie, ob der Zertifikatspfad korrekt ist und die Datei lesbar ist.
Suchen Sie in der Terminalausgabe nach Fehlermeldungen.
Wenn Sie auf Probleme stoßen, können Sie gerne ein Problem im GitHub-Repository öffnen.
Get field mappings for a specific Elasticsearch index
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Name of the Elasticsearch index to get mappings for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Get field mappings', implying read-only but not disclosing permissions, side effects, or behavior like error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention what the response contains; it is adequate but minimal for a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'index' has a description; the tool description adds no extra meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'field mappings' for a specific Elasticsearch index, clearly distinguishing from siblings like create_mapping or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; for example, it doesn't explain how it differs from create_mapping or search in terms of use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Elasticsearch indices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'List' implies a read operation, it doesn't specify whether this requires special permissions, returns paginated results, includes hidden/system indices, or provides any metadata beyond names. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read operation without output schema, the description provides the minimum viable information about what the tool does. However, given the lack of annotations and sibling tools with potentially overlapping functionality, more context about when to use this versus alternatives would be helpful. The description is complete enough for basic understanding but leaves operational context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the schema handles all parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available Elasticsearch indices'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_mappings' or 'search' - it's unclear if this is a simple listing versus more detailed metadata retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_mappings' or 'search'. There's no indication of whether this is for administrative purposes, discovery, or as a prerequisite for other operations. The agent must infer usage context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform an Elasticsearch search with the provided query DSL. Highlights are always enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Name of the Elasticsearch index to search | |
| queryBody | Yes | Complete Elasticsearch query DSL object that can include query, size, from, sort, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only mentions highlights are always enabled. No disclosure of read-only nature, error handling, pagination, or required permissions. With no annotations, more behavioral detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action. No wasted words, though could be expanded with important behavioral notes without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Elasticsearch searches (query DSL), the description lacks return format, pagination behavior, and error context. Incomplete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes both parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs an Elasticsearch search with query DSL, identifying the specific verb and resource. Distinguishes from sibling tools that handle index management, bulk operations, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over siblings (e.g., bulk, list_indices) or when not to use it. Lacks prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_mappingslist_indicessearchScored across 3 tools
Each tool has a clearly distinct purpose: get_mappings retrieves field mappings for a specific index, list_indices enumerates all indices, and search performs query-based searches. There is no overlap in functionality, making tool selection unambiguous.
All tool names follow a consistent verb_noun pattern (get_mappings, list_indices, search), with clear and descriptive verbs that align with their actions. No deviations or mixed conventions are present.
With only 3 tools, the set feels thin for an Elasticsearch server, as it lacks essential operations like creating/deleting indices, updating mappings, or performing CRUD operations on documents. While the tools are well-defined, the count is borderline for the domain's scope.
There are significant gaps in the tool surface for Elasticsearch functionality. Missing operations include index creation/deletion, document indexing/updating/deleting, and cluster management. This incompleteness will likely cause agent failures when attempting full workflows.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Connect Claude, Cursor, or ChatGPT to your business data. Ask questions, get answers.
Build and manage AI-native customer support agents from Claude or any MCP client.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
