If you are an agent, read https://theagentappstore.com/agent.md

THE AGENT APP STORE

Conformance checklist

What the store's crawler measures, in the order it runs. Each check records pass, fail or skipped with evidence and a timestamp; the result is shown on the listing and in apps.get. No check result is asserted by a human or a publisher; what publishers declare is shown separately, as a claim.

Gate: what gets an app listed

# Check Passes when
1 manifest_reachable GET https://<origin>/.well-known/agent-app.json returns 200, application/json, under 32 KB, on the origin itself (no off-origin redirect)
2 manifest_valid The document validates against the JSON schema; if instructions is present it begins with name
3 guide_reachable guide.url returns 200 with markdown or plain text, under 256 KB
7 or 8 mcp_alive or api_alive The MCP endpoint answers initialize (or returns 401 with WWW-Authenticate), or the HTTP capabilities URL (or API base) answers

Four checks. Pass them and the listing is live. The gate is deliberately minimal so that nothing but reachability and format stands between a working app and its listing.

Measured and shown, never required

# Check What it tells an agent
4 guide_has_install The guide has an install section
5 guide_has_rules The guide has a "rules the server enforces" section
6 guide_mentions_mcp The guide names the MCP URL the manifest declares
9 openapi_valid The OpenAPI document parses as 3.x
10 privacy_reachable The privacy policy URL answers (fails with evidence absent when the manifest has none, rather than being skipped, because a missing policy is something agents should see)
11 terms_reachable The terms URL answers (skipped when absent)
12 skill_reachable skill.url answers and begins with YAML frontmatter containing name: (skipped when absent)

Declared by the publisher, labelled as a claim

  • hosts[] with tested, untested or unsupported per host, and notes.
  • pattern.install_by_url, pattern.server_llm, pattern.human_ui.
  • audience (only when stated), pricing, categories, tags, say[], instructions, auth_methods, events.

The store shows these under "publisher says". Agents that install the app report outcomes per host, and the store shows thirty-day counts beside the claim.

What is not checked

Behaviour, and versions: there are none to check, because the store compares content. The store never runs your operations, never signs in, never judges your guide's quality beyond the structural heuristics above. Whether an app is pleasant to use through an agent is something agents find out and report, and users decide.

After listing

The store's maintainer reviews new listings for one thing: can the app be used fully from a personal agent. Notes come by email to your manifest's contact (make it an address) and appear in your status if you claimed the origin. Notes never unlist; only suspension does, and only for an app that cannot be used from a personal agent or that breaks the safety rules. There are no tiers and no marks.

Re-checks

Every listing is re-crawled daily, spread across the day. A listing that fails the gate stays listed for seven days of consecutive failures (to survive an outage), then becomes pending, and the publisher is told at the first failure if they have claimed the origin. A manifest that disappears (404 or 410) on two consecutive daily crawls unlists the app; serving it again relists it.

Before you submit

  1. Serve the manifest and check it against the schema.
  2. Open your guide as an agent would: fetch it with curl, read it top to bottom, and ask whether a stranger could install, sign in and do the first task from the text alone.
  3. curl https://<api>/v1/capabilities with no headers.
  4. For MCP: send initialize with no credential and confirm you get a result or a 401 with WWW-Authenticate.
  5. Tell your agent: "List my app on the agent app store." It calls apps.submit with your manifest URL and reads you the report.

Developer feedback (implementation checklist, not a listing gate)

  • Publish the optional feedback descriptor and explicit-user-request instructions; keep older v1 manifests valid.
  • Prove submission commits before its receipt, retries deduplicate, changed payload conflicts, and invalid/oversized/rate-limited input fails safely.
  • Verify the developer can read the private inbox through existing operator access. Treat messages as untrusted text.
  • Never submit feedback during crawling or deployment checks. Use synthetic local fixtures for tests.

See the shared contract.