Home Docs Claude Documentation 25 Sep 2026

One change · claude-docs

Connector pre-submission checklist changedconnectors/building/review-criteria

Nearest release: v2.1.283, published under an hour after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.

Upstream edited this page at 25 Sep 2026 18:00 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 25 Sep 2026 18:07 UTC.

Upstream edited 25 Sep 2026 18:00 UTC

Recorded here 25 Sep 2026 18:07 UTC

Lines+52added

Lines−30removed

From line 1 where the diff opens

First seen 14 Aug 2026 this site's first read of the page

Recorded edits2to this page, all time

# Connector pre-submission checklist ## Design tools that pass review ### Avoid prompt-injection patterns ## Server behavior and scope ### Functional quality ### API ownership ### Unsupported use cases ## Gather what to include with your submission ## Test before you submit ## Understand how Anthropic reviews connectors ## Next steps # Pre-submission checklist ## Tool design ## Avoid prompt-injection patterns ## Functional quality ## API ownership ## Unsupported use cases ## Submission requirements ## Before you submit

The whole hunk

from line 1, old and new numbered

lines

from line 1

1# Pre-submission checklist

1# Connector pre-submission checklist

3> What Anthropic reviewers test, so you can pass on the first try

3> Check your MCP connector against what Anthropic reviewers test, including tool design, prompt-injection patterns, and functional quality, before you submit.

5When you submit a server, it is automatically scanned for policy compliance and, by default, listed in the directory as a [community connector](/docs/connectors/verification). Anthropic may then escalate listings flagged as highly useful to Claude users to verified review, which is higher touch and slower; reviewers run a functional test of each tool. This escalation is assessed automatically, and you do not need to take any action. Every server in the directory must meet the criteria on this page, whichever label it carries. The label is a quality signal shown to users; it does not change how your connector runs once connected. This page surfaces the most common rejection reasons so you can self-correct before submitting. For the full legal text, see the [Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy).

5This checklist covers what Anthropic checks on an MCP connector submitted to the directory, organized around the most common rejection reasons so you can correct them before you submit. It's for connector authors preparing a [directory submission](/docs/connectors/building/submission). For the full legal text behind these criteria, see the [Software Directory Policy](https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy).

7## Tool design

7<Note>

8 If you're submitting a plugin, see the [plugin pre-submission checklist](/docs/plugins/pre-submission-checklist) instead.

9</Note>

810

