Connect Claude to Elasticsearch

Inspect indices, mappings and cluster health, then search, count and aggregate documents. Toolspoke puts 12 of its actions behind one MCP endpoint that Claude, Cursor, and Codex all speak.

Connect View pricing

Connection: Provider REST API
Authentication: API key
Actions exposed: 12
Cost per call (typical): 1 credit
Adapter: Maintained by Toolspoke

Connected in three steps

1
Install Elasticsearch
Open the marketplace in your workspace, add Elasticsearch to the project your agents work in, and it appears on the gateway immediately.
2
Connect the credential
Authenticate with api key. Where to get one, and what it has to be able to reach, is the next section.
3
Point your agent at the gateway
Give your client one address, https://toolspoke.com/mcp. Claude Code takes it as a command, Claude and Claude Desktop add it as a custom connector, and Cursor, Codex and VS Code each read it from a config file of their own.

.mcp.json

{
  "mcpServers": {
    "toolspoke": {
      "type": "http",
      "url": "https://toolspoke.com/mcp"
    }
  }
}

One block covers every tool you have installed. Elasticsearch shows up in the client as soon as your policy allows it, and so does everything else you install later.

Where the address goes, per client

Claude Code: Run it in your project, then /mcp to sign in
claude mcp add --transport http toolspoke https://toolspoke.com/mcp
Claude and Claude Desktop: Settings, then Connectors, then Add custom connector
https://toolspoke.com/mcp
Cursor: ~/.cursor/mcp.json, or .cursor/mcp.json for one project
{ "mcpServers": { "toolspoke": { "url": "https://toolspoke.com/mcp" } } }
Codex: ~/.codex/config.toml
[mcp_servers.toolspoke] url = "https://toolspoke.com/mcp"
VS Code: .vscode/mcp.json, or the MCP: Add Server command
{ "servers": { "toolspoke": { "type": "http", "url": "https://toolspoke.com/mcp" } } }

What Elasticsearch asks for

API key. You provide it once, when you install the connector. Toolspoke encrypts it at rest and decrypts it only for the length of a single call, and the gateway attaches it to the outbound request itself, so it is never part of the arguments an agent sends.

Cluster URLRequired: The Elasticsearch endpoint root, with its port. Elastic Cloud shows it under the deployment's connection details; a self-managed cluster is usually port 9200. This is the Elasticsearch address, not the Kibana one.; https://my-deployment.es.us-central1.gcp.cloud.es.io:443
API keyRequired: Paste the `encoded` value the create-API-key call returns, or the key shown in Kibana under Stack Management → API keys. Give it `read` and `view_index_metadata` on the indices it should reach, plus cluster `monitor` - that is what makes the install read-only at the server rather than only here.; VnVhQ2ZHY0JDZGJrUW…

What Claude can do in Elasticsearch

12 actions, each one declared and named by the connector rather than discovered at runtime. A workspace policy grants a person all of them, a hand-picked selection, everything on the read side, everything on the write side, or none.

Reads: 12Reads
Writes: 0Writes
Destructive: 0Destructive

Reads

Fetches data and changes nothing.

