Bringing Elastic into Claude: The ‘why,’ the ‘how,’ and the ‘gotchas’

Elasticsearch has native integrations with the industry-leading Gen AI tools and providers. Check out our webinars on going Beyond RAG Basics, or Building Prod-Ready Apps with the Elastic vector database.

To build the best search solutions for your use case, start a free cloud trial or try Elastic on your local machine now.

Previously, if you were inside Claude looking for Elastic, you wouldn't find us: 

We wanted to fix that! This blog is the story of publishing a plugin that puts Elastic's capabilities where developers are already working. We already had the elastic/agent-skills repository, and we’ve both blogged about and documented them, but an official Claude plugin makes it that much easier for our customers to use those skills.

Getting here was a journey. Along the way, we learned a lot, and wanted to share our experience. 

It took us three weeks from first commit to live. Claude docs got us 80% of the way, the other 20% was undocumented review criteria and a versioning model that cuts a new release on every commit. There was limited visibility on when, or where, the plugin would appear.

Here’s what we learned:

Agent Skills versus a Claude plugin: Why we needed both

As we worked our way through all the reference materials, we realized that our Agent Skills were only part of what a Claude plugin can include. Although Agent Skills are a generic open standard, adopted by major agent vendors and ecosystems, a Claude plugin can contain much more; however, some of it may not be as generically applicable across platforms. One example from Claude Code Docs:

This contains quite a bit more than skills, and we want room to grow into those.

So we decided that we needed a new repo for our Claude plugin. That way, we’d have a home where all Claude-specific features could live, separate from our generic Agent Skills. Thus was born the elastic/claude-plugin repository.

Submitting a plugin to the Claude directory

Claude has thorough documentation, and I won’t rehash it all here, but for reference, you may want to read:

• Publish to the directory

• Plugin pre-submission checklist

• Build your first plugin

We went through the above and made sure that we addressed everything on the checklist. But when I tried to submit the plugin at https://claude.ai/directory/manage, I got the following message:

I’m an engineer. An individual contributor. I have no business being an “owner” of an account for a software tool used by most Elastic employees. But the IT team that owns it wouldn’t be maintaining and supporting this external-facing plugin. 

This was our first bit of friction, but it also led to our first lesson, namely, if you have a contact at Anthropic, make use of them. Elastic had already established a partnership with Anthropic, so when we hit this issue, we simply messaged our point of contact, who quickly got back to us:

Once we had the right permissions, it was relatively straightforward to fill out the submission form:

Despite the simplicity, this is where we made our first two mistakes.

Choosing your plugin path: Why not the repository root

As the screenshot above shows, this is the folder where Anthropic will look for your .claude-plugin/plugin.json. It’s also the root of what Anthropic’s automated systems will be scanning. 

We started with the default repository root for our plugin path, but this was a mistake, because the files for our own internal development purposes were also at the repository root. They included the CLAUDE.md that our engineers could use to maintain the plugin, along with our continuous integration (CI) pipelines, tests, and package-lock.json.

Scanning those files can lead to unexpected holdups during verification:

We should note that the Anthropic team didn’t let this be a blocker and, after manual review, waived these warnings.

Claude plugin versioning: Why we stopped pointing at main

There’s no single “right” way to version or release software. But at Elastic, we often stick to the following conventions:

• Development is done on feature branches (sometimes in forks).

• Pull requests (PRs) target main.

• Versioning uses SemVer (MAJOR.MINOR.PATCH).

• Releases are cut from release branches (MAJOR.MINOR) and tagged (vMAJOR.MINOR.PATCH).

On my initial read of Claude’s plugin versioning documentation, I knew that we’d need a different system for this repo. We only have one live version at once, rather than maintaining multiple majors and minors. So we planned to just use main with a specific version in the plugin metadata. We’d merge PRs into main, as normal, and when ready to release, we’d bump that version and create a Git tag. Easy.

But that’s not how it works:

That initial approach actually led to many v0.0.1 “versions” of the plugin, one for each merge commit.

