You and your AI agent shouldn't be using curl: Introducing the Elastic CLI and Agent Skills
Elastic CLI reaches every Elasticsearch, Kibana and Cloud API from one command, and it's what Elastic Agent Skills run on. Input is validated against a JSON Schema before anything leaves your machine, and API keys stay in your OS keychain.
Get hands-on with Elasticsearch: Dive into our sample notebooks in the Elasticsearch Labs repo, start a free cloud trial, or try Elastic on your local machine now.
The Elastic CLI gives you one command for every public Elastic API: Elasticsearch, Kibana, and Elastic Cloud's control plane, including Serverless projects. Learn elastic es search, and you already know how elastic kb data-views list behaves. It's built to be driven by an AI coding agent as easily as by you, so every command takes JSON in and out and validates input against a JSON Schema before sending anything. Plus, it exits with a code that an agent can branch on. Administrators control which commands run at all, and API keys go to your OS keychain, never into a large language model (LLM) transcript. Our Agent Skills now run on it. The command line interface (CLI) is in technical preview today.
Start a free Elastic Cloud Serverless trial or log in to Elastic Cloud to follow along, and install the CLI via npm:
npm install -g @elastic/cliDesigning the Elastic CLI for people and AI agents
A useful side effect of building flexible tools for developers is that they’re more useful to AI agents, too. It’s also the tool that our Agent Skills now use to get things done, closing the loop that we opened in March 2026, when we said that a CLI for agent workflows was coming.
The CLI gives every public API across Elasticsearch, Kibana, and Elastic Cloud one shape: the same flags, input and output conventions, authentication method, and failure mode. Consistency is the ergonomic feature; everything else is built on it.
Agents need the same thing, only stricter. An agent won’t know how to craft a valid CLI command or notice if a tool “feels” wrong; it needs output it can parse and input it can validate before sending, along with failures it can branch on. Agents are now a first-class interface to Elastic, alongside people, whether they live on the platform or in your editor and terminal. Agent Skills, and now the CLI, are how we serve the second kind, so those needs are built into the core of the CLI rather than tacked on.
JSON input and output for every command
Agents love structured text, and almost every Elastic API already speaks JSON, so first-class JSON support was a hard requirement. Developers who are quick with a jq query will be equally satisfied.
JSON output: Any command, like
elastic versionandelastic es indices delete ..., supports--json, which prints JSON-parseable output to stdout and nothing else. Failed commands print{"error": {"code": "...", "message": "..."}}to stderr.JSON input: Every command that takes input accepts JSON on stdin or via
--input-file. Every top-level key in that JSON also works as a CLI argument, and inline arguments take precedence, so you can keep a big request body in a file and tweak a value or two per invocation.JSON Schema as
--helpoutput: Pass--help --jsonto any command, and it prints a valid JSON Schema for its input, which also feeds nicely into codegen tools.elastic cli-schemaprints the whole command tree.
Exit codes that an AI agent can branch on
Agents loop on exit codes as much as they do over stdout. All failure modes are distinguishable from success, even if stdout and stderr are never read.
Safety rails: Keychain storage, allow lists, and validation
No model uses tools perfectly 100% of the time, so an agent-friendly CLI should provide safety rails wherever possible.
Contexts and secret storage: Connection details live in named contexts in
~/.elasticrc.yml,kubectl-style; switch with--use-context. API commands never take credentials as flags.elastic config context addwrites API keys to your OS keychain (macOS, Linux, Windows) and leaves a$(keychain:...)reference in the YAML;$(env:...),$(cmd:...), and$(file:...)work, too. Creating a Serverless project with--save-aswrites its credentials straight to the keychain and never prints them, so nothing leaks into logs or LLM transcripts.Allowlists/blocklists: A
commands.allowed(orcommands.blocked) list in the config file, globally or per context, ensures that only the commands an administrator wants are runnable.
commands:
allowed:
- version
- stack.es.search
- stack.es.esql.*Validation: Every command has a JSON Schema, so inputs are validated before any request is sent. Add
--dry-runto any command that takes input, and it validates and exits without sending anything.Confirmation: Destructive commands prompt in a terminal. In a noninteractive session, where agents live, they refuse to run without
--yesand say so in a structured error.Sanitization: Index, field, and pipeline names have length limits and forbidden characters.
elastic sanitize index-name '<value>'(andfield-name,pipeline-name, …) prints a version stripped of anything invalid.
Keeping API responses inside an agent's context window
Elastic APIs return a lot of data, and an agent’s context window is finite. Three controls help keep unnecessary text out of the context window:
Field masks:
--output-fieldstakes a comma-separated list, with dot notation for nested fields.
elastic es info --output-fields 'name,version.number'
# {
# "name": "serverless",
# "version": { "number": "9.5.0" }
# }String templates: For total control,
--output-templatetakes a mustache-style template.
elastic es info --output-template 'ES version: {{ version.number }}'
# ES version: 9.5.0- Command profiles:
--command-profileserverless (ordefault_profile: serverlessin your config) hides Elastic Cloud Hosted commands and the Elasticsearch namespaces that don’t exist on Serverless. That means less to scroll past and less for an agent to guess wrong. It’s the profile we recommend for agents.
Control | What it does | Syntax | When to use |
Field mask | Returns only the fields you name, using dot notation for nested fields |
| You want valid JSON back, just less of it. This is the default choice for agents parsing structured output. |
String template | Renders the response through a mustache-style template |
| You need one value in a specific shape, for a shell variable, a log line, or a prompt. |
Command profile | Hides commands and namespaces that don't apply to your deployment |
| You want a smaller command surface so an agent has less to scroll past and less to guess wrong. This is recommended for agents. |
Helpers for bulk ingest, scroll search, and msearch
Some of Elasticsearch’s most popular APIs have a learning curve, so elastic es helpers wraps them:
scroll-search: Stream a large result set as NDJSON with paging handled for you.bulk-ingest: Ingest from a file, a directory, or stdin (NDJSON, JSON arrays, or CSV) with streaming, batching, concurrency, and retries.msearch: Send multiple searches in one request.watch: Print new documents from an index to stdout as they’re indexed. This is great for piping into logging tools.
elastic es and elastic kb are aliases for elastic stack elasticsearch and elastic stack kibana. If we don’t ship a command you need, elastic extension create scaffolds one for you.
Searching Elastic docs from the terminal
If you or your agents don’t know which API to use, elastic docs search (plus docs read and docs ask) searches Elastic’s documentation from the terminal, returning Markdown or --json. These are experimental. You’ll see a warning until you pass --accept-experimental, so explore, but don’t script against them yet.
Shell completion for Bash, Zsh, and Fish
Autocomplete hooks are available for Bash, Zsh, and Fish, and they always respect your commands.allowed or commands.blocked policy.
How Elastic Agent Skills use the CLI
Agent Skills teach an AI coding agent how an Elastic expert approaches a job; for example, which cluster health field is the verdict or how to stage a reindex so it doesn’t fall over. They capture process and judgment but not transport. A skill that embeds curl with an auth header has hard-coded a hostname, key, and runtime, and it breaks when any of those change.
So our skills now use a universal format that runs unchanged in any runtime that can execute the elastic CLI, including Claude Code, Codex, Cursor, and GitHub Copilot. The body refers to operations in HTTP shorthand (GET /_cluster/health, POST /_query), and an operations table at the end binds each to a CLI command. That table is the only place transport appears:
HTTP API (shorthand) |
|
|
|
|
|
|
|
Every universal skill also inherits a blunt preamble; that is, use the CLI, don’t guess credentials, don’t call the HTTP API directly, and never ask the user to paste an API key into the chat.
The two halves need each other. The skill supplies the expertise that the model doesn’t have, and the CLI supplies a way to act on it that’s validated, credential-safe, and scoped by your allowlist. Tell your agent to spin up a Serverless project and load products.csv into it, and the provisioning skill creates it with --save-as. The ingest skill dry-runs a mapping and loads with elastic es bulk, and the Elasticsearch Query Language (ES|QL) skill writes a query that parses on the first try. Every step returns JSON, exits non-zero on failure, and can only do what your policy allows.
Skills for Elastic Cloud onboarding and provisioning, Elastic Workflows, and Kubernetes investigation are available today. Skills for Elasticsearch query, ingest, reindex, and index design, plus Kibana dashboards and alerting, are close behind.
What’s in the Elastic CLI technical preview, and what’s next
The preview covers all public Elasticsearch Serverless, Kibana Serverless, and Elastic Cloud APIs. Hosted-only 9.x Elasticsearch API coverage is nearly 100%, and hosted-only 9.x Kibana APIs will be added soon.
We’re actively planning more developer experience work, including broader coverage for all supported stack releases, more helpers for common workflows, more skills in the public catalog, and loading the same skills into agents that run on the Elastic platform itself. What shapes that list is hearing how you and your agents use the CLI. Tell us what’s awkward and what’s missing, along with what you’d automate next.
Install the Elastic CLI and Agent Skills
The Elastic CLI is available now on npm (Node.js 22+). Install it and the skills together:
npm install -g @elastic/cli # or: npx -y @elastic/cli --help
npx skills add elastic/agent-skillsThen, add a context and check it:
elastic config context add prod --es-url https://<project>.es.us-east-1.aws.elastic.cloud --es-api-key <KEY>
elastic statusEven without a project, you can start a free Serverless trial in about a minute, with no credit card. If you already have a project, log in and create API keys for Elastic Cloud and your Elasticsearch clusters. Before pointing an agent at anything real, start with a trial project, a read-only key, and a scoped commands.allowed list. Be sure to take five minutes to read the security notes in the skills repo.
Replace all those curl commands in your Bash scripts, and add some usage instructions to your AGENTS.md. Then let your agent’s skills work efficiently and accurately with our APIs. Let us know what you think, and don’t hesitate to open an issue if you find a bug or if your use case isn’t well supported. Your feedback directly shapes what we build next.
Elastic CLI and Agent Skills resources
How helpful was this content?
Related Content

Migrating 1,100 files to Redux Toolkit v2 without freezing the Kibana monorepo

Kibana Dashboards API: A stable contract for every panel type, tested by 50+ teams before GA

One command. Natural language. Your Elasticsearch data, straight to the terminal.

Introducing unified API keys for Elastic Cloud Serverless and Elasticsearch
