Submit & review

Submitting your plugin to the Allternit directory has five steps: verify your domain, pass the automated scan, fill in the listing, submit for review, and publish once approved.

​

1. Verify your domain

You prove you control your MCP server’s host by serving a token at a fixed path.

1. Request a token for your host. It is issued once, per developer and host, and re-requesting replaces the old one.
   POST /v1/developers/domain-tokens
   { "host": "mcp.example.com" }
   
   The response is { "token": "allternit-verify-<48 hex characters>" }. Allternit stores only a SHA-256 of the token, so save it when you receive it.
2. Serve the token as plain text at:
   https://mcp.example.com/.well-known/allternit-apps-challenge
   
   The response must be 200, with the token as the body. A single trailing newline is allowed and nothing else. If you send a Content-Type, it must be text/plain.
3. Ask Allternit to check it:
   POST /v1/developers/domain-tokens/check
   { "host": "mcp.example.com" }
   

The check runs on Allternit’s servers. It uses HTTPS on the default port only, does not follow redirects, times out after 5 seconds, and reads at most 4 KB. It refuses IP-address hosts and hosts that resolve to private, loopback, or link-local addresses. A redirect is a failure, so serve the file directly from the host you verified.

​

2. Automated scan

The scan connects to your server and lints what it finds. Errors block submission. Warnings and info items do not block it, but a reviewer sees them.

​

Server

​

Tools

​

Resources and CSP

​

3. The listing

​

Test cases

Reviewers run these prompts, so write them as a user would.

• Positive cases are prompts where your app should be used, with what you expect to happen. Cover different tools, and include one where your View appears.
• Negative cases are prompts where your app should stay out of the way: a request another app or the model itself should handle, or a similar-sounding request outside your scope. Say why the app should not trigger.

Fill all eight in. The form is rejected with form.positive-tests or form.negative-tests if any prompt or expected result is empty.

​

Reviewer credentials

Give the reviewer an account that has representative data and does not need two-factor codes you cannot supply. Credentials are stored encrypted, separately from the listing and the package. They are excluded from the public listing and from exports, and only a reviewer with admin access can read them.

​

4. Submit

Submitting sends the form, the package, and a snapshot of your server’s tool metadata from the scan. The listing moves to in_review.

​

5. Publish when ready

Approval does not publish your listing. After it is approved, you choose when to publish it, so you can line it up with your own launch. Publishing is only possible from approved.

​

Changes after approval

Your server’s tools are part of what a reviewer approved. Once a listing is approved, the approved snapshot of your tool metadata stays live and later changes are held until a reviewer approves them:

• Held: a new tool, and any change to an existing tool’s title, description, inputSchema, annotations, or _meta. Also any change to a ui:// resource’s MIME type or its _meta.ui (CSP, permissions).
• Applied immediately: a removed tool or resource, because it only narrows what users can do.

While a change is held, users continue to see the approved metadata. When you submit an update to an approved listing, the new form and package are also held until approval. Design for this: batch tool changes, ship annotation fixes together with the code that needs them, and expect a re-review when a tool’s behavior changes.

​

Errors from the submission API