We cut 40% of our MCP tools to get into Claude’s connector directory

Agent Builder is available now GA. Get started with an Elastic Cloud Trial, and check out the documentation for Agent Builder here.

When OAuth 2.1 landed for the Elastic Agent Builder Model Context Protocol (MCP) server, I told my product manager I could get us into Claude's connector directory in "one, two days, tops." It took weeks. Anthropic's pre-submission checklist sent us back to rework our catalog. The Anthropic review tested every one of our exposed tools. By the end, our catalog for Elasticsearch projects had shrunk from 36 tools to 22 (a reduction of around 40%) and we’d touched more than 100 tools total. 

The Elastic Cloud Serverless connector is now live in Claude’s connector directory. In this blog, we cover what the submission review actually checks, the surprises to plan for, and why we’re evolving our MCP architecture.

What Anthropic’s MCP connector checklist requires, beyond the spec

Although it feels like everybody and their mother has an MCP server in the marketplace today, in reality, chat products need to be extremely careful about which MCP servers they (implicitly or explicitly) certify for their customers’ use. While the worst-case scenario with a bad MCP server is obviously a security breach, the more benign (but annoying) scenario is that your agent gets confused by unintentional context poisoning. 

Therefore, it was unsurprising to find that Anthropic had a very clear pre-submission checklist for connector authors.

That checklist ended up illuminating two required changes, in particular. Before we could submit to be included in the Claude connector directory, we needed to implement:

1. Universal adoption of tool annotations.

2. Separation of read tools from write tools.

MCP tool annotations: What each hint tells the client

Although our MCP server had been stable for nearly a year, optional portions of the MCP specification were growing in adoption. Accordingly, Anthropic had been raising the bar for its connector requirements, beyond what the MCP spec alone requires. 

The biggest example of this was with tool annotations.

If you’re chatting in pretty much any agent harness, you’re probably familiar with UX elements like this:

In the beginning, most agent harnesses seemed to default to “ask” for any tool, no matter what it did or what the risk level was. This could quickly get annoying when you first added a new bundle of tools and, instead of getting to work, you had to click Allow, Allow, Allow ad nauseam. 

To address this, tools can “hint” what their risk level is. Are they read-only tools? Do they perform destructive actions? Do they allow access to external systems?

interface ToolAnnotations {
  title?: string;
  readOnlyHint?: boolean;
  destructiveHint?: boolean;
  idempotentHint?: boolean;
  openWorldHint?: boolean;
}

With these hints, agent harnesses can apply more reasonable starting defaults. For example, these are two tools from our Elastic Cloud Serverless connector in the Claude UI:

For the above screenshot, I didn’t customize the initial settings. But we can see (on the right) that the Get Document by ID tool defaults to “Always allow,” but the Generate Workflow tool defaults to “Needs approval.” With this communicated immediately by the protocol in a tool annotation, Claude won’t make me approve tool calls that aren’t worth interrupting me for.

Adding these hints to every Elastic tool wasn’t hard, but it was time consuming over the full breadth of 100+ tools across all three solution lines, especially when it’s very important to be nuanced and accurate in the hint values.

Why Anthropic wants read tools separated from write tools

{  
   "readOnlyHint": true,  
   "destructiveHint": true
}

What does that even mean? If I’m confused, an agent will be, too.

That’s why Anthropic’s guidance is to separate read tools from write tools. This allows each tool to be explicit in its purpose and to avoid labeling ambiguity, both in its hints and in its name and description. 

One of the most common early issues with MCP integrations was tool explosion, and many vendors started trying to limit the size of their tool catalogs by condensing multiple related features and functions into single tools with control-flow parameters. Anthropic docs provide an apt example:

Don’t ship a catch-all api_request tool with a method parameter.

This avoids a tool having one execution mode that’s read-only but another that’s destructive, with no clear way (hinting or otherwise) to communicate those nuances to an MCP client.

But like many others, Elastic had a number of tools that had adopted this pattern early on to keep our catalog smaller. Each of these needed to be discussed with the owners and either modified, split up, or removed from our MCP server. For example, our cases.attachments got split into cases.get_attachments and cases.manage_attachments, but our execute_connector_sub_action tool is now excluded from our MCP catalog entirely.

Submitting an MCP connector: What Anthropic asks for

Once we felt that we finally had our MCP server and tool catalog up to snuff, we went to submit our connector. I’ve already blogged about how access to the submission portal may need some privilege adjustments, but another unexpected hurdle for submitting a Claude connector was that our account needed a live connection to a custom MCP server of the same type.

We’d known from Claude’s submission docs that we’d need to provide Anthropic reviewers with access to a test instance:

Test-account setup and access instructions detailed enough for a reviewer to connect to your server and run its tools…

This made for a slightly awkward experience when Elastic’s Claude Enterprise account needed to connect a custom MCP server to an Elastic Cloud Serverless project titled Anthropic MCP Test. Again, this required partnering with our IT admins to both set up this MCP server and to not expose it to our whole enterprise.

This may not be a universal experience, since the Elastic Agent Builder MCP server is one of the rarer kinds of MCP server, where every customer deployment has its own embedded server.

Remember this; we’ll return to the customer-specific configuration topic later in this blog.

What the MCP connector review actually checks

The above had implied that Anthropic would do some testing of our MCP server on its end, and this is further confirmed in the Submit a connector documentation: 

