What Agent Review Actually Rejects — and How to Pass on the First Submission

What Agent Review Actually Rejects

Every listing goes through two stages before it's live: a static scan, then human review. Both fail closed. Anything that can't be verified as safe is rejected rather than allowed through with a note, which means the useful mental model when authoring is write for the gate, not for the happy path.

Here is the complete rejection taxonomy, what triggers each, and how to check it yourself first.

flowchart TD
  S["Submission"] --> Scan["Static scan — automated"]

  Scan --> R1["❌ Action host outside<br/>its credential's allowlist"]
  Scan --> R2["❌ Credential slot with<br/>no allowed_hosts"]
  Scan --> R3["❌ Schema validation failure"]
  Scan --> R4["❌ Code bundle fails scan<br/>or sandbox acceptance"]

  Scan -->|"clean"| HR["Human review"]
  HR --> R5["❌ Prohibited content<br/>under marketplace policy"]
  HR --> R6["❌ Listing claims the<br/>manifest doesn't support"]
  HR -->|"clean"| Live["Listed"]

  style Scan fill:#1f2937,color:#fff
  style HR fill:#1f2937,color:#fff

1. An action points at a host outside its credential's allowlist

The single most common automated rejection.

The scan resolves every auth_ref to its credential slot and checks that the slot's allowed_hosts covers the host in that action's URL. Per action — not per agent.

// action
{ "url": "https://api.eu.acme.com/v2/orders", "auth_ref": "acme_key" }

// slot
{ "ref": "acme_key", "allowed_hosts": ["api.acme.com"] }

api.eu.acme.com is a sibling of api.acme.com, not a subdomain of it. Rejected.

Worth noting that the scan is doing you a favour here: had it passed, the credential would never have attached at runtime and every call would have returned 401 with no obvious cause.

Check yourself: list every action URL's host, list every slot's allowed_hosts, and confirm each action's host appears in the list of the slot it references. Ten lines of eyeballing.

2. A credential slot with no allowed_hosts

A credential with no declared audience can be attached to any outbound request. There is no safe default to fall back on, so the slot is rejected outright.

// rejected
{ "ref": "vendor_key", "label": "Vendor API key", "type": "secret" }

Check yourself: every object in credential_slots has an allowed_hosts array, and every array is as narrow as the agent allows — exact hosts, not parent domains.

3. Schema validation failures

The unglamorous bucket, and the easiest to eliminate. What actually shows up:

One kind won't fail here but also won't do what you expect: autonomous-agent is a reserved roadmap value with no distinct runtime behaviour, so a submission that sets it is silently coerced to mcp-tool rather than rejected. It isn't offered as a choice anywhere, and you shouldn't author it — treat your doer as mcp-tool.

Check yourself: the pre-delivery checklist in the manifest cookbook covers every row of this table.

4. A code bundle fails the static scan or sandbox acceptance

Code bundles carry a second surface: the code itself is scanned, and the sandbox has to be able to accept the bundle.

What tends to surface here:

• Committed secrets. A real key in a config file, a test fixture, or git history.
• Hosts the code reaches that aren't in the derived allowlist. Telemetry endpoints, error trackers and a dependency's home-phone are the usual suspects, because nobody thinks of them as "network access".
• An entrypoint the runtime can't resolve. A path that doesn't exist, or an export that isn't there.
• A runtime the sandbox can't provision. A version hint that resolves to no image.
• Build-time network the build isn't permitted. Build-time egress is admin-managed per agent, so an unusual registry needs to be raised during review rather than assumed.

Check yourself: scan your own repo for secrets, grep for every hostname the code contains, and confirm each one is in the README's network section. See repo to code agent.

5. Prohibited content under the marketplace policy

Human review, and not negotiable. Read the marketplace policy before building rather than after — this is the only rejection category where the fix might be "don't build this."

6. The listing claims something the manifest doesn't support

This is the category creators are least prepared for, because everything validates and the agent genuinely works. Review is also checking whether the description matches the artifact.

What gets sent back:

