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

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: Universal adoption of tool annotations. 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; }Annotation What it tells the client readOnlyHint The tool does not modify its environment. destructiveHint The tool may perform destructive updates to its environment. idempotentHint Calling the tool repeatedly with the same arguments will have no additional effect on its environment. openWorldHint This tool may interact with an “open world” of external entities. 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_requesttool 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 ca