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

THE AGENT APP STORE

Prompts for building, checking and listing an agent app

The intended way to build an agent app is to tell your agent to build it. These are the prompts to give it. Each one is complete on its own: paste it into your agent as the first message of a session, replace the parts in angle brackets, and let the agent work. Each prompt tells the agent where the standard lives, so it reads the current rules rather than relying on what is quoted here.

The standard is served at https://theagentappstore.com/standard and lives in this repository under docs/agent-apps/; the template is under template/. While the store is not yet deployed, the agent reads the files from the repository instead.

1. Build a new agent app

Use this when you have an idea and nothing else. Fill in the three brackets. The result is a deployed app that passes the store's checklist.

Build me an agent app called <NAME>. It does this: <WHAT IT DOES, in two or three sentences: who it is for, what it stores, what the rules are>. Deploy it at <ORIGIN, an https hostname I control, or "pick a free hosting option and tell me">.

An agent app is a service that a person uses entirely through their own personal agent (an assistant like you). The person never opens a website; the agent reads what the app publishes about itself, signs the person in, learns how it works, keeps one line of instructions about it, and from then on uses it whenever the person asks for the kind of thing it does. The intelligence is the agent's: the app stores data, applies rules, enforces permissions and delivers events, and runs no language model.

Read the standard first and follow it over anything I say here if they differ:
- What an agent app is: https://theagentappstore.com/standard (repository: docs/agent-apps/what-is-an-agent-app.md)
- How to design one: https://theagentappstore.com/standard/design (docs/agent-apps/design-guide.md)
- What gets checked: https://theagentappstore.com/standard/checklist (docs/agent-apps/checklist.md)
- The manifest: docs/manifest/agent-app-manifest-v1.md and docs/manifest/agent-app.schema.json
- The template to copy: https://theagentappstore.com/standard/template (template/ in the repository)
Repository: https://github.com/rayzhudev/the-agent-app-store

The test the app has to pass: a person can do everything the app offers by talking to their agent, starting from nothing but the URL. If any step needs "open the website and click", or pasting a configuration block before anything works, the app is not finished.

Ship these eight things on the origin:
1. An https origin. Everything below is served from it, or pointed to from the manifest.
2. The manifest at /.well-known/agent-app.json: valid against the schema, Content-Type application/json, Access-Control-Allow-Origin *, under 32 KB. Required fields: agent_app "1", name, one_liner, description, homepage, guide.url, one of mcp or http, categories (from the catalogue, at most three), pricing, publisher.name and publisher.contact (a mailto: address I will give you). Add audience only if the content is not for everyone. Add policies.privacy, hosts[] with honest tested/untested/unsupported statuses, say[] with three to five example lines a user might say, and instructions.
3. The guide at /agent.md (and a short form at /llms.txt: what the app is, the URLs, the lines to say): markdown, written for an agent, in this section order: what this is in five lines; install, per host, with exact commands, honestly marked tested or untested; first run; each main task in the order a new user meets them; keeping up (events); sign-in and credentials; safety; rules the server enforces; result codes and what to do about each; later conversations (which user requests this app serves); changelog. Second person, imperative, present tense; every recommendation carries its reason. "You must" appears only in the rules section, and that section lists exactly what the server refuses, nothing else.
4. Capabilities at GET /v1/capabilities: public, no credential: auth methods, catalogues, consent text, limits, guide URL.
5. Operations over HTTP under /v1 and, if you can, the same operations as MCP tools at /mcp (Streamable HTTP), with the same names, inputs and result codes, generated from one registry. OpenAPI 3.1 at /v1/openapi.json. One envelope: {ok: true, data, meta} or {ok: false, error: {code, message, next_actions, details?}, meta}; meta always carries the guide URL. Stable result codes with next_actions. Idempotency-Key on mutations. Opaque cursors for lists. Self-description on any request: GET / and GET /v1 return a discovery document pointing at the guide, OpenAPI and MCP; unknown routes return directions, not bare 404s; 401 says how to get a credential; validation errors return the schema fragment that failed. Anything written by another user is returned verbatim under a field listed in meta.third_party_fields and is never interpreted on the server. Public reads need no credential. Talk to the agent and mark what is for the user: "Tell your user" / "Ask your user" in the guide, tell_user / ask_user in responses; publish the natural question beside every catalogue the user answers, so the agent can map "berries and coconuts" onto fruits.
6. Only if the app needs accounts (many do not; then declare auth_methods ["none"] and skip this): sign-in an agent can complete without a browser: email one-time code first, then magic link with a grant code, social sign-in if useful, MCP OAuth if the host runs it. One account per person, many revocable connections with scopes, long-lived agent tokens with a recognisable prefix. Provide account.delete. Never ask the agent for a credential to another service.
7. Events, if the app has news: a durable inbox with events.list and events.ack by cursor, a read-only checkin.get for the agent's daily check-in, and push over the channel the agent offers (MCP events, signed webhook, Slack or Discord webhook, email), each verified by a code sent through the channel. Pushes carry event ids and types only. No server-side schedules.
8. A landing page for humans: what the app is, the lines to say to your agent, install snippets per host, privacy and terms. No browsing UI, no dashboard. Include the line "Find us on the agent app store: https://theagentappstore.com/apps/<origin host>" and the badge https://theagentappstore.com/badge.svg in the landing page, the README and the guide.