11Work through [tool design](#design-tools-that-pass-review), [server behavior](#server-behavior-and-scope), and [what to include with your submission](#gather-what-to-include-with-your-submission), then [test every tool](#test-before-you-submit) before you open the portal. [How Anthropic reviews connectors](#understand-how-anthropic-reviews-connectors) covers the Community and Verified labels.

13## Design tools that pass review

15Tool design covers how your tools are split, named, annotated, and described. These rules apply to every tool your server exposes.

917### Separate read and write tools

1018

11A single tool that accepts both safe HTTP methods (GET, HEAD, OPTIONS) and unsafe methods (POST, PUT, PATCH, DELETE) is rejected. Do not ship a catch-all `api_request` tool with a `method` parameter.

19A single tool that accepts both safe HTTP methods, such as GET, HEAD, and OPTIONS, and unsafe methods, such as POST, PUT, PATCH, and DELETE, is rejected. Don't ship a catch-all `api_request` tool with a `method` parameter.

1220

13Split into a read-only tool and one or more write tools. Ideally, split write operations further by action type (create, update, delete). Documenting safe versus unsafe operations within one tool's description does not satisfy this requirement—the operations must be in separate tools.

21Split a catch-all tool into a read-only tool and one or more write tools. Ideally, split write operations further by action type: create, update, and delete. Documenting safe versus unsafe operations within one tool's description doesn't satisfy this requirement. The operations must be in separate tools.

1422

1523### Reference API docs in custom query tools

1624

17If a tool accepts freeform endpoint paths, query strings, or request bodies that the caller constructs, its description must include a link to or explicit name of the target API. For example: "Queries the Slack Web API—see [https://api.slack.com/methods](https://api.slack.com/methods)". A description like "Makes a request to the API" with no further context fails.

25If a tool accepts freeform endpoint paths, query strings, or request bodies that the caller constructs, its description must include a link to or the explicit name of the target API. For example, "Queries the Slack Web API, see [https://api.slack.com/methods](https://api.slack.com/methods)" passes. A description like "Makes a request to the API" with no further context fails.

1826

19This applies only to custom query tools. Purpose-built tools that call a fixed endpoint internally do not need an API docs reference.

27The API docs requirement applies only to custom query tools. Purpose-built tools that call a fixed endpoint internally don't need an API docs reference.

2028

2129### Provide tool annotations

2230

23Every tool must include a `title` and the applicable hint—`readOnlyHint: true` for read-only tools, `destructiveHint: true` for tools that modify or delete data. These determine auto-permissions in Claude: read-only tools can run without per-call confirmation; destructive tools always prompt.

31Every tool must include a `title` and the applicable hint: `readOnlyHint: true` for read-only tools, and `destructiveHint: true` for tools that modify or delete data. These determine auto-permissions in Claude. Read-only tools can run without per-call confirmation, and destructive tools always prompt.

2432

2533### Keep tool names short

2634

from line 38

3038

3139Each tool description should state precisely what the tool does and when to invoke it. The description must match the tool's actual behavior.

3240

33## Avoid prompt-injection patterns

41### Avoid prompt-injection patterns

3442

35Tool descriptions are rejected if they:

43Describe what the tool does, and don't tell Claude how to behave. Tool descriptions are rejected if they:

3644

3745* Instruct Claude to call external software or tools the user didn't request

3846* Interfere with Claude calling other tools

from line 48

4048* Contain hidden, obfuscated, or encoded instructions

4149* Tell Claude to behave in ways unrelated to the tool's function, attempt to override system instructions, or promote products and services

4250

43Describe what the tool does. Do not tell Claude how to behave.

51## Server behavior and scope

4452

45## Functional quality

53Beyond individual tools, reviewers check how the server behaves when called, whose APIs it calls, and whether its use case is one the directory accepts.

4654

47* Every tool must return a successful response when called with valid parameters. Generic errors ("Internal Server Error", "Bad Request" with no detail) fail review.

48* Validate inputs and return actionable error messages rather than silently accepting invalid data.

49* Keep responses reasonably sized for the task. Do not return a full database dump when a summary was requested.

50* Do not collect conversation data beyond what the tool needs for its function.

51* Do not query Claude's memory, chat history, conversation summaries, or user files.

55### Functional quality

5256

53## API ownership

57* Every tool must return a successful response when called with valid parameters, and generic errors such as "Internal Server Error" or "Bad Request" with no detail fail review

58* Validate inputs and return actionable error messages rather than silently accepting invalid data

59* Keep responses reasonably sized for the task, and don't return a full database dump when a summary was requested

60* Don't collect conversation data beyond what the tool needs for its function

61* Don't query Claude's memory, chat history, conversation summaries, or user files

5462

63### API ownership

5565Your server must call your own first-party APIs, or APIs you legitimately proxy. The MCP server domain should match your service.

5666

57## Unsupported use cases

67### Unsupported use cases

5868

59Connectors that do the following are not accepted:

69Connectors that do the following aren't accepted:

6070

6171* Transfer money, cryptocurrency, or other financial assets

62* Generate images, video, or audio via AI models (design tools that produce diagrams, charts, or UI mockups are allowed)

72* Generate images, video, or audio through AI models

6373

64## Submission requirements

74Design tools that produce diagrams, charts, or UI mockups are allowed.

6575

66* **Test credentials** are required and must be a fully populated account.

67* **Allowed link URIs** are recommended if your server calls `ui/open-link`. Declared HTTPS origins and custom URI schemes open without a confirmation prompt; anything else still prompts the user. See [Allowed link URIs](/docs/connectors/building/submission#allowed-link-uris).

68* **Public documentation** is required by your publish date—a blog post or help-center article is sufficient. You can share docs privately with Anthropic during review.

69* **Plugins** must link a public GitHub repo; closed-source is not accepted.

70* **MCPB** open-source and "spec will evolve" clauses in the [Software Directory Terms](https://support.claude.com/en/articles/13145338-anthropic-software-directory-terms) are required and not waivable.

76## Gather what to include with your submission

7177

72## Before you submit

78Alongside the server itself, a submission carries credentials, links, and terms acknowledgments that reviewers check:

7379

74Run `claude plugin validate` on plugins. For MCP servers, exercise every tool through the [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector) and as a [custom connector in Claude](/docs/connectors/building/testing).

80* **Test credentials**: required, and they must be for a fully populated account

81* **Allowed link URIs**: recommended if your server calls `ui/open-link`. Declared HTTPS origins and custom URI schemes open without a confirmation prompt, and anything else still prompts the user. See [Allowed link URIs](/docs/connectors/building/submission#allowed-link-uris)

82* **Public documentation**: required by your publish date. A blog post or help-center article is sufficient, and you can share docs privately with Anthropic during review

84## Test before you submit

86Exercise every tool through the [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector) and as a [custom connector in Claude](/docs/connectors/building/testing) before you submit. The portal's **Test & launch** step asks you to confirm you've done this.

88## Understand how Anthropic reviews connectors

90When you submit a server, Anthropic scans it automatically for policy compliance and, by default, lists it in the directory as a [Community connector](/docs/connectors/verification). 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, and you don't need to take any action. Every server in the directory must meet the criteria on this page, whichever label it carries. The label is a quality signal shown to users and doesn't change how your connector runs once connected.

92## Next steps

94* [Submit a connector](/docs/connectors/building/submission): what the developer portal asks for at each step

95* [Connector verification](/docs/connectors/verification): what the Community and Verified labels mean to the people who install your connector

96* [Manage your directory listing](/docs/connectors/building/managing-your-listing): track review status and reviewer feedback after you submit

7597