• A tool description broader than its action. "Manages your calendar" on a tool that only reads free/busy.
• Annotations that don't match behaviour. readOnlyHint: true on a tool that writes is the classic, and it has teeth: clients use that annotation to decide what to run without asking.
• targets listing clients the agent can't work in. Especially chatgpt on a local doer, which is not a supported configuration.
• A tagline promising an outcome the tools can't produce. "Automatically resolves support tickets" on an agent that can only read them.
• Invented listing metadata. Categories, tags or taglines added to look complete rather than because they're accurate. Omitting them is fine — the submit wizard collects what's missing.
• example_prompts that don't exercise the agent. One generic line, or prompts referencing tools that don't exist. The requirement is 1–5 prompts showing genuine use, and reviewers do read them.
• A system_prompt that claims capabilities the tools don't have. Instructing the model to "check the customer's payment history" when no such tool exists produces confident fabrication.

Check yourself: read the listing copy and the manifest side by side, and for each claim ask which tool delivers it. Any claim without a tool behind it is a rejection.

The pre-flight, in ten minutes

Work top to bottom. Each line maps to a rejection above.

Credentials

• Every slot has allowed_hosts
• Every auth_ref resolves to a slot covering that action's host — checked per action
• Hosts are exact, not parent domains
• No orphaned slots, no dangling refs
• No secret in url, headers, body_template, env, description or any listing field

Schema

• name 3–80; system_prompt 50–20,000; ≤40 tools; 1–5 example_prompts
• Every {param} defined in input_schema
• Every action URL is https
• secret_leak_scan not written at all
• Doer authored as kind: mcp-tool (never autonomous-agent, which is coerced away)
• kind / delivery / exec / targets mutually consistent
• llms values from the allowed six

Behaviour

• annotations match what each tool does — nothing that writes is read-only
• approval: "human" on irreversible or spending tools
• idempotent: false on anything with side effects
• rate_limit on every external call
• No tool needs confirmation inside its own execution

Listing

• Every claim in the copy has a tool behind it
• targets limited to clients actually supported
• Nothing invented to fill space
• example_prompts show real usage

Code bundles

• No secrets in the repo or in git history
• Every host the code reaches is in the README network section
• Entrypoint path and export resolve
• .env.example complete and commented

After a rejection

The rejection tells you which check failed. Fix that specific thing and resubmit — it's cheap, and one round trip is entirely normal for a first listing with credentials in it.

What's expensive is resubmitting repeatedly without reading the reason, usually because the failure looks arbitrary. It generally isn't: the host-coverage check in particular is catching a bug that would otherwise have surfaced as an unexplained 401 in front of a paying buyer.

One thing to settle before you submit at all: the slug you choose at the Basics step is permanent. Everything else is editable across versions. Pick it deliberately.

FAQ

What is the most common reason an agent listing is rejected? An action whose destination host isn't covered by the allowed_hosts of the credential slot its auth_ref points to. The check runs per action, so a slot that covers one tool's host but not another's fails.

Does a human review every agent? Yes. The static scan runs first and rejects automatically, then a human reviews what passes. Both stages fail closed, so anything that can't be verified as safe is rejected rather than approved with a caveat.

Can I disable a check for my own agent? No. secret_leak_scan is mandatory and always runs, allowed_hosts is required on every credential slot, and guardrails may only ever be tightened, never loosened.

Why was my agent rejected when the manifest validates? Human review also checks that the listing's claims match the manifest — tool descriptions broader than their actions, annotations that don't match behaviour, targets including unsupported clients, or a tagline promising an outcome the tools can't produce.

How long does a resubmission take? Fix the specific check named in the rejection and resubmit. One round trip is normal for a first listing that involves credentials; the check that failed is usually catching a bug that would have surfaced later as a runtime error.

Can I change my agent's slug after submitting? No. The slug chosen at the Basics step is permanent. Other listing fields can be edited across versions.

Related: The MCP Agent Manifest Cookbook · Audience-bound credentials · From GitHub repo to hosted code agent