Claude Connector Directory Submission: Requirements, Annotations, and How to Pass Review (May 2026)

TL;DR: Claude Connector Directory review is stricter than a basic MCP smoke test. You need a production-ready remote MCP server, MCPB desktop extension, or MCP App, plus clear docs, a privacy policy where required, test credentials, and support contact details. Every tool needs a title and either readOnlyHint or destructiveHint. Read and write actions should be separate tools. Authenticated connectors should register https://claude.ai/api/mcp/auth_callback, and MCP Apps need 3 to 5 listing screenshots. Test locally with sunpeak, then test the same server as a custom connector in Claude before you submit.

You built a Claude Connector. It runs locally, the tools return useful results, and you want it listed in the Connectors Directory so users can install it from Claude instead of pasting a custom MCP URL.

The submission path is still straightforward, but the review bar has moved. Claude now documents connector submission in the Claude developer docs, and the review criteria cover more than tool annotations. Reviewers look at tool design, authentication, privacy, allowed external links, MCP App assets, documentation, support, and whether the connector behaves well when every tool is called.

What You Can Submit

Claude currently accepts three connector shapes for directory review:

• Remote MCP servers, which are internet-hosted servers that provide tools, data, resources, and prompts to Claude.
• Desktop extensions, which package a local MCP server as an MCP Bundle, or MCPB, for Claude Desktop.
• MCP Apps, which are MCP servers that render interactive UI elements in Claude through the MCP Apps extension.

That matters because the submission form and review assets differ by type. Remote MCP servers and MCP Apps use the MCP directory submission form. Desktop extensions use the desktop extension submission form. MCP Apps also need screenshots for the directory listing because reviewers and users need to see the app response, not just the tool schema.

If your server only runs from npm, PyPI, or a local command, package it as an MCPB or bundle it through the supported directory paths. A raw local package is not the same thing as a directory-ready connector.

The Submission Package

Before you open the form, gather the material reviewers will need:

• Server name, URL, tagline, description, and use cases
• Auth type, transport protocol, read/write capabilities, and connection requirements
• List of tools, resources, and prompts, including human-readable tool names
• Confirmation that every tool has a title and safety annotations
• Public documentation, or private review docs that will be public by launch
• Privacy policy and data handling notes
• Support contact or support channel
• Test credentials with sample data if the connector requires an account
• Branding assets, logo, favicon details, and screenshots for MCP Apps
• Allowed link URIs if your app calls ui/open-link

This is not busywork. The submission form asks for these details because reviewers test the connector as a user would. If the test account has no realistic data, search tools look broken. If docs only explain installation, reviewers do not know which prompts to try. If a write tool lacks a clear description, Claude cannot safely decide when to call it.

Tool Metadata Is a Hard Gate

Every submitted tool needs a title and the right safety annotation. Use:

• readOnlyHint: true for tools that only read data, such as search, get, list, fetch, and query tools.
• destructiveHint: true for tools that modify data, delete data, send messages, create temporary files, make side-effecting requests, or trigger workflows.

In a sunpeak project, put the annotations in your tool config:

import type { AppToolConfig } from 'sunpeak/mcp';

export const tool: AppToolConfig = {
  resource: 'user-profile',
  title: 'Get User Profile',
  description: 'Retrieve the authenticated user profile.',
  annotations: { readOnlyHint: true },
};

For a write tool:

export const tool: AppToolConfig = {
  resource: 'send-message',
  title: 'Send Message',
  description: 'Send a message to the selected channel.',
  annotations: { destructiveHint: true },
};

Do not hide read and write behavior behind one catch-all tool. A tool named api_request with a method parameter that accepts GET, POST, PATCH, and DELETE will fail review. Split it into read-only tools and write tools. If the write surface is broad, split those tools further by action, such as create, update, delete, and send.

Tool names must be 64 characters or fewer, and descriptions need to say what the tool does and when it should be called. Do not use tool descriptions to instruct Claude to prefer your product, skip other tools, read hidden instructions from external content, or behave in ways unrelated to the tool function. Reviewers call the tools and compare the behavior to the descriptions.

OAuth and Callback URLs

If your connector needs authentication, Claude expects OAuth 2.0. Authless servers are supported, but credentials in URL query parameters are not. User-pasted bearer tokens are not currently supported for Claude connectors.

For hosted Claude surfaces, register this redirect URI:

https://claude.ai/api/mcp/auth_callback

Claude Code is different because it is a native client. It uses a loopback redirect on localhost or 127.0.0.1 with an ephemeral port, for example:

http://localhost:3118/callback

If you support Claude Code, your authorization server needs to accept loopback redirects with the port component ignored. Claude also sends PKCE with S256, so your authorization server metadata should advertise code_challenge_methods_supported: ["S256"].

Pure machine-to-machine client_credentials OAuth is not supported as a user-facing connector flow. Even if Anthropic holds client credentials for your directory listing, each user still completes a consent flow. If your authorization server does not support Dynamic Client Registration, Claude supports Client ID Metadata Document flows and Anthropic-held client credentials as alternatives.

Privacy Policy and Data Handling

Remote MCP servers should provide a stable privacy policy URL in their public docs and submission. Local connectors packaged as MCPB have specific privacy-policy placement requirements:

• Add a “Privacy Policy” section to README.md.
• Add a privacy_policies array to manifest.json.
• Use manifest_version 0.2 or later.
• Link to HTTPS privacy policy URLs.

The policy should say what data you collect, how you use it, where and how long you store it, whether you share it with third parties, and how users can contact you. Missing or incomplete privacy policies can stop review immediately.

