Creator guide

The submit flow asks one thing first:

• Agent — something you built: instructions, skills, actions or code. It comes from GitHub (your own repo), an Upload (a .zip, a folder, or a single manifest or skill file) or the Editor, where you write instructions, actions, skills, commands and sub-agents in the browser. FindAgent reads what you hand it and shows what it found before any form, so you start from your own files rather than a blank page. Code needs a GitHub repo for now. Upload and the Editor carry the other three parts. Moving from a Custom GPT? Its instructions and actions open straight in the Editor.
• MCP server — a server you already run. Add it by its URL, its package or run command, or its server.json, and it's listed in the MCP directory for anyone to discover and connect. Nothing runs on FindAgent's side — the listing points at your server.

A findagent.json in the repository you pick, or uploaded on its own, fills in the form from its fields instead of you typing each one. An OpenAPI file does the same for actions. Reading it is read-only: FindAgent parses the file, fills in the form, and waits for you to review it. Nothing runs; the security scan happens later, in the normal review pipeline.

Bringing your code doesn't need a FindAgent manifest at all. Connect GitHub, pick a repo, and FindAgent generates the agent from your code. It reads what's already in the repository — an Anthropic DXT manifest.json, an MCP server config, your .env.example, package.json, and README — and auto-detects:

• Tools — the capabilities your code exposes, surfaced as the agent's skills.
• Credentials — the secrets your code needs, read from your DXT env and .env.example keys (never the values), each as a credential slot.
• Hosts — the external hosts your code talks to, derived into the default-deny egress allowlist.

You only confirm or edit what was detected — you never write a findagent.json. That's the 1:1 promise: the repo you bring is the agent that runs. Your code still runs only inside the isolated, scanned, reviewed sandbox — the security keystone is unchanged (instructions, skills and actions ship no code at all; an agent's code is sandboxed).

Don't want to fill the wizard by hand? Add the FindAgent platform MCP to your AI client (Claude, Cursor, any MCP client) and let your own assistant write the listing. Connect it at https://mcp.findagent.cloud/mcp, then ask it to list one of your repos: it calls findagent_import_repo to read the repo's grounding (basics, languages, the tools it exposes and the hosts they reach) and findagent_list_categories to pick a category, and writes the title, tagline, description, and the rest. You review and submit in the wizard.

This is read-only on our side — import_repo pulls only repos your connected GitHub token can read, parses them statically (nothing runs, nothing is persisted), and your assistant does the writing. The wizard's own prefill is deterministic detection; the AI synthesis happens in your client, on your model. See MCP & API.

Any AI assistant can do this, not only one. Playbooks that work with all of them are in FindAgent/agent-creators, and FindAgent/agent-template is a code agent template in Node and Python.

The Editor is one page with the whole agent as a tree:

1. 1
   Listing. Name, slug, tagline, and category. The slug becomes the agent's permanent URL, so choose it carefully — it can't change after publishing.
2. 2
   Instructions and actions. How the agent works, and the HTTP calls it may make with the key each one needs. A key is only declared here; the buyer enters it when they connect.
3. 3
   Skills, commands and sub-agents. Optional parts, each written as its own file.
4. 4
   Checks and submit. Checks shows what would stop a submit, and where. Submitting sends the package to the scan and a human review; screenshots are added right after.

FindAgent is in early access: every agent publishes free and paid pricing isn't available yet. When payments launch you'll set whether an agent is free or paid and at what price, and on every paid sale you'll keep the majority of the net revenue — the split is creator-first by design.

• Free agents are installable by anyone signed in.
• Once paid agents go live, a completed purchase will be required before the agent's instructions or manifest are released — install, the CLI, and the manifest endpoint all enforce that entitlement.

An agent with actions goes beyond instructions: it declares tools that take real actions. In the Editor's Actions (or a findagent.json), give each tool an action (an HTTP call or a prompt template) and declare a host-bound credential slot for any secret it needs. You can also declare guardrails the platform enforces on your behalf. The Editor's Protections set the input rails (an input length cap and personal-data redaction); output secret-leak scanning is always on; per-tool policies like human approval, spend caps, and rate limits are declared in a findagent.json. See the manifest spec for the full shape.

Most agents with actions or code need a secret to reach the API they act on. You declare a credential slot for each one — the buyer supplies the value at connect time, and FindAgent stores it encrypted and attaches it only to the host you bound. You never hold the buyer's secret, and it never reaches a host you didn't declare. The two fields that trip creators up:

At install time each slot shows the buyer a per-scheme format hint (for example, “paste the Base64 of id:token, not the raw token”), so you don't have to explain it. The full slot shape — allowed_hosts, header_name, host_example, and the rest — is in the manifest spec.

Every submission goes through the same gate before it can go live:

1. 1
   Static scan. The manifest is scanned automatically — host allowlists, credential bindings, and tool actions are checked. Unsafe declarations fail closed.
2. 2
   Human review. A reviewer checks the submission for quality and policy. Approval or rejection is emailed to you.
3. 3
   Publish. Once approved, the agent gets a public page, an install command, and a spot on your creator profile.

• A tool action that points at a host outside its declared allowlist, or a credential slot with no allowed host (a credential needs an audience).
• An agent whose code fails the static scan, or whose manifest the sandbox can't accept — agent code fails closed.
• Agents that violate the marketplace's prohibited-content policy.
• Manifests that fail schema validation (missing required fields, malformed tools).

Keep your published listing current from your dashboard:

• Edit the listing — update the title, tagline, description, and category any time. Changes go live immediately; your agent's tools and behaviour are unchanged (those re-version through Publish new version — see Versioning & updates).
• Add screenshots — upload up to eight images (PNG, JPG, or WebP, 5 MB each) from the listing editor. They show in the gallery on your agent's page so people can see it in action before they connect.
• Reply to reviews — a public, one-per-review response to answer a question or address feedback. Keep it professional; the same content policy applies, and abusive replies can be flagged like any other content.