Anthropic scans your submission automatically for policy compliance...

This, it turns out, is an understatement.

Claude’s submission process didn’t require an evaluation dataset or an in-depth testing script. It just asked for a sandbox environment, a link to documentation, and three example prompt use cases. From that, the Anthropic team reviewed every single one of our MCP tools and provided feedback (positive and negative) on many of them. It checked the tools for spec compliance and security (expected) but also reflected on:

• The language we used in tool and parameter descriptions.

• The implications of metadata embedded in tool response values.

• The token efficiency of any given tool.

• The efficacy of expected error messages.

• The value of listing tools when their functionality isn’t available for a particular license or product flavor.

What the Verified badge review adds

Funnily enough, while drafting this blog, an autonomous reviewer shamed me for not having carefully read Claude’s verification docs before now, particularly:

Anthropic may then escalate listings flagged as highly useful to Claude users to Verified review, which is higher touch and slower, and in which reviewers run a functional test of each tool. That escalation is assessed automatically. There’s no separate application for the Verified label, and you don’t need to take any action.

Nevertheless, since it surprised us, I think it bears repeating here: if you submit to the Claude connector directory and are hoping for that verification badge, expect a high degree of scrutiny.

Although this level of review wasn’t expected, it honestly was very helpful. Not only did it result in a Verified badge, it caught several legitimate bugs [1][2][3][4], prompted a change around how we should better automate a quality bar for all our tool definitions [5], and forced us to confront the fact that not every tool needed to be published in our MCP server [6][7][8][9][10][11][12][13]. 

To quantify the volume of adjustments: our Elasticsearch projects started with 36 published tools. At time of writing, one exposes 22 tools by default. 

After development: Approval and publishing

Our valiant developers have overcome every obstacle. They’ve updated our MCP spec compliance, and they’ve reevaluated the spirit of every tool to confirm its fit and granularity. Descriptions have been tweaked, directives softened, docs links injected, error messaging elaborated. At long last, the Anthropic team grants coveted approval…

And the connector is immediately available to the public. No final Publish button. No confirmation. Not even a notification. We went to the directory management page one day and saw: 

This would’ve been a cause for celebration, if every early user wasn’t seeing:

Remember how I said earlier that the topic of customer-specific configuration would come back up?

The submission form had asked if each customer needed to provide its own URL, and we had provided an explicit set of OAuth credentials to test with. However, we hadn’t clarified or confirmed that the customer-specific configuration form would prompt for a client_id and client_secret pair, retrieved from Kibana. This first published version only displayed:

We only mention this as a cautionary tale to any other connector publishers whose MCP servers, like Agent Builder and Snowflake, are part of the minority that have a non-static URL and require individual OAuth configuration. Be sure to capture this requirement in advance in your submission notes. Happily, the Anthropic team was able to expedite a fix for us, and a few days later, the form looked like:

Connecting multiple MCP server instances in Claude Enterprise

Another hiccup we’ve faced with this connector is that Claude Enterprise accounts can only connect a single instance of a connector from the directory. This isn’t a great fit with MCP servers that have different configurations (instances) for different use cases.

Although these MCP servers are usually talked about as “per-customer,” that doesn’t necessarily mean “per-account” or “per-business.” For example, a single business entity might reasonably have three Elastic Cloud Serverless projects:

1. Dev

2. QA

3. Prod

Each of these would have its own distinct Agent Builder MCP server and would need its own OAuth configurations. And that means that you wouldn’t be able to connect all three as connectors from the directory, because once you have one, there’s no option to add another:

In order to have additional connection to your Elastic resources, you (or an admin) would have to add a custom connector:

This results in your additional connections looking like:

If your MCP server has a static URL, almost none of this applies to you.

What’s next: A single MCP server URL at mcp.elastic.co

If you’re not familiar, “Progress, SIMPLE Perfection”, is part of Elastic’s Source Code (our company values). Cherry-picking two lines from this one in particular:

Perfection is not a destination. … An Elastic that moves is an Elastic that survives, thrives, and stands the test of time.

It’s clear to us that the Agent Builder MCP server and its tool catalog are not the final form of our agentic interface. So rather than double down on past decisions, we’re actively looking to learn from this experience and improve our architecture.

I’m happy to be able to use this blog to tease that an mcp.elastic.co centralized, universal, MCP server is coming. We don’t have a concrete date for it yet, but stay tuned as the calendar flips to ’27. We hope to use it as an opportunity to improve on several structural issues that this Claude connector integration illustrated for us:

• One MCP Server URL (mcp.elastic.co) that can be baked into plugins, directories, and marketplaces and that doesn’t require explicit configuration.

• Client ID Metadata Document (CIMD) support for our OAuth flows, so that client_id and client_secret pairs aren’t necessary to explicitly configure, either.

• A new tool catalog that simultaneously:

• Avoids tool sprawl.

• Provides clear tool annotations and separation of responsibility.

• Exposes even more features (Elastic Cloud APIs, here we come!).

Is the Agent Builder MCP server going away?

For folks currently using the Agent Builder MCP server: not to worry, it’s not going away. There may have been some friction to get here, but we’re still thrilled to have made an incremental improvement to Elastic’s agentic interface. Now, our MCP server is that much closer to where you, our users, are.

We’d love to hear your feedback on where we are and where we’re going. Reach out on our Elastic Stack Community Slack or find me on LinkedIn.