Most product directories were designed for a human founder filling out a browser form. That workflow still matters, but it is no longer the only credible way a product can be described, evaluated, and submitted.
MadeWithStack now supports a different path: an AI agent can prepare a structured product record, submit it through a public API, preserve stack evidence, include Agent Directory qualification details, and hand the result to a human editorial review process.
That is the important distinction. The API does not turn MadeWithStack into an instant publishing feed. It turns product intake into a machine-readable workflow while keeping the catalog curated, reviewable, and useful for people who need to trust what they are browsing.
For founders, operators, and developers building agent-native products, this matters because the agent that helped build the product can often do more than paste a marketing blurb. It can inspect the stack, normalize tool names, gather supporting links, generate a clean description, and preserve a follow-up handle for review status.
For MadeWithStack, this turns each submission into something stronger than a row in a database. A good submission becomes a review object: a structured record with product identity, stack context, evidence, review state, and eventual trust signals.
The short version
Agents can now submit products to MadeWithStack by sending a valid JSON payload to POST /api/v1/submit. The payload must include the product name, canonical URL, short description, submitter email, and stack metadata through tool_slugs, tool_ids, or custom_tools.
If the product is agent-native, agent-built, or centered on an agentic workflow, the payload can also include Agent Directory claim fields such as qualification_type, agent_use_case, workflow_summary, agent_tools_used, and supporting_links.
Accepted submissions return a 201 response and enter the pending review queue. That response is not publication. It means the record was accepted for review and the agent should preserve the returned review_status_url.
Why agentic submission matters
The old directory submission model assumes a person has to manually translate a product into directory metadata. That creates several problems for a serious catalog.
Founders often submit too little context because they are moving quickly. Product descriptions can drift into vague launch copy. Stack information gets flattened into logos or buzzwords. Agent-native details are easy to miss because the person submitting may not know which fields matter for future discovery.
Agents are good at a different part of the job. A capable coding or operating agent can read the product site, inspect docs, identify the stack, fetch valid tool slugs, and produce a consistent payload. It can include links that support the claim instead of only asserting it.
That is useful for founders because submission becomes less repetitive. It is useful for editors because the review queue starts with cleaner data. It is useful for human readers because approved listings can carry better context after review.
The best version of this workflow is not "agents publish anything automatically." The best version is "agents prepare structured evidence, and humans make the catalog decision."
What agents can submit
The public submission API accepts a compact core product record:
| Field | Purpose | Review note |
|---|---|---|
name | Product name shown to editors and, if approved, readers | Should match the public product identity |
url | Canonical product homepage | Do not submit docs pages, changelog pages, or asset URLs |
description | Short product summary | Must be 240 characters or less |
email | Submitter email for updates and status checks | Used for pending review privacy and follow-up |
tool_slugs | Preferred stack metadata | Fetch current slugs from GET /api/v1/tools |
tool_ids | UUID-based stack metadata | Useful only when the agent already has valid IDs |
custom_tools | Stack entries not yet in the taxonomy | Limited to 10 entries, 40 characters each |
For Agent Directory eligibility, the API accepts additional claim fields:
| Field | Purpose |
|---|---|
qualification_type | Classifies the product as agent_native, agent_built, or agentic_workflow |
agent_use_case | Places the product in a practical agent use-case category |
qualification_statement | Explains why the product qualifies |
workflow_summary | Describes the agentic workflow in concrete terms |
agent_tools_used | Lists relevant tools used by or inside the workflow |
supporting_links | Provides evidence editors can inspect |
Those claim fields are optional. However, if an agent sends qualification_type, the claim must be complete enough to review. A half-filled Agent Directory claim is worse than no claim because it creates ambiguity in the editorial queue.
A good payload is not just a form submission
The most useful submissions preserve three kinds of information.
First, they preserve product identity. The URL should be the canonical homepage. The name should be the name the product actually uses. The description should say what the product does without turning into hype.
Second, they preserve stack evidence. MadeWithStack is a stack-aware directory, so the product should include valid tool slugs whenever possible. tool_slugs are preferable because they are readable, stable for agent workflows, and easy to validate against the live taxonomy.
Third, they preserve claim evidence. If the product belongs in the Agent Directory, the payload should explain why. That means the workflow summary should be specific enough for an editor to understand how the product uses agents, not merely that it mentions AI.
Minimal request example
Agents should usually start with /developers/submit, then fetch valid tool slugs from /api/v1/tools, and then send the submit request.
curl -X POST https://www.madewithstack.com/api/v1/submit \
-H "Content-Type: application/json" \
-d '{
"name": "AgentFlow",
"url": "https://agentflow.dev",
"description": "Workflow orchestration for multi-agent operations teams.",
"email": "founder@agentflow.dev",
"tool_slugs": ["claude", "supabase"],
"qualification_type": "agent_native",
"agent_use_case": "operations",
"qualification_statement": "The product centers agent-led workflow execution.",
"workflow_summary": "Users define workflows that agents execute and monitor.",
"agent_tools_used": ["Claude", "Supabase"],
"supporting_links": ["https://agentflow.dev/docs"]
}'
The important part is not the example brand name. The important part is the shape. The agent submits a product, stack metadata, and claim evidence in one request. The API accepts the record into review if the payload is valid.
What a successful response means
A successful API submission means the record entered the editorial queue. It does not mean the product is public, indexed, approved for the Agent Directory, or eligible for a badge.
The response includes fields that help agents continue the workflow:
| Response field | How agents should use it |
|---|---|
slug | Store it as the product's MadeWithStack identifier |
status | Expect pending immediately after submission |
review_status_url | Poll this URL for review progress |
owner_claim | Track the submitter inbox verification state |
claim_status | Understand Agent Directory claim progression |
claim_eligibility | Understand whether the claim can be shown publicly |
next_action_code | Branch the agent workflow without parsing prose |
The review status URL is the durable handle. If an agent submits the product and then loses that URL, it has made the founder's follow-up workflow worse. A good submitting agent should store it in the project notes, issue tracker, CRM, or wherever the product team keeps launch tasks.
Error handling should be deterministic
Agents should branch on error_code, not on human-readable error text.
The main submission failure modes are intentionally explicit:
| Error code | What it means | Practical agent response |
|---|---|---|
VALIDATION_ERROR | Required fields are missing or malformed | Fix the payload before retrying |
INVALID_TOOL_SLUGS | One or more submitted slugs are not in the taxonomy | Refresh GET /api/v1/tools and remap the stack |
DUPLICATE_DOMAIN | The product domain already exists in the directory or queue | Stop and check the existing listing or pending status |
RATE_LIMITED | Public write limits were exceeded | Respect Retry-After and slow down |
This is where an API submission path becomes better than a browser-only workflow. A browser form can show an error, but an agent needs a predictable machine-readable reason so it can decide whether to correct, retry, wait, or stop.
How manual review fits the API model
MadeWithStack is not trying to remove editors from the system. It is trying to remove avoidable intake friction while giving editors better starting material.
After a valid submission is accepted, editors can review:
- the product homepage and whether it describes a real product
- whether the submitted domain is canonical
- whether the stack evidence is plausible
- whether any custom tools should be mapped into the taxonomy
- whether the Agent Directory claim is supported by the product itself
- whether the submission appears duplicative, thin, spammy, or misleading
- whether approval should include broader catalog placement, Agent Directory placement, or a request for revision
This is why the API is open but not trust-blind. No account, API key, or payment step is required for the public submission path. But the absence of friction does not mean the catalog accepts everything.
The Agent Directory claim needs evidence
The Agent Directory is not just a tag for products that mention AI. It is a more specific surface for products that are agent-native, agent-built, or centered on agentic workflows.
That is why qualification_type should be treated carefully.
Use agent_native when the product's core value depends on agents or agentic execution. Use agent_built when the product was materially built by agents and the submission can support that claim. Use agentic_workflow when agents are central to the workflow even if the product itself is not purely an agent platform.
Weak claim:
{
"qualification_type": "agent_native",
"qualification_statement": "It uses AI."
}
Stronger claim:
{
"qualification_type": "agent_native",
"agent_use_case": "operations",
"qualification_statement": "The product coordinates agent-led workflow execution for operations teams.",
"workflow_summary": "Users define workflows, assign goals, and monitor agent execution across operational tasks.",
"agent_tools_used": ["Claude", "Supabase"],
"supporting_links": ["https://agentflow.dev/docs"]
}
The stronger claim is easier to review because it is concrete. It does not ask editors to infer the agentic workflow from branding.
REST and MCP are two doors into the same workflow
Some agents prefer REST. Some agent runtimes already speak MCP. MadeWithStack supports both paths.
REST integrations can use:
/developers/submitfor the focused agent submission kit/api/v1/openapifor the full contract/api/v1/schemafor the compact schema/api/v1/toolsfor the current tool taxonomy/api/v1/submitfor the write endpoint/api/v1/products/:slugfor review polling
MCP-capable runtimes can connect to /mcp and call submit_product directly. The MCP tool follows the same trust model as the REST endpoint: accepted submissions enter manual review, and MCP submission does not bypass curation.
The practical guidance is simple. Use MCP when the host supports it cleanly. Use REST when you need a universal HTTP contract, typed client generation, or direct control over request handling.
What agents should do before submitting
An agent should not submit the first payload it can assemble. It should run a quick preflight.
- Confirm the submitted URL is the product homepage.
- Read the homepage enough to describe the product accurately.
- Fetch current tool slugs from
GET /api/v1/tools. - Prefer existing
tool_slugsover custom tool names. - Keep the description under 240 characters.
- Add Agent Directory claim fields only when the product clearly qualifies.
- Include supporting links when making an agent-native or agent-built claim.
- Submit once, store
review_status_url, and poll conservatively.
This keeps the API useful for serious submissions instead of turning it into a high-volume queue of low-quality records.
What humans gain from agent submission
The human reader is still central. A directory only matters if people browsing it can quickly answer practical questions.
They need to know what the product does, who it is for, what stack it uses, why the listing is credible, and what review state supports it. Agentic submission helps because it can preserve more of that metadata at intake time.
The benefit is not that the agent replaces editorial judgment. The benefit is that editorial judgment starts with a better packet of information.
That makes MadeWithStack different from a generic launch board. The directory is not optimized for raw submission volume. It is optimized for structured discovery, professional trust, and durable catalog quality.
A copy-paste prompt for submitting agents
If you are using an agent to submit a product, start with a task like this:
Submit this product to MadeWithStack. Read
/developers/submit, fetch valid tool slugs from/api/v1/tools, build a validPOST /api/v1/submitpayload, include Agent Directory claim evidence only if the product clearly qualifies, and preserve the returnedreview_status_urlfor follow-up.
That prompt tells the agent to do the important work in the right order: read the submission kit, validate taxonomy, prepare structured metadata, respect the claim threshold, and preserve the review handle.
The larger direction
The useful future is not a bigger pile of AI products. It is a cleaner workflow where agents can submit structured product data, humans can review it with better evidence, and buyers can browse a catalog that has enough metadata to be useful.
That is the MadeWithStack direction: a professional agentic product directory where programmatic submission, manual review, and human trust signals work together.
Start here: Submit an AI agent product by API.