Creator guide

The submit flow starts by picking what kind of agent you're publishing:

• Declarative agent — a recipe or tool-using (doer) agent described by a manifest. No-code, runs anywhere, and nothing executes on FindAgent's side. Build it in the wizard or import an existing manifest.
• Skills bundle — your own skills or rules repo (Claude Agent Skills, Cursor / Windsurf / Continue rules, an AGENTS.md) turned into one agent. Connect GitHub, pick the repo, and each skill becomes a prompt. Nothing executes.
• Code agent — your real code from a GitHub repo, run 1:1 in an isolated sandbox. Connect GitHub, pick a repo, and FindAgent reads it as-is and generates the manifest from it — you never write a findagent.json. Scanned and reviewed before it publishes.
• MCP server — a remote MCP server you already host. Add its URL and tools and it's listed in the MCP directory for anyone to discover and connect. Nothing runs on FindAgent's side — the listing only points at your endpoint.

If you already keep an agent manifest in a repository, you can import it to prefill the submit wizard instead of typing every field. Importing is read-only — FindAgent fetches and parses the manifest, fills in the form, and waits for you to review. Nothing is ever run during import; the security scan happens later, in the normal review pipeline. (Running real code from a repo is the code-agent path above, not this import.)

You can also paste a JSON manifest directly. Either way, you review the prefilled form before submitting.

The code-agent path 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 (declarative agents ship no code at all; code agents are 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.

The wizard walks through five steps:

1. 1
   Basics. 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
   Manifest. The system prompt and tools. For a doer agent, declare each tool and its action; see the manifest spec.
3. 3
   Pricing. Free or paid, and the price if paid.
4. 4
   Install. Which clients the agent targets and how it's delivered.
5. 5
   Review. A final read-through before you submit for review.

You set whether an agent is free or paid and at what price. On every paid sale you keep the majority of the net revenue. The platform exists to make publishing an agent worth it — the split is creator-first by design.

• Free agents are installable by anyone signed in.
• Paid agents require a completed purchase before the agent's recipe or manifest is released — install, the CLI, and the manifest endpoint all enforce that entitlement.

A doer agent goes beyond a prompt recipe: it declares tools that take real actions. In the manifest step, 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 — input caps and prompt-injection deny-lists, output secret-leak scanning (always on), and per-tool policies like human approval, spend caps, and rate limits. See the manifest spec for the full shape.

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).
• A code agent whose bundle fails the static scan, or whose manifest the sandbox can't accept — code agents fail closed.
• Agents that violate the marketplace's prohibited-content policy.
• Manifests that fail schema validation (missing required fields, malformed tools).

You can reply to reviews on your agent as the creator — 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.