모든 MCP 클라이언트(예: Claude Desktop, Cursor)에서 Elasticsearch 클러스터에 직접 연결할 수 있는 MCP 서버입니다.
이 서버는 모델 컨텍스트 프로토콜(Model Context Protocol)을 사용하여 에이전트를 Elasticsearch 데이터에 연결합니다. 자연어 대화를 통해 Elasticsearch 인덱스와 상호 작용할 수 있습니다.
Related MCP server: Elasticsearch MCP Server
elasticsearch_health : Elasticsearch 클러스터 상태 정보를 가져오며, 선택적으로 인덱스 수준 세부 정보도 포함합니다.
list_indices : 사용 가능한 Elasticsearch 인덱스를 나열하고 정규식을 지원합니다.
create_index : 선택적 설정 및 매핑을 사용하여 Elasticsearch 인덱스를 생성합니다.
reindex : 선택적 쿼리 및 스크립트를 사용하여 소스 인덱스에서 대상 인덱스로 데이터를 다시 인덱싱합니다.
get_mappings : 특정 Elasticsearch 인덱스에 대한 필드 매핑을 가져옵니다.
create_mapping : Elasticsearch 인덱스에 대한 매핑 구조를 생성하거나 업데이트합니다.
search : 제공된 쿼리 DSL로 Elasticsearch 검색을 수행합니다.
bulk : Elasticsearch 인덱스에 대량 데이터 넣기
create_index_template : 인덱스 템플릿을 생성하거나 업데이트합니다.
get_index_template : 인덱스 템플릿에 대한 정보를 가져옵니다.
delete_index_template : 인덱스 템플릿 삭제
MCP 클라이언트는 귀하의 요청을 분석하고 어떤 Elasticsearch 작업이 필요한지 결정합니다.
MCP 서버는 다음과 같은 작업(인덱스 나열, 매핑 가져오기, 검색 수행)을 수행합니다.
MCP 클라이언트는 결과를 처리하여 사용자 친화적인 형식으로 표시합니다.
Elasticsearch 인스턴스
Elasticsearch 인증 자격 증명(API 키 또는 사용자 이름/비밀번호)
MCP 클라이언트(예: Claude Desktop, Cursor)
[!TIP] Elasticsearch MCP 서버를 사용하는 가장 쉬운 방법은 게시된 npm 패키지를 사용하는 것입니다.
MCP 클라이언트 구성
MCP 클라이언트를 엽니다. MCP 클라이언트 목록을 확인하세요. 여기서는 Claude Desktop을 구성하고 있습니다.
설정 > 개발자 > MCP 서버 로 이동하세요.
Edit Config 클릭하고 다음 구성으로 새 MCP 서버를 추가합니다.
지엑스피1
대화 시작하기
MCP 클라이언트에서 새로운 대화를 엽니다.
MCP 서버는 자동으로 연결되어야 합니다.
이제 Elasticsearch 데이터에 대한 질문을 할 수 있습니다.
Elasticsearch MCP 서버는 Elasticsearch에 연결하기 위한 구성 옵션을 지원합니다.
[!NOTE] 인증을 위해서는 API 키 또는 사용자 이름과 비밀번호를 모두 제공해야 합니다.
환경 변수 | 설명 | 필수의 |
| Elasticsearch 인스턴스 URL(레거시 | 예 |
| 인증을 위한 Elasticsearch API 키(레거시 | 아니요 |
| 기본 인증을 위한 Elasticsearch 사용자 이름(레거시 | 아니요 |
| 기본 인증을 위한 Elasticsearch 비밀번호(레거시 | 아니요 |
| Elasticsearch SSL/TLS에 대한 사용자 정의 CA 인증서 경로(레거시 | 아니요 |
[!NOTE] MCP 서버를 수정하거나 확장하려면 다음 로컬 개발 단계를 따르세요.
올바른 Node.js 버전을 사용하세요
nvm use종속성 설치
npm install프로젝트 빌드
npm run buildClaude Desktop App에서 로컬로 실행
클로드 데스크톱 앱 열기
설정 > 개발자 > MCP 서버 로 이동하세요.
Edit Config 클릭하고 다음 구성으로 새 MCP 서버를 추가합니다: GXP5
커서 편집기에서 로컬로 실행
커서 편집기 열기
커서 설정 > MCP 로 이동하세요
Add new global MCP Server 클릭하고 다음 구성으로 새 MCP 서버를 추가합니다: GXP6
MCP Inspector를 사용한 디버깅
ES_HOST=your-elasticsearch-url ES_API_KEY=your-api-key npm run inspector그러면 MCP Inspector가 시작되어 요청을 디버깅하고 분석할 수 있습니다. 다음이 표시됩니다.
Starting MCP inspector...
⚙️ Proxy server listening on port 6277
🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀[!TIP] MCP 클라이언트에서 시도할 수 있는 자연어 쿼리는 다음과 같습니다.
"Elasticsearch 클러스터의 상태는 어떻습니까?"
"내 클러스터에는 몇 개의 활성 노드가 있나요?"
"Elasticsearch 클러스터에는 어떤 인덱스가 있나요?"
"3개의 샤드와 1개의 복제본을 갖는 'users'라는 새로운 인덱스를 만듭니다."
"'old_index'에서 'new_index'로 데이터를 다시 인덱싱합니다."
'제품' 인덱스에 대한 필드 매핑을 보여주세요.
"'제품' 인덱스에 '태그'라는 키워드 유형 필드를 추가합니다."
"지난달 500달러 이상 주문한 모든 주문을 찾으세요."
"어떤 제품이 5점 만점에 가장 많은 리뷰를 받았나요?"
"이러한 고객 기록을 대량으로 '고객' 인덱스로 가져옵니다."
"패턴 'logs-*'를 사용하여 로그에 대한 인덱스 템플릿을 만듭니다."
"내 인덱스 템플릿을 모두 보여주세요."
"outdated_template" 인덱스 템플릿을 삭제하세요.
문제가 발생하면 GitHub 저장소에서 문제를 제기해 주시기 바랍니다.
Bulk data into an Elasticsearch index
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Target Elasticsearch index name | |
| documents | Yes | Array of documents to import | |
| idField | No | Optional document ID field name, if specified, the value of this field will be used as the document ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It only says 'Bulk data', omitting whether it overwrites, appends, error handling, limits, or idempotency. Completely opaque.
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 concise (one sentence), but this brevity sacrifices critical detail. It is not front-loaded with essential information.
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?
No output schema or return value information is provided. For a bulk operation, details on success/failure reporting, batch limits, and error handling are missing, leaving the tool incomplete.
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?
Although the schema covers all parameters with descriptions, the tool description adds no extra meaning. It does not explain how the parameters interact (e.g., how idField is used), offering minimal value.
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 uses 'Bulk' as a verb, which is ambiguous and does not clearly specify the action (e.g., indexing, updating). It fails to distinguish from sibling tools like 'index' or 'reindex'.
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 is provided on when to use this tool versus alternatives like create_index, reindex, or search. The description does not mention context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an Elasticsearch index, optionally configure settings and mappings
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Name of the Elasticsearch index to create | |
| settings | No | Index settings, such as number of shards and replicas | |
| mappings | No | Index mappings, defining field types, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states the action. It does not explain what happens if the index already exists (e.g., error or overwrite), side effects, or authentication/rate limits. The optional settings and mappings are mentioned but no behavioral details.
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 concise sentence that front-loads the main action. It avoids unnecessary words, though slight expansion would improve clarity without losing 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?
Despite moderate complexity (3 params, nested objects, no output schema), the description lacks crucial context such as error handling (e.g., index already exists), success response, and typical use cases. An agent would need additional information to use this tool correctly.
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 description coverage is 100%, with each parameter's purpose described in the schema. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
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 'Create an Elasticsearch index, optionally configure settings and mappings' uses a specific verb and resource, clearly distinguishing it from siblings like create_index_template or create_mapping. It is unambiguous and directly states the action.
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 is provided on when to use this tool versus alternatives (e.g., create_index_template for templates). There is no mention of prerequisites, such as Elasticsearch cluster availability or required permissions, nor any context for when to use settings vs. mappings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update an Elasticsearch index template
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the index template | |
| indexPatterns | Yes | Array of index patterns this template applies to | |
| template | Yes | Template configuration including settings, mappings, and aliases | |
| priority | No | Optional template priority - higher values have higher precedence | |
| version | No | Optional template version number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose whether the operation is idempotent, destructive, or has side effects on existing indices. Auth or rate limit information is absent.
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 is concise and front-loaded, but could include more useful details without becoming verbose. No wasted words.
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?
No output schema, no annotations. The description lacks information about return values or what 'update' entails. Given the complexity of index templates, the description is insufficient for an agent to understand full behavior.
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?
Input schema has 100% description coverage, so the schema already documents parameters. The description adds no extra meaning beyond the schema, providing only a brief restatement.
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 (create or update) and resource (Elasticsearch index template). It distinguishes from sibling tools like create_index (creates an index) and delete_index_template (deletes a template).
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 create vs update, or when this tool is appropriate over alternatives. The description does not specify prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update the mapping structure of an Elasticsearch index
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Elasticsearch index name | |
| mappings | Yes | Index mappings, defining field types, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the operation is destructive or merges with existing mappings. The term 'create or update' is ambiguous; it is unclear if existing mappings are replaced or added to.
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 sentence with no filler words. It is concise but could be slightly more informative without becoming verbose.
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 lack of output schema and annotations, the description should explain return values, error cases, or idempotency. It does not cover these, leaving the agent underinformed about the tool's behavior.
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 input schema has 100% coverage with descriptions for both parameters. The description does not add additional meaning beyond what the schema already provides, so it meets the baseline but does not enhance understanding.
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 explicitly states the action 'Create or update' and the resource 'mapping structure of an Elasticsearch index'. It clearly distinguishes from sibling tools like 'create_index' (which creates an index) and 'get_mappings' (which retrieves mappings).
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 like 'create_index' or 'get_mappings'. The description mentions 'create or update' but does not specify prerequisites (e.g., index must exist) or when to choose update over creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an Elasticsearch index template
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the template to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It only says 'Delete an Elasticsearch index template' without mentioning irreversibility, permissions, or effects on existing indices.
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 sentence with no wasted words, but it is too brief to be fully informative. Conciseness is achieved at the expense of clarity.
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 delete operation with no output schema and one parameter, the minimal description fails to convey important context such as irreversibility or required permissions. It feels incomplete for an agent.
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 schema already describes the 'name' parameter. The description adds no additional meaning beyond the schema.
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 'Delete' and the resource 'Elasticsearch index template', uniquely distinguishing it from sibling tools like create_index_template and get_index_template.
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 is provided on when to use this tool, prerequisites, or alternatives. The description simply states the action without any contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the health status of the Elasticsearch cluster, optionally include index-level details
| Name | Required | Description | Default |
|---|---|---|---|
| includeIndices | No | Whether to include index-level details |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states the action. It does not disclose that the operation is read-only, has no side effects, or any authentication or rate limit requirements. For a health check, this minimal disclosure is inadequate.
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 concise sentence of 12 words, front-loaded with the verb and resource. Every word earns its place with no redundancy or fluff.
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?
The description adequately conveys the tool's purpose and parameter, but lacks details on the output (e.g., health status values like green/yellow/red). Given the tool's simplicity and no output schema, a bit more context would be helpful.
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 description coverage is 100% for the lone parameter 'includeIndices', which already explains its purpose. The tool description adds minor context by saying 'optionally include index-level details', but does not significantly extend understanding beyond the schema.
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 tool retrieves the health status of an Elasticsearch cluster, optionally including index-level details. It uses a specific verb 'get' and a distinct resource, differentiating it from sibling tools like search or bulk.
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 is provided on when to use this tool versus alternatives, such as when to include index details or what the response indicates. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about Elasticsearch index templates
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional template name filter - if omitted, all templates are returned |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely states 'Get information' without describing what information is returned, whether the operation is read-only, or any potential side effects. The agent lacks essential behavioral context.
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 front-loads the verb and resource. Every word earns its place; there is no redundancy or unnecessary detail.
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 simplicity of the tool (one optional parameter, no output schema), the description covers basic purpose but fails to specify the return format or structure. It is minimally complete but could benefit from additional context about the expected output.
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 description coverage is 100%, and the schema already explains the 'name' parameter well. The tool description adds no extra semantic meaning beyond what the schema provides, so a baseline score of 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?
The description 'Get information about Elasticsearch index templates' uses a clear verb ('Get') and specific resource ('information about Elasticsearch index templates'). It unambiguously states the tool's function and distinguishes it from sibling tools like create_index_template or delete_index_template.
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 is provided on when to use this tool versus alternatives like get_mappings or list_indices. The optional 'name' parameter is mentioned in the schema but not in the description, and there is no indication of typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, support regex
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Optional regex pattern to filter indices by name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description lists indices but does not disclose pagination, performance, or side effects; no annotations to rely on, so the description carries full burden but is minimal.
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, front-loaded, no wasted words.
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?
No output schema, and description does not explain return format (e.g., what properties each index entry has), leaving gaps for the agent.
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 description mentions regex support, adding context beyond the schema description for the pattern parameter, which already has 100% coverage.
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 it lists all Elasticsearch indices with regex support, distinguishing it from sibling tools like search or create_index.
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 explicit guidance on when to use this tool vs alternatives; usage is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reindex data from a source index to a target index
| Name | Required | Description | Default |
|---|---|---|---|
| sourceIndex | Yes | Name of the source Elasticsearch index | |
| destIndex | Yes | Name of the destination Elasticsearch index | |
| query | No | Optional query to filter which documents to reindex | |
| script | No | Optional script to transform documents during reindex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as whether the operation is synchronous, whether it overwrites or appends to the target index, or potential side effects like cluster load.
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 with no extraneous information; concise and front-loaded.
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 straightforward nature of reindexing and that all parameters have good schema descriptions, the description is adequate but lacks details on return values (no output schema) and behavioral context (e.g., would benefit from mention of async or copying behavior).
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 descriptions are clear for all four parameters (100% coverage), so baseline is 3. The description adds minimal value beyond the schema, only restating the overall operation.
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 uses the verb 'Reindex' and specifies the resource as 'data from a source index to a target index', clearly distinguishing this tool from siblings like 'bulk' (bulk indexing) and 'create_index' (creating an index).
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 (e.g., using search and bulk operations), no prerequisites mentioned (e.g., indices must exist), and no context on performance implications or long-running nature.
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.
bulkcreate_indexcreate_index_templatecreate_mappingdelete_index_templateelasticsearch_healthget_index_templateget_mappingslist_indicesreindexsearchScored across 11 tools
Each tool targets a distinct Elasticsearch resource and action (e.g., create_index, create_mapping, search, bulk). There is no overlap or ambiguity; tools are clearly differentiated by their purpose.
Most tools follow a verb_noun pattern with underscores (e.g., create_index, get_mappings). However, 'elasticsearch_health' deviates by starting with a noun instead of a verb, causing a minor inconsistency.
With 11 tools, the server covers a reasonable breadth of Elasticsearch operations (index management, search, mapping, templates) without being excessive. The count fits well within the typical 3-15 range for a focused server.
The tool set lacks essential operations like deleting an index and document-level CRUD (get, delete by ID). While bulk and search are present, agents cannot perform complete lifecycle management, leading to significant gaps.
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.
Agent-driven search: build, import, tune, search, and score result quality — all over MCP.
Let AI agents query data and act across all your business apps via MCP.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
