Elastic Agent Builder includes an MCP endpoint for letting external clients use tools configured in Elastic. It is the current Elastic path; the older standalone elastic/mcp-server-elasticsearch repository is deprecated.
Key takeaways
- Current server is built into Elastic Agent Builder.
- Available tools follow the authorizing Elastic user’s permissions.
- Requires a current supported Elastic deployment and applicable subscription.
What is Elastic Agent Builder MCP?
Built-in Elastic Agent Builder endpoint that exposes authorized Agent Builder tools to external MCP clients. MCP standardizes how a compatible client discovers and invokes tools, but it does not make those tools safe automatically. The client, server, credentials and upstream service remain separate trust boundaries.
What tools does it expose?
- List and call tools configured in Elastic Agent Builder.
- Access Elasticsearch-backed retrieval or actions represented by those tools.
- Use the endpoint from external compatible MCP clients.
- Apply Elastic user permissions to tool access.
The exact catalog can change by release, account, enabled feature or server configuration. Inspect the live tool list and JSON schemas before enabling it. A descriptive tool name is not an authorization control, and a read-sounding operation can still reveal sensitive metadata.
What is a safe first test?
Create one read-only Agent Builder tool over a non-production index and authorize a dedicated user that can only read that index. Verify that unrelated tools and indexes are absent.
Use a test account or project, allow only the required tools and record the client configuration, server version and arguments. Verify the result directly in the upstream service. Add write tools only after read-only behavior, authentication expiry, error handling and audit logs have been reviewed.
What data and credentials can it access?
The endpoint can expose Elastic data and Agent Builder tool outputs available to the authenticated Elastic user. The scope depends on configured tools, index privileges and deployment settings.
Credentials should be supplied through the documented OAuth flow, a secret manager or a restricted environment variable, never pasted into prompts or committed to source. The upstream account should expose only the resources required for the pilot.
Which permissions should you grant?
- A dedicated Elastic user with read access to one test index.
- Only the Agent Builder tool needed for the pilot.
- No cluster administration or broad index wildcard privileges.
Prefer project-scoped, read-only or restricted tokens. Where the server offers tool filters, combine them with upstream authorization rather than treating filtering as the only control. Separate development and production identities and rotate test credentials after the evaluation.
What should a security review cover?
- Use Elastic role-based access control as the primary boundary.
- Protect search results and observability data in traces.
- Do not deploy the deprecated standalone server as the current solution.
Assume tool results can contain prompt injection or hostile content. Keep approval gates in application code for financial, administrative, destructive or public actions. Apply network restrictions, timeouts, output-size limits and audit logging at the host or gateway layer.
What are the main limitations?
- Requires Elastic 9.2 or a supported Serverless environment according to current documentation.
- Subscription requirements apply.
- The server exposes configured Agent Builder tools, not every Elasticsearch API directly.
This is a documentation-based profile checked on 2026-10-04; Anavem did not connect the server or test it against a live account. Tool catalogs, transport support, pricing, licensing and authentication methods can change. Verify the current first-party documentation before installation.