Also avoid collecting conversation data that your tool does not need. Claude’s review checklist calls out overcollection, querying conversation memory, and querying user files as review problems.

Allowed Link URIs for MCP Apps

MCP Apps can ask the host to open external links through ui/open-link. For directory submission, declare the destinations you own.

You can submit:

• HTTPS origins, such as https://app.example.com
• Custom URI schemes for apps you publish, such as myapp:

Only the scheme and hostname are matched for HTTPS origins. Paths, ports, and query strings are ignored. Subdomains are not implied, so list https://app.example.com and https://docs.example.com separately if you use both.

If you omit allowed link URIs, your connector can still open links, but users see a confirmation prompt each time. Do not list third-party domains or URI schemes you do not own.

MCP App Screenshot Requirements

MCP Apps are now a first-class submission type for the directory, but they need extra listing assets. Prepare:

• 3 to 5 PNG screenshots
• At least 1000px width
• Cropped to the app response only
• Paired prompt text for each screenshot
• No video or GIF assets

Screenshots should show real states that reviewers can reproduce with your test account. Include a useful empty state only if users will genuinely encounter it. For an approval workflow, show the list, the detail state, and the confirmation state. For a dashboard, show the filtered view and a drill-down state. This helps reviewers understand what the connector does beyond the text returned to the model.

The MCP Apps extension defines the portable pattern behind these UIs: tools reference ui:// resources, hosts render those resources in sandboxed iframes, and the view communicates with the host through JSON-RPC over postMessage. A good Claude Connector still needs text output for clients that do not support UI, because MCP Apps add richer UI on top of normal MCP tools.

Documentation That Helps Reviewers

Your docs should let someone unfamiliar with your product test the connector in 10 minutes. Include:

• A short explanation of what the connector does
• Setup steps and auth requirements
• At least three prompts that exercise different tools
• Expected outcomes for those prompts
• Known limitations
• Privacy policy link
• Support contact

For tools that accept freeform paths, query strings, or request bodies, link to the API docs or name the target API in the tool description. A description like “Makes a request to the API” is too vague. Purpose-built tools that call one fixed endpoint do not need the same API-docs link, but they still need narrow descriptions.

Testing Before You Submit

Use three test layers.

First, validate protocol behavior locally. The official MCP Inspector is useful for protocol compliance, auth flow checks, and schema inspection. sunpeak inspect adds replicated ChatGPT and Claude MCP App runtimes, so you can test iframe rendering, host context, display modes, themes, simulations, and Playwright tests without burning host credits.

npx sunpeak inspect --server http://localhost:8000/mcp

For a new sunpeak project:

npx sunpeak new sunpeak-app
cd sunpeak-app
pnpm dev

The dev server starts a local inspector at http://localhost:3000 and an MCP server at http://localhost:8000. Use simulations to pin tool inputs, tool results, error states, and server tool mocks. Those fixtures are what make CI tests useful instead of dependent on a live account with changing data.

Second, test the real connector runtime. Claude documentation says there is no separate staging environment. Add your server as a custom connector from Settings > Connectors > Add custom connector. If the server is local, expose it through a tunnel such as Cloudflare Tunnel or ngrok, keep auth enabled, and shut the tunnel down when you finish.

Third, test the reviewer account. Create a fully populated test account with real sample records, documents, tasks, or whatever your connector manages. Then run every documented prompt from that account. Empty accounts make useful tools look broken.

Common Review Problems

Fix these before you submit:

• One tool mixes safe and unsafe HTTP methods behind a method argument.
• A tool is missing title, readOnlyHint, or destructiveHint.
• Tool descriptions are vague, promotional, or instruct the model how to behave.
• OAuth discovery works in your browser but fails from Claude because a WAF blocks Anthropic egress.
• Your token endpoint only accepts JSON instead of application/x-www-form-urlencoded.
• The connector returns generic 500 or 400 errors without actionable messages.
• The server returns huge unfiltered payloads instead of scoped, paginated results.
• The test account has no sample data.
• The MCP App opens external links but you did not declare owned allowed link URIs.
• MCP App screenshots include the whole chat prompt instead of only the app response.

Claude reviewers run functional tests against every tool and run a policy compliance scan. Treat the checklist like a release gate, not a paperwork step.

Submission Checklist

Before you fill out the form:

• Server is production-ready and reachable over HTTPS
• Streamable HTTP transport is supported where possible
• OAuth is implemented if the connector accesses user data
• Hosted callback URL is registered: https://claude.ai/api/mcp/auth_callback
• Claude Code loopback redirects work if you support Claude Code
• Every tool has a title
• Every tool has readOnlyHint or destructiveHint
• Read and write actions are separate tools
• Tool names are 64 characters or fewer
• Tool descriptions are narrow, accurate, and non-promotional
• Tool responses are scoped, useful, and not oversized
• Errors include actionable messages
• Privacy policy is published and complete
• MCPB packages include privacy policy entries in README and manifest
• Documentation includes setup, auth, examples, expected outcomes, and support
• Allowed link URIs are listed for ui/open-link
• MCP App screenshots are ready if your connector includes UI
• Test credentials are fully populated with sample data
• Server was tested with MCP Inspector or sunpeak inspect
• Server was tested as a custom connector in Claude
• Logs can trace OAuth, initialize, tool call, and resource-read failures

If you have not built the connector yet, start with the Claude Connectors tutorial. If you already have an MCP server, use sunpeak to add repeatable local tests before you submit. Directory review is much easier when you can replay the exact states reviewers will hit.