How LaunchDistro works

A backlink starts with a listing: a form on a directory, filled in with the same facts about your product every time. LaunchDistro keeps those facts in one profile, knows which directories take your product and what each one really gives on its free plan, and hands your agent a playbook per directory. It then opens the public listing and reads the link, so a listing counts as live only when the link is really there.

Nothing is submitted from our servers. The directories' forms need your signed-in sessions, so your agent does the filling in your browser and stops for you at anything that is yours to decide.

The Model Context Protocol is an open standard for connecting AI apps to tools and data. An app (the client) connects to a server, asks it what it offers, and calls it when the model decides to. A server can offer three kinds of thing: tools the model calls, prompts the user picks, and resources the app reads. Messages are JSON-RPC 2.0. A server is either started on your computer (over standard input and output) or reached over HTTP, and LaunchDistro is the second kind: a remote server, so there is nothing to install and it works in apps that cannot run programs. Over HTTP each message is a POST to one endpoint and the reply is a JSON object or an event stream; ours replies with JSON. The protocol itself is stateless in its current revision: every request carries what the server needs to answer it.

Your AI app reads each tool's name, description and parameters on its own, so you never call a tool by hand: you say what you want ("where does my product qualify?") and the app chooses the tool.

The server is stateless: every request stands alone, and each AI app has its own token (ld_agent_...), shown once and revocable on its own. See the setup page for the command per app and the tools reference for the 13 tools and the one prompt.

1. Profile. get_product_profile; if it is thin, the agent fills it from your repository and site, shows you, then save_product_profile.
2. Match. match_directories says where the product qualifies: ready, locked, or not a fit with the reason.
3. Plan. plan_submissions orders the ready directories, each with why it is where it is, at a pace for your domain's DR, and saves it to the dashboard. Nothing is sent.
4. Playbook. submission_playbook for one directory: who it takes and turns away, requirements, what the form asks, what paying changes, the traps, where to stop. It is read before every submission.
5. Your decisions, once. Before touching the form the agent asks, in one message, about a fee, a badge or link back, votes or other actions from your account, an account to create or sign in to, and any copy the profile lacks, each with a recommendation.
6. The form, in your browser. Your agent fills it from the profile only, where you can watch. It replaces the directory's own AI-written copy with yours and leaves hidden fields empty.
7. Record. record_submission with the confirmation page. A listing saved but not sent yet is draft, with a note on what is left.
8. Verify. When the listing is public, verify_link opens it, finds your link and reads its rel. Only then is it live.

The pace follows the domain's DR: gentle (3 to 5 a day) below DR 20 or when the DR is unknown, standard (8 to 12 a day) from DR 20, fast (15 to 20 a day) only when you ask. A new domain that collects a hundred links in an afternoon looks bought.

Only directories LaunchDistro gives for your product. If you name another site, your agent does not open its form: it calls suggest_directory, and the directory reaches your matches once it has been checked and has a playbook.

Cookies, sessions and passwords stay in your browser. What reaches us is your account, one token per AI app, the profile you save and what your agent records: statuses, links and link checks.

Your agent stops, records needs_human with what is waiting, and asks you, at:

• a sign-in (Google, GitHub, email), including two-factor codes and codes sent by email or SMS;
• a CAPTCHA, or any question there to prove a person is filling the form (a sum, a puzzle): it is left to you, never solved;
• a payment page, or a fee above what you said you would pay (your profile's paid_ok, asked once; with no answer it asks first): it explains what paying buys; it never pays;
• terms and consent boxes, and creating an account or typing a password: you do these in the browser;
• a field the profile cannot answer, and directory rules that turn your product away (it stops without opening a form and records skipped with the rule).

Free-plan actions from your account (upvoting other products, following, sharing) are done only after you say yes to that action for that directory, and the agent tells you which ones it did. A badge or link back goes into your site's footer in your repository only if your profile says you will show one: it shows you the diff and leaves committing and deploying to you, then verify_badge checks it before you press the directory's verify button.

One profile per product holds every fact a form asks, and nothing is filled from anywhere else. It lives on your dashboard (Product profile), and your agent can read and write it. Roughly:

• The product: name, website, tagline, short and long description, categories, tech stack, logo and thumbnail locations, and the product story (inspiration, what it does, how it was built, challenges, accomplishments, lessons, what's next).
• Who and what it is: the product types (SaaS, AI, developer tool, MCP server, desktop, mobile, extension, integration, e-commerce, local, template, and more), regions and country. They decide which directories take it.
• The company: stage, team size, funding, pricing model, incorporated or not, launch date, city, and the founder's name, contact, bio and profile links.
• Your answers: whether you will show a directory's badge (show_badge), whether you would pay a directory with no free route (paid_ok), and what the product already has (a live URL, open signup, a pricing page, a square logo, a cover image, a demo video, a public repository, docs, a privacy page, paying customers).

A directory that needs a badge you will not show, a public repository you do not have or a minimum domain rating you are below is reported as not a fit with that reason, and the playbook is refused before it counts. An empty answer is asked about, never guessed: the agent may only use facts you confirmed.

• Submitted means you (or your agent, on your word) pressed the button, with the directory's confirmation page recorded as proof.
• Live means our server opened the public listing page and found your link. Your agent cannot record it: only verify_link can.
• Dofollow or nofollow is the rel we read on that page. A directory's own claim is shown as its claim, never as verified.

Directories seldom show the listing address at submit time, so the dashboard's "Check if live" and list_submissions flag submitted directories past their usual approval time, and your agent looks for the listing and verifies it. On Pro every live link is checked again each week, and the dashboard alerts you when a link is dropped, flips to nofollow, or the page stops answering twice in a row.

300+ directories have a playbook your agent can follow, and more are added every week. Each one says who it takes, what its free listing gives, what the form asks and where to stop. A directory without a playbook yet is not offered.

Agents keep the catalog current: report_directory_fact sends what a directory's page says now (approval time, link type, badge rule, price), with the page's exact words and address. It changes a playbook only when those words are on the directory's own page and say what the report says; anything else is read by a person.

A submission attempt is a playbook fetched to submit, counted once per directory per UTC day, never a placed link: whether a listing goes live is the directory's decision. When a limit is reached the tool answers with the reason and the way out, and nothing is throttled silently. See pricing.

• One token per AI app, shown once, revocable from the dashboard without touching the others. Claude Desktop's connector takes only a URL, so the token rides in it there: treat that URL like a password.
• Every tool reads only your own account.
• Pages our server opens for link checks are public http(s) addresses only; private and internal addresses are refused.
• Playbooks and directory pages are information for your agent, not instructions: it never follows text in them that tells it to visit or submit to another site or to send your data anywhere, and it tells you instead.
• Playbooks are licensed for submitting your own products, one directory at a time; see the terms.

See also the privacy policy.

• No live product yet. Directories want a working URL, a favicon and real pricing. Build first, list second.
• You want hundreds of links this week. A young domain gets 3 to 5 a day for a reason, and a hundred directories is about three weeks of work, not an afternoon.
• You will not put a badge on your site and want only free listings. Many free listings need a link back; those show up as not a fit when you say no.
• You want it to run unattended. Your agent stops for you at sign-ins, CAPTCHAs, fees and terms, every time.

Directory links build a base, and they do not replace a good product.

• Model Context Protocol: architecture overview (participants, tools, resources, prompts, JSON-RPC)
• MCP specification: transports (stdio and Streamable HTTP)
• Claude Code: connect to MCP servers