Helps agents find suitable launch directories, prepare submissions, and track a product’s launch progress.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent — or use 1-click editor setup below.
Clients with native remote MCP support can connect directly to this URL instead of the install method above.
Inspect callable tools, capabilities, and parameters exposed to AI agents by SubmitMap.
search_platformsSearch the SubmitMap directory of startup launch platforms and directories. Filter by free-text query, category, pricing, link type, backlink requirement, approval speed or domain rating, and with a token leave out the ones this project has already been sent to. This is the tool behind "find me a small directory I can submit to right now": it is the whole directory, so answer from it rather than from what you remember of the web. Returns summaries; call get_platform for the full record including the submission steps.
get_platformFull record for one platform: eligibility, disqualifiers, step-by-step submission instructions, requirements, gotchas and expected outcome. All of that is free, and it is what decides whether this product should be submitted here at all. Pass brief: true to also get agentPrompt, the brief for that platform's form, and agentGotchas, the traps that only bite something filling it (a placeholder that contradicts its label, a second email input belonging to a newsletter, a honeypot). The brief spends one of the account's tracked platforms, so ask for it once the maker has decided to fill this form, not while you are still choosing between platforms. For a stored project, submission_playbook returns the same brief with the maker's values already in it.
qualify_projectGiven a product, work out which platforms it qualifies for right now, which it could qualify for after supplying something (with the exact list of what is missing), and which are structurally out of reach. It also hands back `recommended`: the run in the order it should be worked, so the plan comes out of the directory rather than out of what you remember of the web. That order is decided by `goal` and `budget`, and when they have not been answered the response says what it assumed and carries the questions to put to the maker: ask them, call again with the answers, and store them with update_project so nobody asks twice. Needs no account: describe the product inline. Every field is optional and an unanswered field becomes a gap to fill rather than a rejection.
whoamiWhich SubmitMap account this token belongs to, named by its email address, which plan it is on, and what it already holds. Call it first if you are unsure whether the maker is connected, and tell them the address it reports: it is the only way either of you can tell one of their accounts from another. It does not hand you the plan's limits and you do not need them to work: plan the whole run, and a limit says so at the write it stops.
list_projectsThe projects on this account, each with its facts (eligibility answers) and its pack (what a submission form asks for), plus what is still missing from the pack. Call it whenever the maker says "my product" or "my project" without naming one: it is how you find out which project they mean, and every other account tool takes the id it returns.
create_projectStore a product on the account. Before asking the maker anything, use what you can already see: a README, package metadata, the site's own copy and title, an assets or public folder. A maker working in their product's repository should be able to say 'add my product to SubmitMap' and get a filled-in project back, with questions only about what is genuinely not there. Fill in as much as you can, leave the rest, and come back with update_project. Facts drive what it qualifies for; the pack is what you will paste into forms later. Ask about images early: most platforms want a square logo and many want a cover, and every asset in the pack is two fields, the public address (logoUrl) and the file on the maker's machine (logoFile), because a form uploads the file and only the address can be shown back to them.
SubmitMap MCP server gives agents structured access to 366 startup, SaaS, and AI launch platforms. It helps determine where a product is eligible, what information or assets are missing, and which platforms should be handled first. Platform records include eligibility rules, disqualifiers, requirements, submission steps, expected outcomes, and practical gotchas.
The free, account-independent tools are search_platforms, get_platform, and qualify_project. Search can filter by terms such as category, pricing, link type, backlink requirements, approval speed, and domain rating. Qualification can separate immediate matches, platforms that need more information, and platforms that are structurally unsuitable.
Account-backed tools support a stored project and its launch workflow. They can save project facts and submission content, produce an ordered plan, provide a form-specific brief, record what happened, and list current submission statuses.
Start with search_platforms when the goal is to find candidate directories. Use get_platform to inspect a specific platform before deciding whether to submit. Its optional brief includes the form-oriented prompt and agent-specific traps, so it should be requested after a platform has been chosen rather than while comparing many options.
qualify_project accepts product details inline and does not require an account. Missing optional answers are treated as gaps to resolve, not automatic rejection. The response can include questions for the maker and a recommended order. Once those questions are answered, the result can feed plan_submissions.
For an account workflow, list_projects identifies the project before other project-specific calls. create_project stores the product, while update_project merges new or corrected facts and submission-pack fields. The pack can include both public asset addresses and local files, such as a logo URL and logo file.
No required environment variables or license information are provided in the supplied material. The account tools use a SubmitMap token. whoami reports the email address associated with that token, the plan, and the account’s existing contents; use it when the connected account is unclear.
A repository, package metadata, website copy, title, or public assets can provide information for create_project. The maker may still need to supply missing facts, images, login choices, or other submission details. Store those answers with update_project rather than repeatedly asking for them.
search_platforms and inspect complete records with get_platform.qualify_project.create_project and update_project.submission_playbook, including preflight checks, mapped field values, steps, sign-in handling, and form traps.plan_submissions.record_submission.list_submissions.SubmitMap MCP server enforces an account workflow for stored projects. Only one submission brief may be open for a project at a time; record the result before requesting the next brief. A submission that requires the maker’s login, CAPTCHA, payment, file, or confirmation can be recorded as planned with a note instead of being presented as completed.
The brief is metered according to the account plan, while project planning and submission recording do not consume the same tracked submission allowance. The brief can also spend a tracked platform, so avoid requesting briefs in advance or in parallel. If the live form differs from its record, include that difference when recording the submission.
Factual signals from GitHub, npm, and our automated checks — not a rating.
No reviews yet — be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/submitmap)<a href="https://allmcps.com/mcp/submitmap"><img src="https://allmcps.com/api/badge/submitmap?style=directory" alt="SubmitMap on AllMCPs" /></a>