server_info
Report the cluster name and the Elasticsearch version. Call this first to confirm the URL and the API key work - it takes no arguments and reads nothing about the data.
cluster_health
Report the cluster's health: the green/yellow/red status, node counts, and how many shards are active, relocating, initialising or unassigned. Ask for the indices level to get the same breakdown per index.
list_indices
List indices with their health, document count and size on disk. The index argument is a pattern, so * lists everything and logs-* lists one family. Sizes are in bytes so they sort correctly.
list_aliases
List index aliases and what they point at, including which index an alias writes to. Use it when a query names something that turns out not to be an index.
list_nodes
List the nodes in the cluster with their roles, heap and memory use, CPU and load average. Use it to tell a cluster problem from a slow query.
get_mapping
Return the field mappings of one index or index pattern: every field with its type and any sub-fields. Call this before writing a query - whether a field is text, keyword or date decides which query works on it.
get_settings
Return one index's settings: shard and replica counts, refresh interval, analysers and lifecycle policy. Use it when an index behaves differently from its neighbours.
search
Run a query DSL search and return the matching documents. Call get_mapping first so the field types are right. Keep `size` small - the documents come back in full. Sorting on a field replaces the relevance score, so ask for a sort only when you want one.
count_documents
Count the documents matching a query without returning any of them. Use it to size a result before searching, and to check a filter is selective enough.
aggregate
Run aggregations and return only the buckets, never the documents. This is how you get counts by term, histograms over time and statistics on a field. `size` is fixed at 0, so no document bodies come back.
get_document
Fetch one document by its id. Use it after a search has given you an id, when you want the whole document rather than the fields the search returned.
validate_query
Check whether a query is valid against an index and, when it is not, say why - without running it. Use it to debug a query that returns an error, and to check an expensive query parses before paying for it.

What it will not do

Enforced by the gateway rather than left to convention, which is why each of these can be stated flatly.

It cannot call anything else: The 12 actions above are the whole of it. A call to any other name is refused before it reaches Elasticsearch rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time.
It only reads: Every action here reads. Nothing this connector can do changes anything in Elasticsearch.
It reaches no further than your credential: Toolspoke holds no access to Elasticsearch of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either.
It never hears from Elasticsearch: Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in Elasticsearch. An agent has to ask.
It does not smooth over provider limits: Toolspoke does not retry, queue or back off around Elasticsearch's own rate limits. A call that Elasticsearch refuses comes back to the agent as a failed call.

Before you connect it

What can Claude do in Elasticsearch?

12 named actions: 12 that only read. They include server_info, cluster_health and list_indices. Nothing outside that list is reachable: the connector declares each operation by name rather than proxying whatever an agent asks for.

What credentials does the Elasticsearch connector need?

API key. The connector asks for cluster url and api key. Values are encrypted at rest and attached to the outbound request by the gateway, so they are never part of the arguments an agent sends and never reach the audit log.

Does the Elasticsearch connector work with Cursor and Codex, or only Claude?

Any client that speaks MCP, and every one of them gets the same 12 actions. There is a single address, https://toolspoke.com/mcp. Claude Code adds it with claude mcp add --transport http, Claude and Claude Desktop take it as a custom connector in settings, Cursor reads it from .cursor/mcp.json, Codex from ~/.codex/config.toml, and VS Code from .vscode/mcp.json. Each of them signs in to the gateway itself, so there is no key to paste.

What does the Elasticsearch connector not do?

The 12 actions above are the whole of it. A call to any other name is refused before it reaches Elasticsearch rather than forwarded on, and connecting your account does not add to the list: it is fixed by the connector, not discovered at run time. Every action here reads. Nothing this connector can do changes anything in Elasticsearch. Toolspoke holds no access to Elasticsearch of its own. Every call carries the credential you stored and nothing besides, so whatever that credential cannot reach, this connector cannot reach either. Nothing is pushed to it. There is no webhook, no subscription and no polling, so this connector cannot notice by itself that something changed in Elasticsearch. An agent has to ask. Toolspoke does not retry, queue or back off around Elasticsearch's own rate limits. A call that Elasticsearch refuses comes back to the agent as a failed call.

Can I limit which actions an agent can call?

Yes, in two places. The project switches Elasticsearch's actions on and off one at a time, for everyone in the project at once, and the screen groups them by read, write and destructive so turning off everything that deletes is one click. An individual agent key can then be narrowed further, to particular toolkits in a project and to particular actions in a toolkit. Whatever it was granted, a key never reaches a project its owner cannot.

What gets recorded when an agent calls Elasticsearch?

Every attempt, with the agent that made it and the person that agent belongs to, the full request payload, the response payload, the status, the duration, and the credits spent. Values whose key names a secret are masked out before the record is shown to anyone. An operation the connector marks as not retained never has its response body written at all, so the gateway keeps no second copy of what was read.

More database connectors

Browse all of them