The instructions line (manifest field "instructions", also in the guide): one line under 280 characters that begins with the app's name, says what the app is, when to use it and where the guide is, and that an account is needed only if one is. Installing the app is an agent adding this line to its standing instructions after its user agrees; uninstalling is removing it.

Rules I want kept: no language model on the server; no ranking, summarising or writing on the user's behalf; one app, no feature that needs a human screen; every example line in say[] must be something the guide actually supports.

Stack: <YOUR PREFERENCE, or "choose something cheap with a free tier and no servers to run, and tell me why">. Write tests for the manifest, the guide's sections, the envelope and every result code.

When it is deployed, check it the way the store will: fetch the manifest and validate it against the schema; fetch the guide and confirm it has the install and rules sections; call GET /v1/capabilities with no headers; send an MCP initialize with no credential and confirm a result or a 401 with WWW-Authenticate; then read the guide top to bottom as a stranger and tell me whether you could install, sign in and do the first task from the text alone. Fix whatever fails. Then show me the manifest, the instructions line and the landing page text, and wait for me before submitting it anywhere.

2. Check whether an existing app meets the standard, and make it meet it

Use this on an app you already have. The agent reports first and changes nothing until you say so.

I have an app at <ORIGIN>. Check whether it is an agent app by the agent app standard, tell me exactly what is missing, and then, once I agree, make the changes.

An agent app is a service a person uses entirely through their own personal agent: the agent reads what the app publishes about itself, signs the person in, learns how it works, keeps one line of instructions about it, and uses it whenever the person asks for the kind of thing it does. The test: can a person do everything the app offers by talking to their agent, starting from nothing but the URL?

Read the standard before you judge: https://theagentappstore.com/standard, /standard/design and /standard/checklist (repository docs/agent-apps/ at https://github.com/rayzhudev/the-agent-app-store), and the manifest specification in docs/manifest/.

Run the store's checks against <ORIGIN>, numbered as in the checklist, and report each one as pass, fail or skipped with evidence:
- 1 manifest_reachable: GET /.well-known/agent-app.json returns 200, application/json, under 32 KB, on the origin itself.
- 2 manifest_valid: the document validates against docs/manifest/agent-app.schema.json; if instructions is present it begins with the name.
- 3 guide_reachable: guide.url returns 200 with markdown or plain text, under 256 KB.
- 7 mcp_alive: the MCP endpoint answers initialize without a credential, or returns 401 with WWW-Authenticate.
- 8 api_alive: the capabilities URL or API base answers without a credential.
- 4 to 6 and 9 to 12, measured and shown but not required: guide_has_install, guide_has_rules, guide_mentions_mcp, openapi_valid, privacy_reachable, terms_reachable, skill_reachable.
Checks 1, 2, 3 and one of 7 or 8 are the gate: the store lists an app that passes them.

Then judge the parts no crawler can: read the guide as an agent that has never heard of the app and tell me whether you could install, sign in and do the first task from the text alone; whether "you must" appears outside the rules section; whether sign-in can be completed without a browser; whether public reads need a credential; whether anything in returned data could read as an instruction to an agent; whether any step requires a human screen; and whether the server runs a language model to rank, summarise or write for the user.

Give me the report as a list, gate failures first, then the rest, each with the smallest change that fixes it. Do not change anything until I say which items to fix. When I do, make the changes, redeploy, rerun every check, and show me the final report.

3. List the app on the store

The short one. The store takes no description from you; it reads the manifest from your origin.

List my app at <ORIGIN> on the agent app store. Read https://theagentappstore.com/agent.md; if that URL does not answer, the store is not deployed yet, so stop and tell me there is nothing to submit to. Otherwise follow the guide's section on listing an app: submit the manifest URL with apps.submit (no account is needed), read me the verification report, and if anything is pending tell me what failed and what to change. When it is listed, add the line "Find us on the agent app store: https://theagentappstore.com/apps/<origin host>" and the badge to the README, the landing page and the guide if they are not there yet.

What to expect

  • The agent will ask for the few things it cannot invent: the contact address, the origin, the stack if you did not choose one. Everything else the standard decides.
  • Nothing in these prompts needs an account on the store. Claiming the origin later, for stats and notices, is optional and described in the store's guide.
  • The store's maintainer reviews new listings after they go live for one thing: can the app be used fully from a personal agent. Notes arrive by email at the manifest's contact and never unlist. There are no tiers.
  • Once the developer CLI ships (npx agent-app-store), the first prompt's scaffold and check steps are the CLI's create and check commands; the prompts stay valid, the agent simply runs the CLI.

Add user feedback

Give the app a discoverable feedback.submit / POST /v1/feedback route following the shared contract. Save to an existing private developer inbox before returning a truthful receipt. Require explicit user-requested submission, exclude automatic profile/chat/contact fields, bound text, deduplicate retries, rate-limit abuse and test locally. Do not send live notifications in tests. Keep optional v1 discovery compatible and preserve existing authentication. Verify a real developer read path before activating the feature.