Guides

Paste one of these and fill in the blanks. Most of what makes a run go well is getting the order right, and these have it built in.

A whole launch, start to finish

The first time. You have a product and no idea where it belongs.

Use the SubmitMap MCP server for this.

If you are in the product's workspace, read it from there: the README,
the package metadata, the site copy, the assets folder. Ask me only
about what is genuinely not in front of you.

1. Call whoami so we both know whether I am connected and what my plan
   allows.
2. Store the product with create_project. Fill in the facts and as much
   of the pack as you can see, then ask me for the rest in one go.
3. Call qualify_project. Show me what is ready, what is one missing
   piece away (name the piece), and what is out of reach and why.
4. Call plan_submissions with the recommended order. Planning is free,
   so plan the whole run, not the part that fits my current limit.
5. Stop there and show me the plan before submitting anything.
  • Plan the run before spending any of it. A plan costs nothing on any plan; what the free tier meters is a recorded outcome, and it is spent once and for good.
  • If the agent starts naming platforms you recognise instead of ones the tool returned, it is answering from memory. Tell it to work from `recommended`.

Submit to one platform, properly

The plan exists and you want the next one done.

Take the next platform in my SubmitMap plan.

1. Call submission_playbook for it before opening any tab.
2. Read the preflight aloud. If something is missing, ask me for it and
   stop; do not improvise a value I have not given you.
3. Work the steps in my browser, in front of me. Sign-in is mine unless
   I have told you otherwise.
4. Verify the listing the way the playbook says to verify it. Never
   send the form twice to find out.
5. Call record_submission with what actually happened, including
   "attempted" if you cannot prove it landed.
  • The playbook is the point. Everything an agent needs to fill that specific form is in it, including the traps that only bite something typing into it.
  • The submission happens in the browser the maker is already signed into. Nothing about those accounts is handed over.

One small directory, right now

You have twenty minutes and want something submitted today.

Find me one SubmitMap platform I can submit to in the next
twenty minutes: search_platforms with a domain rating ceiling around
40, approval inside a week, and excludeTracked so I do not do one
twice. Then run the playbook for it and record what happened.
  • The ceiling is the important half. The small, quick end of the directory is where a first submission belongs, and it is the part an agent will never pick on its own.
  • excludeTracked needs a token. Without one it is ignored, and the result says so rather than pretending the list is fresh.

Get the pack finished before it blocks you

A preflight has stopped you, or you would rather it never did.

Call list_projects and tell me exactly what my pack is
missing. For each gap: what the field is for, how long it can be, and
which platforms in my plan refuse a submission without it. Draft the
text ones in my voice from what you can see of the product, show me
each draft, and only save what I approve with update_project.
  • Assets are the commonest reason a run stalls. Most platforms want a square logo and many want a cover image.
  • Asset fields take a path on your machine as readily as a URL, because a submission form uploads a file rather than fetching one.
  • Copy gets pasted into a listing under your name, so it has to read as yours. An em dash is the tell that undoes that; the tools flag one rather than rewriting your words.

Put the badges on your site without touching the code

A platform wants its badge live before it will approve you, and you have your product open in the same session.

Which platforms in my SubmitMap plan want a badge or a
link back on my own site? For each one, take the markup and the
placement rule from its record, add it to this site in one place I can
reuse, and show me the diff before anything is committed. Then tell me
which ones I still have to deploy before I can click verify.
  • This is the step that quietly ends launch runs. The submission is two minutes; the badge is a code change, a deploy and a second visit, and it gets postponed until the whole run is.
  • Ask for the diff first if you have never let it near the site. Once you have seen it do one, "add the rest and open a PR" is a reasonable next sentence.
  • Badges are load-bearing after approval too: several of these platforms re-crawl your site and delist you if the badge comes down.

When you cannot tell whether it landed

The tab died, the connection dropped, the page never came back.

Do not send that form again. Check whether it landed the
way the playbook's verification step describes, and if that is not
conclusive, call record_submission with status "attempted" and a note
saying exactly what you saw. I will settle it later.
  • A recorded uncertainty costs the same as a recorded success and is worth far more than a silence. An unrecorded submission is the expensive mistake here.
  • Every platform has a way to check without submitting twice. A duplicate listing is harder to undo than an unknown one.

Ask what you have already done

A week later, when nobody remembers.

Using SubmitMap, tell me where my launch stands: what is
live, what is still waiting and how long it has been waiting, what came
back rejected or needs changes, and what is next in the plan. Then tell
me the one thing worth doing today.
  • This is what the tracking is for. The answer comes from the account, not from scrolling back through a chat.

Every one of these ends in a record on your dashboard. That is the half worth being pedantic about: a submission nobody wrote down is one you will make twice.

NextTools