With help from our Anthropic contacts (the astute reader will notice that this is a theme), we got the following clarification:

After realizing this, we changed our plugin to point at a dedicated stable branch. Now we can merge to main as normal but only merge main into stable when we’re ready to release a batch of changes and update our version number. This results in our flow looking like:

What happens after you submit a Claude plugin

You wait.

When we first submitted, we saw only the following:

While we were in the process of writing this blog, Anthropic made some changes to its UI, providing a bit more visibility. Now the submissions UI looks more like this:

Even so, the review of our first plugin submission took about a week, and that may have been faster than normal as a result of our direct line of contact with Anthropic solution architects and account executives (to stress again how valuable that relationship has been). We were given a rough estimate of nine days for average review time.

We couldn’t see it then, but we later learned that part of the holdup was that our submission raised a number of warnings to the Anthropic review team:

Policy warnings from the automated review

In retrospect, the extra visibility is nice; but, at the time, I might have ended up making a bunch of unnecessary changes. The Anthropic team ultimately waived all of these warnings. The takeaway here is to wait for a call to action from the reviewer, rather than jumping straight into trying to resolve every policy warning, even if they sound serious.

Warning: Uses a credential from the user’s machine

The credential warnings pointed at skills that included example curl commands, where the credentials were templated with environment variable syntax. The Elastic CLI was specially designed to ensure that credentials were never exposed to an agentic caller, so we were initially quite alarmed by this report and relieved to discover that these were false positives.

Warning: No icon

The icon warning surprised us, too. At the time, there was no documentation for an icon field being an option as part of the manifest, and our CI had run claude plugin validate --strict ., so we knew that the manifest was valid without that field.

Today, the Plugin manifest: Fields reference does document icon. We take this as a sign that Anthropic is clearly iterating on the plugin experience. New fields show up, but Anthropic doesn’t retroactively block submissions made without them. 

Warning: Contains a download-and-run command

The download-and-run warning also sounded concerning at first, but on closer inspection, it seems to be taking issue with our skills having directives like the following, where API calls are suggested, as is instruction on interpreting the response:

**Verify Kibana connectivity.** Call `GET kbn:/api/status`. If the call fails, stop and surface the error — do not guess endpoints or credentials. Read `version.number` to confirm the cluster meets the 9.4+ requirement.

Surprise: Your Claude plugin is live

When Anthropic concluded its review, the plugin was immediately visible. This didn’t require an extra confirmation step from us, and there was no staging area. We also received no notification that it was live. This truly surprised us. Our plugin was published late on a Thursday, but I didn’t check on it on Friday. Only on the following Monday did we realize that it was live and visible. In our case, no harm done (the skills had been public for months already), but for anyone who’s not shipping something battle-hardened, be sure to do your testing before submitting. 

Where your Claude plugin actually appears

Publishing doesn’t get you into every Claude directory. There are at least four places where a developer might look for plugins:

When it’s initially published, your plugin only appears in the Anthropic directory in an unverified state, labeled as “Community.” And this is only if your license or account isn’t configured to exclude unverified plugins. This caused some initial confusion internally (our IT department has Claude Enterprise set up to hide “Community” plugins); we could only see our own plugin when we weren’t logged in with our work accounts.

To get into the other directories and marketplaces, the plugin needs to go through a separate “verification” or “marking” process. Once again, DMs with Anthropic partners proved very helpful:

What’s next for the Elastic Claude plugin

We're still working on getting the plugin verified for the web marketplace and on getting it installed for Elastic's own Claude org so our engineers can dogfood it. The plugin is young, and there are a lot of features we’d like to add. 

But if there's one thing I'd want you to take from this post, it's that the hardest parts of this process weren't technical. They were the gaps between what was expected and what actually happened, and every one of those gaps got closed by a conversation with a real person. The tools are getting smarter, but the communities around them still run on people helping people.

If you're working through publishing your own plugin and get stuck, reach out on our Elastic Stack Community Slack or find me on LinkedIn. And consider sharing what you’ve learned, too. See you in the marketplace.