A connector directory listing is a security review with a form attached. The reviewer on the other side is reading for the same things a customer's security team reads for, with less context and less patience, and the answer is either a listing or a rejection with a short reason.
One caveat before the checklist. Directory criteria are published by each vendor, they differ between vendors, and they change. Read the current requirements for the specific directory you are submitting to, on the day you submit. What follows is the part that has been stable across the ones we have worked with, and it is almost entirely the part you cannot add after the build.
The server has to be remote and hosted
A directory lists something its users can connect to. That rules out a server distributed as a local process launched over stdio. You need a remote server on the Streamable HTTP transport, at a stable HTTPS URL you operate, with the operational obligations that implies: uptime, TLS, versioned deployments, and a way to roll back.
If your current server is a local binary that a developer runs beside the client, submission is not a paperwork exercise. It is a hosting project, and the authorization design changes with it. We cover the transport-side work in securing the Streamable HTTP transport.
Authorization has to be the specification's, not yours
The part of a submission that fails most often is authorization, because a server that works for one developer usually works on a shared secret in a config file.
What a directory expects to find, and what a client will exercise automatically:
- An unauthenticated request returns
401with aWWW-Authenticateheader pointing at your protected resource metadata document (RFC 9728). See serving protected resource metadata. - That metadata names one or more authorization servers, each with reachable authorization server metadata (RFC 8414).
- The authorization code flow with PKCE completes end to end from a client the directory operator controls, not just from your test client.
- Access tokens are bound to your server through a resource indicator (RFC 8707), and your server validates the
audclaim on every request. See validating token audience. - The server never accepts a token minted for something else, and never forwards the token it received to a downstream API.
A useful test: hand a colleague nothing but the server URL and ask them to connect with a stock MCP client. If they need a secret from you, a directory reviewer will need one too, and that is a rejection.
Client onboarding has to have an answer
A directory brings clients you have never heard of. Either your authorization server supports dynamic client registration (RFC 7591), or you publish another documented route for a new client to obtain credentials. Choosing one closed is fine and often the right enterprise answer; having neither is not. The trade-offs, including what to do when your security team will not enable open registration, are in registration and client identity.
Scopes a user can read
The consent screen is the one piece of your authorization design an end user actually reads. If it says api.full_access, the reviewer sees a server that hands an agent everything the person has.
Have a scope catalog with names that describe an action and an object, request the minimum at connect time, and elevate with an insufficient_scope challenge when a specific tool needs more. Directory reviewers do compare your requested scopes against what your tools plausibly need, and an obvious mismatch reads as carelessness. See designing OAuth scopes.
The tool surface is documentation now
Once listed, your tool list is public product surface. Before you submit:
- Every tool has a name and description that says what it does, on what data, and what it will not do.
- Read tools and write tools are distinguishable without reading the code, and the write list is short and deliberate.
- Destructive tools have a confirmation step the model cannot set for itself.
- No tool takes a user or tenant identifier as an argument. Identity comes from the validated token, every time.
- Inputs are bounded and validated server-side; outputs are bounded and treated as untrusted text.
- Nothing is left in from development: no debug tool, no admin escape hatch, no half-finished tool marked experimental.
That last line is worth a pass of its own. Prototype tools that never got removed are the cheapest rejection to avoid and the easiest one to earn.
Data handling in writing
Submissions ask what the connector does with data, and the answer has to match the server's behaviour. Have written, and true:
- What categories of data tools can read and write.
- Where the server runs and where data is stored, if it is stored at all.
- Retention for logs and audit events, and who can read them.
- Which subprocessors see request data, including any model provider.
- A privacy policy and terms at stable public URLs.
If a tool returns personal data, say so plainly. Reviewers are not surprised by personal data; they are unimpressed by a form that omits it and a tool schema that reveals it.
A support contact that is a person
Directories require a contact for security reports and user problems, and they use it. A monitored mailbox with an owner, a stated response window you can actually meet, and a documented path for a vulnerability report. If you also publish a security contact record for the domain, the two should agree.
Versioning and change
Your listing is not a one-time event. Plan for what happens when the specification revision you implement is superseded, when a tool changes shape, and when a scope is added. Decide in advance which changes require a re-submission under the directory's rules, keep a changelog, and keep the protocol version your server advertises current enough that clients do not have to negotiate downward.
This is the ongoing part of the work, and it is the part most teams have no owner for. Someone has to read the specification changelog and the directory requirements every few weeks and say what it means for your server.
Submit against a record, not a hope
Before you fill in the form, run the pre-handover test sequence against the deployed server and write down the results: the authorization rejections, cross-tenant attempts through every tool, injected instructions in every output field, replayed sessions. Then assemble the same material a customer's security team would ask for. If your evidence pack is complete, the submission form is mostly transcription, and the follow-up questions have answers already.
A rejection is not usually a security failure. It is usually a server that was built to demo and submitted before anyone decided how identity flows through it.
Where we fit
We prepare and submit directory listings as part of an MCP server engineering engagement, and we assess submission readiness in an MCP security audit when a server already exists or a submission came back. If your server is already remote, already on specification-conformant OAuth 2.1, and already has its data handling written down, you probably do not need us for the form. Read the current criteria and submit.