directory

Server Details

A directory of product launch platforms: where your product qualifies and how each form is filled.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 56 days
Last Tested: 2026-10-12 21:28
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: FifthWye/submitmap-mcp
GitHub Stars: 276
Server Listing: SubmitMap MCP server

TDQS

A4.4/5.0

Scored 2026-09-26 15:35 across 11 tools

Disambiguation5/5

Each tool targets a distinct action and resource: project creation/update/list, platform search/get, qualification, planning, submission recording/playbook, and account identity. No two tools overlap in purpose; even the planning and qualification tools are clearly separated by role.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern (create_project, list_projects, qualify_project, plan_submissions, record_submission). Two exceptions—submission_playbook (noun_noun) and whoami (imperative)—are minor deviations but still readable and unambiguous.

Tool Count5/5

11 tools is well within the ideal 3–15 range and each tool earns its place for the server's purpose of managing product submissions to launch platforms. The count feels neither thin nor bloated.

Completeness4/5

The surface covers the full lifecycle: create/update/list projects, qualify, plan, search platforms, get details, generate playbooks, record submissions, and list submissions. Minor gaps exist (e.g., no explicit delete project or delete submission), but agents can work around them without dead ends.

Available Tools

11 tools

create_projectAInspect

Store 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.

ParametersJSON Schema

Name	Required	Description
`url`	No
`name`	Yes
`pack`	No
`facts`	No	Same shape qualify_project takes: stage, pricingModel, categories, and the booleans. It is also where the two answers that decide a run order live once the maker has given them (`goal`, `budget`, and `launchAt` if they named a date), which is what stops the next session asking again. Leave domainRating out: the url is measured against Ahrefs on the way in and the measured number is what gets stored, so a guess here is overwritten anyway.
`pitch`	No	One paragraph in the maker's own words.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: it persists facts (goal, budget, launchAt) to avoid re-asking, overwrites domainRating with measured data, and explains the dual image fields (logoUrl/logoFile). It also states that facts drive qualification and the pack is for pasting into forms. This is exceptionally transparent for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded with the core purpose and packed with valuable guidance. It could be trimmed, but every sentence adds context about how to fill the pack or when to ask questions. The structure flows from purpose to workflow to specifics, making it usable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex create tool with nested objects and many fields, the description covers how to gather info, what to fill, what to leave, and when to defer to update_project. It also clarifies the facts/pack split and mentions run-order persistence. Nothing essential for calling it correctly is missing, even without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the roles of pack and facts ('Facts drive what it qualifies for; the pack is what you will paste into forms later') and clarifies the logoUrl/logoFile distinction. However, it doesn't individually describe each of the many nested properties; the schema covers most of those. Given the low schema coverage (40%), the description adds significant high-level meaning but doesn't compensate for every parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Store a product on the account,' a specific verb and resource, and immediately contrasts itself with update_project by saying 'come back with update_project.' It clearly defines the tool's role as creating a project and distinguishes it from its sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit instructions on when to use the tool: before asking the maker anything, gather info from visible sources like README and package metadata. It also specifies when to use update_project instead ('Fill in as much as you can, leave the rest, and come back with update_project') and advises asking about images early. This is concrete, actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_platformAInspect

Full 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.

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	Platform slug, e.g. "product-hunt".
`brief`	No	Include agentPrompt and agentGotchas. This is the paid half and it spends a tracked platform, once, for good. Leave it out while you are deciding where to submit: eligibility, disqualifiers, gotchas, approval time and link type all come back either way. A platform this account has already spent a slot on is free to brief again, so re-reading one costs nothing.
`projectId`	No	Which project the brief is for, when brief is true. Omit it when the account has one project. A brief is one form being worked on for one product, and the project it belongs to cannot be issued another until this one has an outcome recorded.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does an excellent job: it discloses that the brief 'spends one of the account's tracked platforms' and that re-briefing an already-spent platform is free. It also explains the project constraint (a project cannot be issued another brief until the current one has an outcome recorded). These are non-obvious behavioral traits an agent must know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but every sentence carries meaningful information, from the core purpose to the cost model and the alternative tool. It front-loads the main value and then details the paid/optional part. Slightly dense but not wasteful; a 4 reflects efficient use of length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-oriented tool with 3 parameters and no output schema or annotations, the description covers everything an agent needs: what data is returned (including the optional brief fields), the cost/behavior, the project constraint, and when to use an alternative. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema itself is richly descriptive (explains the paid nature of brief, the project constraint, and when to omit projectId). The description text adds minimal additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it returns a 'full record for one platform' and enumerates the content (eligibility, disqualifiers, submission instructions, requirements, gotchas, expected outcome). It also distinguishes itself from siblings by mentioning the brief (agentPrompt/agentGotchas) and referencing submission_playbook, so an agent can clearly tell it apart from search_platforms and submission_playbook without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: it says to ask for the brief 'once the maker has decided to fill this form, not while you are still choosing between platforms' and that submission_playbook returns the same brief with values pre-filled for stored projects. It also states that eligibility and disqualifiers come back even without the brief, making the decision context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsAInspect

The 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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explains the output structure (facts, pack, missing items) and the role of the returned ID for other tools. It implies read-only behavior by describing a listing operation, though it does not explicitly state side effects or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the primary function and then delivering a crisp use case. Every phrase contributes to understanding the tool's purpose and usage, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the key return elements: projects with facts, pack, missing items, and an ID usable by other tools. It places the tool within the broader toolset. It could be slightly more explicit about the output format (e.g., array of projects) but that is easily inferred.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description need not explain input schema. The schema coverage is trivially 100% with an empty object. The description focuses on output semantics, which is appropriate for a parameterless list operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool lists all projects on the account, each with its facts (eligibility answers), pack (submission form fields), and missing pack items. It also distinguishes itself as the means to resolve ambiguous references to 'my project', setting it apart from sibling tools that require an ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'Call it whenever the maker says "my product" or "my project" without naming one' and explains that every other account tool takes the ID it returns. This clearly differentiates when to use this tool versus others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_submissionsAInspect

Where every submission for a project stands: what went out, when, what came back, and what is still waiting. This is the tool behind "check my submissions", "what did I submit", "did I ever submit to that one" and "how is my launch going", so answer those from here instead of asking the maker to remember. Start with list_projects if they have not named a project.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	No	Omit it when the account has one project, which is the free tier.

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the transparency burden. It strongly implies a read-only status lookup through 'Where every submission for a project stands' and 'what came back, and what is still waiting', and says the tool answers from stored data rather than memory. It does not explicitly state 'read-only' or discuss data freshness/authorization, but the behavior is clearly non-mutating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, every one earning its place: functionality, user-query mapping/guidance, and a prerequisite. No repetition of the schema or tool name, and the tone is engaging without bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description fully covers what data the user wants, which queries map to it, and what to do before calling it. It is complete for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage for the single parameter is 100% (projectId), so the baseline is 3. The description adds value by telling the agent to call list_projects first when no project is named, which indirectly clarifies when projectId is needed or can be omitted. It also reinforces the project context through example queries.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool as a status dashboard for project submissions, listing exactly what information it provides (what went out, when, what came back, what is waiting). It also distinguishes itself from sibling tools by explicitly positioning it as the answer to 'check my submissions' and similar queries, rather than record_submission or plan_submissions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit user language triggers ('check my submissions', 'what did I submit') and a concrete precondition: 'Start with list_projects if they have not named a project.' This tells the agent exactly when to call this tool and what to do first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_submissionsAInspect

Write the run order for a project: which platforms, in what sequence, and why each one is where it is. Anything already submitted to is dropped from the plan and named back to you in alreadySubmitted, because a plan is what is still ahead. Pass the platforms in the order they should be worked, with a short reason on each, plus a summary of the strategy. The plan appears on the maker's dashboard as a checklist that ticks itself off as submissions land. Anything already tracked is reordered rather than reset. Call it after qualify_project, using the recommended list it hands back, and if that response carried questions, put them to the maker before you plan: the order depends on the answers, and a plan written on an assumption is one they have to undo by hand. A plan costs nothing on any plan, so plan the whole run the product deserves rather than a short one sized to a guess about what the account can track.

ParametersJSON Schema

Name	Required	Description
`items`	Yes	In the order they should be submitted. First is next.
`summary`	No	Why this order, in a sentence or two. The maker reads this.
`checklist`	No	What the maker has to prepare before any of this can be submitted: the gallery, the demo video, a privacy policy page, a launch date. Write it from what the platforms in this plan actually demand and what the project is missing, not from a generic template. The maker ticks these off or throws them away on their dashboard, and anything they have already decided on keeps that decision when you plan again.
`projectId`	No	Omit it when the account has one project, which is the free tier.

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and delivers: already-submitted items are dropped and echoed back in `alreadySubmitted`, the plan renders as a dashboard checklist that ticks itself off, already-tracked items are reordered rather than reset, and planning costs nothing. It discloses return behavior, side effects, and idempotency — far more than the schema or annotations could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly 220 words, but every sentence contributes a distinct piece — purpose, return behavior, parameter handling, dashboard side effect, reorder-not-reset semantics, workflow scheduling, and cost. The purpose is front-loaded and there is no filler; the lenth is earned by the absence of annotations and an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 params, cross-tool workflow, no annotations, no output schema), the description is remarkably complete: it covers when to call, precenditions, what gets excluded, the key return field (`alreadySubmitted`), idempotent reordering, and cost. The only minor gap is the full return shape, and the most consequential part of it is explicitly named.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real value: items must be passed in work order with a short reason each, the summary is read by the maker, and the checklist must be 'written from what the platforms in this plan actually demand and what the project is missing, not from a generic template,' with decisions surviving re-plans. This meaningsfuly extends the schema's bare field names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence, 'Write the run order for a project: which platforms, in what sequence, and why each one is where it is,' gives a specific verb, resource, and scope in one breath. It also distinguishes itself from siblings by naming its workflow position ('Call it after qualify_project') and implying a contrast with record_submission (planning vs. recording).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Call it after qualify_project, using the `recommended` list it hands back' is explicit when-and-with-what guidance tied to a named sibling. The conditional 'if that response carried `questions`, put them to the maker before you plan: the order depends on the answers, and a plan written on an assumption is one they have to undo by hand' is an explicit when-not with a concrete consequence, and the already-submitted exclusion tells the agent what to leave out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qualify_projectAInspect

Given 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.

ParametersJSON Schema

Name	Required	Description
`url`	No
`docs`	No
`goal`	No	What this run is for, which decides the order of it. `already-live` means the product is out and wants listings, links and traffic now, so the run leads on fast approvals, dofollow links and strong domains. `launching-later` means there is a launch date ahead, so it leads on the platforms with months of queue. Ask the maker rather than guessing: absent, it is inferred from `stage` and the response says so.
`name`	No
`stage`	No
`budget`	No	Whether platforms that charge to list may appear in the run. Absent means `free-only`, which is the assumption that cannot cost anybody anything. `freemium` platforms are in the run either way: their submission is free, and paying to skip their queue is a separate question at the form.
`launchAt`	No	ISO 8601 date the maker is launching on, when they have named one.
`demoVideo`	No
`categories`	No	Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, an mcp server is `mcp`, a workspace with several of those means all of them. Then answer what it is commercially, which is a separate question and the one most runs lose platforms on: most launch boards say what they take by who ships it, not by what it runs on, so a subscription mobile app is `mobile` and `saas`, anything a solo maker or small team shipped is `indie`, and something sold to companies is `b2b`. Leaving those off does not make the run safer, it makes it shorter. Tags: agent-skill, ai, b2b, christian, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, turkish-founders, web.
`coverImage`	No
`logoSquare`	No
`openSignup`	No
`publicRepo`	No
`pricingPage`	No
`domainRating`	No
`pricingModel`	No
`livePublicUrl`	No
`privacyPolicy`	No
`monthlyTraffic`	No
`acceptsBacklink`	No
`payingCustomers`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the full burden. It discloses that all fields are optional, that unanswered fields become gaps, and that assumptions are made (e.g., free-only budget) and communicated back. It also explains how the order is decided (by goal and budget) and that it doesn't need an account. However, it doesn't explicitly state side effects like whether it creates anything or if it's read-only, but given no annotations, the description does a good job of setting expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense graduated. It front-loads the core purpose and then explains the ordering logic and the ask-retry-store flow. It includes important assumptions and the no-account note early. While it's verbose, every sentence adds value, especially the detailed `categories` guidance which is critical for correct usage. It could be trimmed but is not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 21 optional parameters and no output schema, the description covers the essential context: what it does, how to use it, what assumptions it makes, and what to do next (ask questions, call again, update_project). It doesn't detail return structure but the description states it returns `recommended` order. The complexity is high due to many parameters, but the description addresses the key ones and provides a coherent mental model.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 19%, but the description compensates somewhat: it explains how `goal` and `budget` affect ordering and assumptions, and it gives detailed guidance on `categories` (which is the most complex parameter). However, many parameters (like `docs`, `demoVideo`, `coverImage`) are simple boolean flags that are self-evident from the schema, so the description doesn't need to explain them. For those that are not obvious (like `acceptsBacklink`, `domainRating`), there's no added meaning, but the schema names are fairly clear on their own.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it qualifies a product against platforms, distinguishing between current qualification, potential qualification with missing items, and structural exclusion. It also explicitly introduces the `recommended` output and how it derives from goal and budget, which is a specific and valuable behavior that separates it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: it says to call this tool when you need to qualify a product, and to call it again after getting answers from the maker. It also directs storing answers with update_project, which is a clear alternative for persisting data. It mentions 'ask them, call again with the answers' which is actionable usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

record_submissionAInspect

Log what happened to the dashboard: the listing URL, when it was sent, when it goes live. Call it as soon as a submission lands, before you ask for the next brief, including when it is only queued for review, and including when you are not sure it landed: that is what attempted is for. The next brief on this project is refused until this call is made. A platform that needs the maker (a captcha, a login, a payment, a file, an address to confirm) is recorded as planned with a note saying what you need from them: that hands it back without claiming an outcome, and frees the run to carry on. If the live platform did not match what the brief said, put the difference in differsFromRecord. This costs nothing on any plan and no status costs more than another, so record what actually happened: the brief was what spent the tracked platform, and leaving the row wrong now only makes the run harder to follow.

ParametersJSON Schema

Name	Required	Description
`note`	No	Required with `planned`: what you need from the maker, in one line they can act on.
`status`	Yes	Use `attempted` when the form was sent and you cannot prove it arrived: the tab died, the connection dropped, the page never came back. It is not a lesser `submitted`, it is the honest one, and it carries the verification the platform record describes so somebody can settle it later. Never re-send a form to find out; every platform has a way to check without submitting twice. Use `planned`, with a note, to hand a platform back to the maker when it is waiting on them. A first record is `submitted`, `attempted` or `planned`: `live`, `rejected` and `needs_changes` come after one of those.
`launchAt`	No	ISO 8601, if it is scheduled.
`projectId`	No	Omit it when the account has one project, which is the free tier.
`listingUrl`	No	The product's URL on that platform.
`submittedAt`	No	ISO 8601.
`platformSlug`	Yes
`differsFromRecord`	No	Only when the live platform did not match the brief or the platform record: say what differed, in one line, as fact. A price where the record said free, a sign-in or phone check it did not mention, a field it did not list, a submit page that moved, an audience it does not accept. We read these and fix the record, so the next maker is not sent into the same wall. Leave it out when everything matched.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it delivers: it discloses side effects (next brief blocked), cost neutrality, the honest meaning of `attempted`, and that `planned` hands the platform back without claiming an outcome. This is far richer than a generic 'records a submission'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded with purpose and organized around call timing, statuses, and edge cases. Some repetition exists, but every sentence carries operational guidance for a nuanced tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with no annotations and no output schema, the description covers when to call, status selection, the required note for `planned`, mismatch handling, and downstream consequences. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 88%, so the baseline is 3. The description reinforces status semantics and `differsFromRecord`, but mostly applies what the schema already documents rather than adding new parameter-level syntax or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Log') and resource ('what happened to the dashboard'), then names the key fields. This clearly distinguishes record_submission from siblings like list_submissions and plan_submissions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit call conditions: as soon as a submission lands, before the next brief, including queued or uncertain cases. It also explains when to use `planned` and `differsFromRecord`, and states that the next brief is refused until this call is made.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_platformsAInspect

Search 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.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Fastest approval first (the default), or strongest domain first. Either way, a platform that publishes no approval time comes last rather than reading as instant.
`limit`	No	Return at most this many. The count is unaffected.
`query`	No	Free text matched against name, tagline, domain, slug and categories. A bare domain works: "startupfa.me" finds Startup Fame.
`pricing`	No
`category`	No	e.g. "AI tools", "Dev tools", "Web apps".
`dofollow`	No	Only platforms giving a dofollow backlink.
`projectId`	No	Omit it when the account has one project, which is the free tier.
`excludeTracked`	No	Leave out every platform this project has already been submitted to or planned for. Needs a token, and is what makes "one I have not done yet" answerable.
`maxApprovalDays`	No	Only platforms approving within this many days. Leaves out every platform that publishes no approval time, the same way a rating bound leaves out the unrated.
`maxDomainRating`	No	Only platforms up to this domain rating. The small, quick, unglamorous end of the directory, which is where a first submission usually belongs.
`minDomainRating`	No	Only platforms with at least this domain rating.
`requiresBacklink`	No	Filter on whether they demand a badge/link back.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does disclose useful behavioral traits: it searches the entire directory, respects a project tracker when a token is supplied, and returns summaries rather than full records. It could add more about auth/rate limits, but for a read-only search tool the behavior is adequately transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence pulls weight: the first lists what the tool searches and how to filter, the second gives the concrete user phrase and the authoritative source over model memory, the third explains the return type and the next tool. It is dense but well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For 12 optional parameters and no output commentary, the description tells the agent what to use, what to filter by, what the source of truth is, and what to call next for full details. It is complete enough though it stops short of describing return field shape or pagination behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high at 92%, so the input schea carries most of the parameter meaning. The description adds context about filtering concepts and the token-gated excludeTracked behavior, but mostly names parameters rather than revealing details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: it searches the SubmitMap directory of startup launch platforms. It also distinguishes itself from the get_platform sibling by noting it returns summaries rather than full records, and frames itself as the tool behind a concrete user request.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly describes when an agent should use it (whenever the user asks for a directory to submit to, and when asked about what is in the directory rather than memory). It also directs the agent to call get_platform for full record details including submission steps, which is a clear alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submission_playbookAInspect

Everything needed to submit a stored project to one platform, yourself, in the maker's browser: a preflight of what is still missing, the sign-in plan (on the first submission it carries a question for the maker: hand every login back to them, or use the Google address they write out, which you then pass back as signInAs), the pack values mapped onto the fields the form asks for, the steps, the gotchas, the agentGotchas (traps in the form itself), and the call to make afterwards. Read the preflight before opening a tab. One brief is out at a time per project: ask for the next platform only after record_submission has answered this one, because until then this tool refuses the next brief and names the one still open. Do not fetch briefs ahead or in parallel. This is the tool the free plan meters: it covers the same submissions the dashboard tracks, plus any platform the account has already sent to, and past that it says so and points at the upgrade rather than answering.

ParametersJSON Schema

Name	Required	Description
`signInAs`	No	The Google address the maker wrote out when they agreed you could sign in, or sign up, for them on this project, whether they said it when asked or before you started. Pass it on every call after they say it, so the answer travels with the work instead of living in your head. It belongs to one project: on a different one, ask again rather than sending the address you were given for the last. Leave it out if they have not written one: sign-in then goes back to them, which is the safe end.
`projectId`	No	Omit it when the account has one project, which is the free tier.
`platformSlug`	Yes

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It reveals the one-brief-per-project refusal behavior, the free-plan metering with upgrade redirection, the sign-in decision path, and the presence of gotchas/agentGotchas, all of which are non-obvious behavioral traits affecting invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is a single dense paragraph packed with caveats and embedded clauses, making it harder to scan. Every sentence does convey a distinct operational fact and the purpose is front-loaded, but restructuring into bullets or shorter sentences would improve clarity significantly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and no annotations, the description thoroughly covers what the tool returns, when it refuses, how metering works, and how sign-in is handled. The only minor gap is enumerating exact platform slugs, but the description points to account/platform context and related sibling tools, which is sufficient for an agent to proceed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Two of three parameters already have detailed schema descriptions, so the description adds marginal value for signInAs and projectId. The missing piece is platformSlug: the schema gives only a type, and the description never explains what platform slugs are valid or where to obtain them, leaving the one required parameter under-specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as the complete submission brief for a stored project on one platform and distinguishes it from record_submission, which is the follow-up call. However, it lacks an explicit verb like 'fetch' or 'return,' presenting the tool as a noun phrase ('Everything needed to submit...') rather than stating the core action directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives strong operational context: read the preflight before opening a tab, fetch one brief at a time, never fetch ahead or in parallel, and wait for record_submission before requesting the next platform. It does not, however, compare this tool against sibling planning tools like plan_submissions, so some alternative routing is left implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_projectAInspect

Fill in or correct a stored project. Facts and pack are merged into what is there, so you can add one field at a time as the maker answers.

ParametersJSON Schema

Name	Required	Description
`url`	No
`name`	No
`pack`	No
`facts`	No
`pitch`	No
`projectId`	No	Omit it when the account has one project, which is the free tier.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations to rely on, the description carries the burden of behavioral disclosurecars. It clearly reveals a critical non-obvious behavior: the merge semantics (facts and pack are merged into what is there), and that partial updates are supported. It does not detail error cases or return values, but the core merge behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the core purpose stated first and the key merge behavior second. There is no filler or repetition, making it highly efficient and appropriately scoped for an agent to consume.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex nested pack schema and no output schema, the description is lean but gives the essential merge behavior. However, it does not explain what 'facts' is, what 'pitch' means, or how the target project is identified beyond the schema's projectId description. These omissions leave moderate gaps for an agent trying to fully understand the tool's semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds only a generic mention of 'facts' and 'pack' and the merge behavior, which is useful but minimal. The schema's pack properties are richly described, but top-level parameters like url, name, facts, and pitch have no schema descriptions, and the tool description does not compensate for those gaps. The merge hint adds some meaning beyond the schema, so it is not completely deficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Fill in or correct') on a specific resource ('a stored project'), immediately distinguishing it from creation. The merge behavior is explicitly mentioned, making it clear this is an update/amendment tool rather than a create tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context by explaining that facts and pack are merged incrementally, making it suitable for adding one field at a time as the maker answers. It does not explicitly name alternatives like create_project, but the phrase 'stored project' and the sibling context imply the update scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

whoamiAInspect

Which 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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosure. It reveals what the tool returns (email, plan, existing holdings) and what it does not (plan limits), effectively implying a read-only identity operation. It doesn't explicitly state there are no side effects, but that's implied by the context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description packs useful information but is somewhat wordy, with a cryptic final sentence ('plan the whole run, and a limit says so at the write it stops') that may puzzle an AI agent. The core purpose is front-loaded, but the extra guidance could be tightened for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter identity tool, the description sufficiently covers what it does, what it returns, and when to use it. It even clarifies what it doesn't return (plan limits). It lacks exact output formatting details, but that's minor given the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no schema to elaborate. The description adds meaningful output context (email, plan, holdings) that goes beyond the empty input schema, though parameter-specific semantics are not applicable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: it identifies which SubmitMap account a token belongs to, including the associated email, plan, and held items. This is a specific identity-check function that is distinct from sibling tools like list_projects or create_project, which focus on other actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to call it: 'Call it first if you are unsure whether the maker is connected' and emphasizes it's the only way to distinguish accounts. It also advises against using it for plan limits ('It does not hand you the plan's limits'), but doesn't name alternative tools for that purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesSep 26, 2026

Changedcreate_project18 fields changed

changedInput schema / properties / facts / properties / categories / description

Previous value: -"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, an mcp server is `mcp`, a workspace with several of those means all of them. Then answer what it is commercially, which is a separate question and the one most runs lose platforms on: most launch boards say what they take by who ships it, not by what it runs on, so a subscription mobile app is `mobile` and `saas`, anything a solo maker or small team shipped is `indie`, and something sold to companies is `b2b`. Leaving those off does not make the run safer, it makes it shorter. Tags: agent-skill, ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, web."New value: +"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, an mcp server is `mcp`, a workspace with several of those means all of them. Then answer what it is commercially, which is a separate question and the one most runs lose platforms on: most launch boards say what they take by who ships it, not by what it runs on, so a subscription mobile app is `mobile` and `saas`, anything a solo maker or small team shipped is `indie`, and something sold to companies is `b2b`. Leaving those off does not make the run safer, it makes it shorter. Tags: agent-skill, ai, b2b, christian, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, turkish-founders, web."

changedInput schema / properties / facts / properties / categories / items / enum

Previous value: -[
-  "agent-skill",
-  "ai",
-  "b2b",
-  "community",
-  "content",
-  "design",
-  "dev",
-  "directory",
-  "extension",
-  "free",
-  "hardware",
-  "indie",
-  "local",
-  "marketing",
-  "marketplace",
-  "mcp",
-  "mobile",
-  "no-code",
-  "open-source",
-  "prelaunch",
-  "productivity",
-  "saas",
-  "web"
-]New value: +[
+  "agent-skill",
+  "ai",
+  "b2b",
+  "christian",
+  "community",
+  "content",
+  "design",
+  "dev",
+  "directory",
+  "extension",
+  "free",
+  "hardware",
+  "indie",
+  "local",
+  "marketing",
+  "marketplace",
+  "mcp",
+  "mobile",
+  "no-code",
+  "open-source",
+  "prelaunch",
+  "productivity",
+  "saas",
+  "turkish-founders",
+  "web"
+]

addedInput schema / properties / pack / properties / alternativeTo

Added value: +{
+  "description": "Well-known products this replaces, by name. Alternative directories will not take a listing without one. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / pack / properties / audience

Added value: +{
+  "description": "The people it is built for, like Freelancers or Small businesses, for the forms with a target-audience picker. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / pack / properties / buildStory

Added value: +{
+  "description": "Why and how it was built, with the real numbers, for community posts and maker showcases that want a story rather than a description. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / companyName

Added value: +{
+  "description": "The business behind the product, when it is not the product name. Review sites and B2B directories list the company. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / extendedDescription

Added value: +{
+  "description": "A full write-up of 400 words or more (about 2,500 characters) for the forms that set a minimum length. The long description above is shorter on purpose. Drafting it from the product is fine, but show the maker before it is used, because it goes out under their name. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / foundedYear

Added value: +{
+  "description": "Four digits. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / fundingStage

Added value: +{
+  "description": "Bootstrapped, or what was raised and at which stage. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / howItWorks

Added value: +{
+  "description": "Three short steps, one per line, under 200 characters each. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / pack / properties / location

Added value: +{
+  "description": "City and country, or country alone. Asked for as headquarters, and it decides the regional directories. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / makerName

Added value: +{
+  "description": "The person shown as the maker, first and last name, exactly as it should be printed on a listing. Launch boards and founder profiles require it. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / makerRole

Added value: +{
+  "description": "Their title, like Founder or Solo developer. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / monthlyRevenue

Added value: +{
+  "description": "MRR or a bracket like $0-1k, and only if the maker is happy for it to be public: forms that ask for it usually display it. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / monthlyVisitors

Added value: +{
+  "description": "A real figure from their analytics. Some directories make it a required number and print it. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / repoUrl

Added value: +{
+  "description": "The public repository, for open-source directories. Leave it empty for a closed-source product rather than pointing at something else.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / teamSize

Added value: +{
+  "description": "How many people work on it, as a number or a range like 2-10. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / techStack

Added value: +{
+  "description": "What it is built with, five at most, like Next.js or Postgres. Launch boards for builders make it a required step. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changedqualify_project2 fields changed

changedInput schema / properties / categories / description

Previous value: -"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, an mcp server is `mcp`, a workspace with several of those means all of them. Then answer what it is commercially, which is a separate question and the one most runs lose platforms on: most launch boards say what they take by who ships it, not by what it runs on, so a subscription mobile app is `mobile` and `saas`, anything a solo maker or small team shipped is `indie`, and something sold to companies is `b2b`. Leaving those off does not make the run safer, it makes it shorter. Tags: agent-skill, ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, web."New value: +"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, an mcp server is `mcp`, a workspace with several of those means all of them. Then answer what it is commercially, which is a separate question and the one most runs lose platforms on: most launch boards say what they take by who ships it, not by what it runs on, so a subscription mobile app is `mobile` and `saas`, anything a solo maker or small team shipped is `indie`, and something sold to companies is `b2b`. Leaving those off does not make the run safer, it makes it shorter. Tags: agent-skill, ai, b2b, christian, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, turkish-founders, web."

changedInput schema / properties / categories / items / enum

Previous value: -[
-  "agent-skill",
-  "ai",
-  "b2b",
-  "community",
-  "content",
-  "design",
-  "dev",
-  "directory",
-  "extension",
-  "free",
-  "hardware",
-  "indie",
-  "local",
-  "marketing",
-  "marketplace",
-  "mcp",
-  "mobile",
-  "no-code",
-  "open-source",
-  "prelaunch",
-  "productivity",
-  "saas",
-  "web"
-]New value: +[
+  "agent-skill",
+  "ai",
+  "b2b",
+  "christian",
+  "community",
+  "content",
+  "design",
+  "dev",
+  "directory",
+  "extension",
+  "free",
+  "hardware",
+  "indie",
+  "local",
+  "marketing",
+  "marketplace",
+  "mcp",
+  "mobile",
+  "no-code",
+  "open-source",
+  "prelaunch",
+  "productivity",
+  "saas",
+  "turkish-founders",
+  "web"
+]

Changedupdate_project16 fields changed

addedInput schema / properties / pack / properties / alternativeTo

Added value: +{
+  "description": "Well-known products this replaces, by name. Alternative directories will not take a listing without one. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / pack / properties / audience

Added value: +{
+  "description": "The people it is built for, like Freelancers or Small businesses, for the forms with a target-audience picker. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / pack / properties / buildStory

Added value: +{
+  "description": "Why and how it was built, with the real numbers, for community posts and maker showcases that want a story rather than a description. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / companyName

Added value: +{
+  "description": "The business behind the product, when it is not the product name. Review sites and B2B directories list the company. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / extendedDescription

Added value: +{
+  "description": "A full write-up of 400 words or more (about 2,500 characters) for the forms that set a minimum length. The long description above is shorter on purpose. Drafting it from the product is fine, but show the maker before it is used, because it goes out under their name. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / foundedYear

Added value: +{
+  "description": "Four digits. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / fundingStage

Added value: +{
+  "description": "Bootstrapped, or what was raised and at which stage. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / howItWorks

Added value: +{
+  "description": "Three short steps, one per line, under 200 characters each. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / pack / properties / location

Added value: +{
+  "description": "City and country, or country alone. Asked for as headquarters, and it decides the regional directories. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / makerName

Added value: +{
+  "description": "The person shown as the maker, first and last name, exactly as it should be printed on a listing. Launch boards and founder profiles require it. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / makerRole

Added value: +{
+  "description": "Their title, like Founder or Solo developer. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / monthlyRevenue

Added value: +{
+  "description": "MRR or a bracket like $0-1k, and only if the maker is happy for it to be public: forms that ask for it usually display it. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / monthlyVisitors

Added value: +{
+  "description": "A real figure from their analytics. Some directories make it a required number and print it. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / repoUrl

Added value: +{
+  "description": "The public repository, for open-source directories. Leave it empty for a closed-source product rather than pointing at something else.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / teamSize

Added value: +{
+  "description": "How many people work on it, as a number or a range like 2-10. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

addedInput schema / properties / pack / properties / techStack

Added value: +{
+  "description": "What it is built with, five at most, like Next.js or Postgres. Launch boards for builders make it a required step. Only what the maker told you, never a guess. When a form requires it and it is empty here, ask the maker once, then save the answer with update_project so no other form stops on it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

1 tool updateSep 26, 2026

Changedrecord_submission1 field changed

addedInput schema / properties / differsFromRecord

Added value: +{
+  "description": "Only when the live platform did not match the brief or the platform record: say what differed, in one line, as fact. A price where the record said free, a sign-in or phone check it did not mention, a field it did not list, a submit page that moved, an audience it does not accept. We read these and fix the record, so the next maker is not sent into the same wall. Leave it out when everything matched.",
+  "type": "string"
+}

2 tool updatesSep 16, 2026

Changedget_platform1 field changed

addedInput schema / properties / projectId

Added value: +{
+  "description": "Which project the brief is for, when brief is true. Omit it when the account has one project. A brief is one form being worked on for one product, and the project it belongs to cannot be issued another until this one has an outcome recorded.",
+  "type": "string"
+}

Changedrecord_submission2 fields changed

addedInput schema / properties / note / description

Added value: +"Required with `planned`: what you need from the maker, in one line they can act on."

changedInput schema / properties / status / description

Previous value: -"Use `attempted` when the form was sent and you cannot prove it arrived: the tab died, the connection dropped, the page never came back. It is not a lesser `submitted`, it is the honest one, and it carries the verification the platform record describes so somebody can settle it later. Never re-send a form to find out; every platform has a way to check without submitting twice."New value: +"Use `attempted` when the form was sent and you cannot prove it arrived: the tab died, the connection dropped, the page never came back. It is not a lesser `submitted`, it is the honest one, and it carries the verification the platform record describes so somebody can settle it later. Never re-send a form to find out; every platform has a way to check without submitting twice. Use `planned`, with a note, to hand a platform back to the maker when it is waiting on them. A first record is `submitted`, `attempted` or `planned`: `live`, `rejected` and `needs_changes` come after one of those."

1 tool updateSep 14, 2026

Changedsubmission_playbook1 field changed

changedInput schema / properties / signInAs / description

Previous value: -"The Google address the maker wrote out when they agreed you could sign in for them on this project. Pass it on every call after they say it, so the answer travels with the work instead of living in your head. It belongs to one project: on a different one, ask again rather than sending the address you were given for the last. Leave it out if they have not written one: sign-in then goes back to them, which is the safe end."New value: +"The Google address the maker wrote out when they agreed you could sign in, or sign up, for them on this project, whether they said it when asked or before you started. Pass it on every call after they say it, so the answer travels with the work instead of living in your head. It belongs to one project: on a different one, ask again rather than sending the address you were given for the last. Leave it out if they have not written one: sign-in then goes back to them, which is the safe end."

1 tool updateSep 1, 2026

Changedget_platform1 field changed

addedInput schema / properties / brief

Added value: +{
+  "description": "Include agentPrompt and agentGotchas. This is the paid half and it spends a tracked platform, once, for good. Leave it out while you are deciding where to submit: eligibility, disqualifiers, gotchas, approval time and link type all come back either way. A platform this account has already spent a slot on is free to brief again, so re-reading one costs nothing.",
+  "type": "boolean"
+}

2 tool updatesAug 30, 2026

Changedcreate_project1 field changed

changedInput schema / properties / facts / properties / categories / description

Previous value: -"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: agent-skill, ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, web."New value: +"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, an mcp server is `mcp`, a workspace with several of those means all of them. Then answer what it is commercially, which is a separate question and the one most runs lose platforms on: most launch boards say what they take by who ships it, not by what it runs on, so a subscription mobile app is `mobile` and `saas`, anything a solo maker or small team shipped is `indie`, and something sold to companies is `b2b`. Leaving those off does not make the run safer, it makes it shorter. Tags: agent-skill, ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, web."

Changedqualify_project1 field changed

changedInput schema / properties / categories / description

Previous value: -"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: agent-skill, ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, web."New value: +"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, an mcp server is `mcp`, a workspace with several of those means all of them. Then answer what it is commercially, which is a separate question and the one most runs lose platforms on: most launch boards say what they take by who ships it, not by what it runs on, so a subscription mobile app is `mobile` and `saas`, anything a solo maker or small team shipped is `indie`, and something sold to companies is `b2b`. Leaving those off does not make the run safer, it makes it shorter. Tags: agent-skill, ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, web."

2 tool updatesAug 29, 2026

Changedcreate_project2 fields changed

changedInput schema / properties / facts / properties / categories / description

Previous value: -"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mobile, no-code, open-source, prelaunch, productivity, saas, web."New value: +"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: agent-skill, ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, web."

changedInput schema / properties / facts / properties / categories / items / enum

Previous value: -[
-  "ai",
-  "b2b",
-  "community",
-  "content",
-  "design",
-  "dev",
-  "directory",
-  "extension",
-  "free",
-  "hardware",
-  "indie",
-  "local",
-  "marketing",
-  "marketplace",
-  "mobile",
-  "no-code",
-  "open-source",
-  "prelaunch",
-  "productivity",
-  "saas",
-  "web"
-]New value: +[
+  "agent-skill",
+  "ai",
+  "b2b",
+  "community",
+  "content",
+  "design",
+  "dev",
+  "directory",
+  "extension",
+  "free",
+  "hardware",
+  "indie",
+  "local",
+  "marketing",
+  "marketplace",
+  "mcp",
+  "mobile",
+  "no-code",
+  "open-source",
+  "prelaunch",
+  "productivity",
+  "saas",
+  "web"
+]

Changedqualify_project2 fields changed

changedInput schema / properties / categories / description

Previous value: -"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mobile, no-code, open-source, prelaunch, productivity, saas, web."New value: +"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: agent-skill, ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mcp, mobile, no-code, open-source, prelaunch, productivity, saas, web."

changedInput schema / properties / categories / items / enum

Previous value: -[
-  "ai",
-  "b2b",
-  "community",
-  "content",
-  "design",
-  "dev",
-  "directory",
-  "extension",
-  "free",
-  "hardware",
-  "indie",
-  "local",
-  "marketing",
-  "marketplace",
-  "mobile",
-  "no-code",
-  "open-source",
-  "prelaunch",
-  "productivity",
-  "saas",
-  "web"
-]New value: +[
+  "agent-skill",
+  "ai",
+  "b2b",
+  "community",
+  "content",
+  "design",
+  "dev",
+  "directory",
+  "extension",
+  "free",
+  "hardware",
+  "indie",
+  "local",
+  "marketing",
+  "marketplace",
+  "mcp",
+  "mobile",
+  "no-code",
+  "open-source",
+  "prelaunch",
+  "productivity",
+  "saas",
+  "web"
+]

2 tool updatesAug 27, 2026

Changedcreate_project1 field changed

changedInput schema / properties / facts / description

Previous value: -"Same shape qualify_project takes: stage, pricingModel, categories, and the booleans. Leave domainRating out: the url is measured against Ahrefs on the way in and the measured number is what gets stored, so a guess here is overwritten anyway."New value: +"Same shape qualify_project takes: stage, pricingModel, categories, and the booleans. It is also where the two answers that decide a run order live once the maker has given them (`goal`, `budget`, and `launchAt` if they named a date), which is what stops the next session asking again. Leave domainRating out: the url is measured against Ahrefs on the way in and the measured number is what gets stored, so a guess here is overwritten anyway."

Changedqualify_project3 fields changed

addedInput schema / properties / budget

Added value: +{
+  "description": "Whether platforms that charge to list may appear in the run. Absent means `free-only`, which is the assumption that cannot cost anybody anything. `freemium` platforms are in the run either way: their submission is free, and paying to skip their queue is a separate question at the form.",
+  "enum": [
+    "free-only",
+    "will-pay"
+  ],
+  "type": "string"
+}

addedInput schema / properties / goal

Added value: +{
+  "description": "What this run is for, which decides the order of it. `already-live` means the product is out and wants listings, links and traffic now, so the run leads on fast approvals, dofollow links and strong domains. `launching-later` means there is a launch date ahead, so it leads on the platforms with months of queue. Ask the maker rather than guessing: absent, it is inferred from `stage` and the response says so.",
+  "enum": [
+    "already-live",
+    "launching-later"
+  ],
+  "type": "string"
+}

addedInput schema / properties / launchAt

Added value: +{
+  "description": "ISO 8601 date the maker is launching on, when they have named one.",
+  "type": "string"
+}

1 tool updateAug 24, 2026

Changedsearch_platforms1 field changed

changedInput schema / properties / query / description

Previous value: -"Free text matched against name, tagline and categories."New value: +"Free text matched against name, tagline, domain, slug and categories. A bare domain works: \"startupfa.me\" finds Startup Fame."

2 tool updatesAug 22, 2026

Changedcreate_project1 field changed

addedInput schema / properties / pack / properties / xHandle

Added value: +{
+  "description": "Without the @. Launch boards ask for it and some make it a required field, so a pack without one stalls at the last step of a form that is otherwise finished. Fill it only with an account you hold: it is printed on the listing as the maker, and a handle typed to satisfy a validator credits whoever really owns it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

Changedupdate_project1 field changed

addedInput schema / properties / pack / properties / xHandle

Added value: +{
+  "description": "Without the @. Launch boards ask for it and some make it a required field, so a pack without one stalls at the last step of a form that is otherwise finished. Fill it only with an account you hold: it is printed on the listing as the maker, and a handle typed to satisfy a validator credits whoever really owns it. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

1 tool updateAug 20, 2026

Changedcreate_project1 field changed

changedInput schema / properties / facts / description

Previous value: -"Same shape qualify_project takes: stage, pricingModel, categories, and the booleans."New value: +"Same shape qualify_project takes: stage, pricingModel, categories, and the booleans. Leave domainRating out: the url is measured against Ahrefs on the way in and the measured number is what gets stored, so a guess here is overwritten anyway."

3 tool updatesAug 19, 2026

Changedcreate_project8 fields changed

addedInput schema / properties / pack / properties / coverFile

Added value: +{
+  "description": "The same cover as a file on the machine your agent runs on, for the forms that upload it.",
+  "type": "string"
+}

changedInput schema / properties / pack / properties / coverUrl / description

Previous value: -"1270x760, the size every gallery accepts. A URL or a local path."New value: +"1270x760, the size every gallery accepts. The public address of it."

addedInput schema / properties / pack / properties / demoVideoFile

Added value: +{
+  "description": "The video as a file on the machine your agent runs on, for the few platforms that upload rather than embed.",
+  "type": "string"
+}

changedInput schema / properties / pack / properties / demoVideoUrl / description

Previous value: -"Optional almost everywhere, decisive on a few. A URL or a local path."New value: +"Optional almost everywhere, decisive on a few. A watch page or a hosted file."

addedInput schema / properties / pack / properties / galleryFiles

Added value: +{
+  "description": "The same frames as files on the machine your agent runs on, in the same order, one per line. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / pack / properties / galleryUrls / description

Previous value: -"Three to five, first one a poster slide. URLs or local paths. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."New value: +"Three to five, first one a poster slide. Public addresses, one per line. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

addedInput schema / properties / pack / properties / logoFile

Added value: +{
+  "description": "The same logo as a file on the machine your agent runs on, like /Users/you/product/logo-512.png. This is the one a submission form uploads, because a file picker cannot be handed a link. It stays a path: nothing can display it, here or anywhere else.",
+  "type": "string"
+}

changedInput schema / properties / pack / properties / logoUrl / description

Previous value: -"Square, transparent, 512px or better. A URL, or the path to the file on the machine your agent runs on."New value: +"Square, transparent, 512px or better. The public address of the image: forms with a logo URL field take this one, and it is what shows on your dashboard."

Changedsearch_platforms2 fields changed

changedInput schema / properties / maxApprovalDays / description

Previous value: -"Only platforms approving within this many days."New value: +"Only platforms approving within this many days. Leaves out every platform that publishes no approval time, the same way a rating bound leaves out the unrated."

changedInput schema / properties / sort / description

Previous value: -"Fastest approval first (the default), or strongest domain first."New value: +"Fastest approval first (the default), or strongest domain first. Either way, a platform that publishes no approval time comes last rather than reading as instant."

Changedupdate_project8 fields changed

addedInput schema / properties / pack / properties / coverFile

Added value: +{
+  "description": "The same cover as a file on the machine your agent runs on, for the forms that upload it.",
+  "type": "string"
+}

changedInput schema / properties / pack / properties / coverUrl / description

Previous value: -"1270x760, the size every gallery accepts. A URL or a local path."New value: +"1270x760, the size every gallery accepts. The public address of it."

addedInput schema / properties / pack / properties / demoVideoFile

Added value: +{
+  "description": "The video as a file on the machine your agent runs on, for the few platforms that upload rather than embed.",
+  "type": "string"
+}

changedInput schema / properties / pack / properties / demoVideoUrl / description

Previous value: -"Optional almost everywhere, decisive on a few. A URL or a local path."New value: +"Optional almost everywhere, decisive on a few. A watch page or a hosted file."

addedInput schema / properties / pack / properties / galleryFiles

Added value: +{
+  "description": "The same frames as files on the machine your agent runs on, in the same order, one per line. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / pack / properties / galleryUrls / description

Previous value: -"Three to five, first one a poster slide. URLs or local paths. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."New value: +"Three to five, first one a poster slide. Public addresses, one per line. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

addedInput schema / properties / pack / properties / logoFile

Added value: +{
+  "description": "The same logo as a file on the machine your agent runs on, like /Users/you/product/logo-512.png. This is the one a submission form uploads, because a file picker cannot be handed a link. It stays a path: nothing can display it, here or anywhere else.",
+  "type": "string"
+}

changedInput schema / properties / pack / properties / logoUrl / description

Previous value: -"Square, transparent, 512px or better. A URL, or the path to the file on the machine your agent runs on."New value: +"Square, transparent, 512px or better. The public address of the image: forms with a logo URL field take this one, and it is what shows on your dashboard."

4 tool updatesAug 17, 2026

Changedcreate_project1 field changed

addedInput schema / properties / pack / properties / contactEmail

Added value: +{
+  "description": "The address you submit under. Most forms ask for one, and it is where the confirmation link lands, so a mailbox nobody opens stalls the submission. Per product, not per person: a client launch and a side project rarely want the same address, and the one you use here is the one the listing belongs to. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

Changedrecord_submission2 fields changed

addedInput schema / properties / status / description

Added value: +"Use `attempted` when the form was sent and you cannot prove it arrived: the tab died, the connection dropped, the page never came back. It is not a lesser `submitted`, it is the honest one, and it carries the verification the platform record describes so somebody can settle it later. Never re-send a form to find out; every platform has a way to check without submitting twice."

changedInput schema / properties / status / enum

Previous value: -[
-  "planned",
-  "submitted",
-  "live",
-  "rejected",
-  "needs_changes"
-]New value: +[
+  "planned",
+  "attempted",
+  "submitted",
+  "live",
+  "rejected",
+  "needs_changes"
+]

Changedsearch_platforms6 fields changed

addedInput schema / properties / excludeTracked

Added value: +{
+  "description": "Leave out every platform this project has already been submitted to or planned for. Needs a token, and is what makes \"one I have not done yet\" answerable.",
+  "type": "boolean"
+}

addedInput schema / properties / limit

Added value: +{
+  "description": "Return at most this many. The count is unaffected.",
+  "type": "number"
+}

addedInput schema / properties / maxDomainRating

Added value: +{
+  "description": "Only platforms up to this domain rating. The small, quick, unglamorous end of the directory, which is where a first submission usually belongs.",
+  "type": "number"
+}

addedInput schema / properties / minDomainRating

Added value: +{
+  "description": "Only platforms with at least this domain rating.",
+  "type": "number"
+}

addedInput schema / properties / projectId

Added value: +{
+  "description": "Omit it when the account has one project, which is the free tier.",
+  "type": "string"
+}

addedInput schema / properties / sort

Added value: +{
+  "description": "Fastest approval first (the default), or strongest domain first.",
+  "enum": [
+    "approvalDays",
+    "domainRating"
+  ],
+  "type": "string"
+}

Changedupdate_project1 field changed

addedInput schema / properties / pack / properties / contactEmail

Added value: +{
+  "description": "The address you submit under. Most forms ask for one, and it is where the confirmation link lands, so a mailbox nobody opens stalls the submission. Per product, not per person: a client launch and a side project rarely want the same address, and the one you use here is the one the listing belongs to. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead.",
+  "type": "string"
+}

3 tool updatesAug 13, 2026

Changedcreate_project10 fields changed

changedInput schema / properties / pack / properties / categories / description

Previous value: -"Three at most, in the platform's own vocabulary where it has one."New value: +"Three at most, in the platform's own vocabulary where it has one. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / firstComment / description

Previous value: -"Product Hunt and Show HN only, and it matters there."New value: +"Product Hunt and Show HN only, and it matters there. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / galleryUrls / description

Previous value: -"Three to five, first one a poster slide. URLs or local paths."New value: +"Three to five, first one a poster slide. URLs or local paths. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / longDescription / description

Previous value: -"Two or three paragraphs, for the forms with room."New value: +"Two or three paragraphs, for the forms with room. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / makerBio / description

Previous value: -"Asked for by launch platforms, not by plain directories. Max 160 characters."New value: +"Asked for by launch platforms, not by plain directories. Max 160 characters. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / name / description

Previous value: -"Exactly as it should appear in a listing."New value: +"Exactly as it should appear in a listing. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / oneLiner / description

Previous value: -"A sentence that works as a meta description. Max 140 characters."New value: +"A sentence that works as a meta description. Max 140 characters. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / pricing / description

Previous value: -"What it costs, in a sentence a form can take."New value: +"What it costs, in a sentence a form can take. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / shortDescription / description

Previous value: -"The paragraph most directory forms ask for. Max 260 characters."New value: +"The paragraph most directory forms ask for. Max 260 characters. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / tagline / description

Previous value: -"One line, no product name, no full stop. Max 60 characters."New value: +"One line, no product name, no full stop. Max 60 characters. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

Changedsubmission_playbook1 field changed

addedInput schema / properties / signInAs

Added value: +{
+  "description": "The Google address the maker wrote out when they agreed you could sign in for them on this project. Pass it on every call after they say it, so the answer travels with the work instead of living in your head. It belongs to one project: on a different one, ask again rather than sending the address you were given for the last. Leave it out if they have not written one: sign-in then goes back to them, which is the safe end.",
+  "type": "string"
+}

Changedupdate_project10 fields changed

changedInput schema / properties / pack / properties / categories / description

Previous value: -"Three at most, in the platform's own vocabulary where it has one."New value: +"Three at most, in the platform's own vocabulary where it has one. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / firstComment / description

Previous value: -"Product Hunt and Show HN only, and it matters there."New value: +"Product Hunt and Show HN only, and it matters there. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / galleryUrls / description

Previous value: -"Three to five, first one a poster slide. URLs or local paths."New value: +"Three to five, first one a poster slide. URLs or local paths. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / longDescription / description

Previous value: -"Two or three paragraphs, for the forms with room."New value: +"Two or three paragraphs, for the forms with room. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / makerBio / description

Previous value: -"Asked for by launch platforms, not by plain directories. Max 160 characters."New value: +"Asked for by launch platforms, not by plain directories. Max 160 characters. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / name / description

Previous value: -"Exactly as it should appear in a listing."New value: +"Exactly as it should appear in a listing. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / oneLiner / description

Previous value: -"A sentence that works as a meta description. Max 140 characters."New value: +"A sentence that works as a meta description. Max 140 characters. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / pricing / description

Previous value: -"What it costs, in a sentence a form can take."New value: +"What it costs, in a sentence a form can take. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / shortDescription / description

Previous value: -"The paragraph most directory forms ask for. Max 260 characters."New value: +"The paragraph most directory forms ask for. Max 260 characters. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

changedInput schema / properties / pack / properties / tagline / description

Previous value: -"One line, no product name, no full stop. Max 60 characters."New value: +"One line, no product name, no full stop. Max 60 characters. Write it as the maker would: no em dashes, which read as machine-written and get the whole listing dismissed. Use a comma, a colon, a semicolon, brackets or a full stop instead."

2 tool updatesAug 13, 2026

Changedcreate_project2 fields changed

changedInput schema / properties / facts / properties / categories / description

Previous value: -"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: ai, b2b, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mobile, no-code, open-source, prelaunch, productivity, saas, web."New value: +"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mobile, no-code, open-source, prelaunch, productivity, saas, web."

changedInput schema / properties / facts / properties / categories / items / enum

Previous value: -[
-  "ai",
-  "b2b",
-  "content",
-  "design",
-  "dev",
-  "directory",
-  "extension",
-  "free",
-  "hardware",
-  "indie",
-  "local",
-  "marketing",
-  "marketplace",
-  "mobile",
-  "no-code",
-  "open-source",
-  "prelaunch",
-  "productivity",
-  "saas",
-  "web"
-]New value: +[
+  "ai",
+  "b2b",
+  "community",
+  "content",
+  "design",
+  "dev",
+  "directory",
+  "extension",
+  "free",
+  "hardware",
+  "indie",
+  "local",
+  "marketing",
+  "marketplace",
+  "mobile",
+  "no-code",
+  "open-source",
+  "prelaunch",
+  "productivity",
+  "saas",
+  "web"
+]

Changedqualify_project2 fields changed

changedInput schema / properties / categories / description

Previous value: -"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: ai, b2b, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mobile, no-code, open-source, prelaunch, productivity, saas, web."New value: +"Every audience and form factor this product belongs to, not just the main one. A product is often several at once, and one missing tag is one directory it never hears about: a repository holding a browser extension and a web app is `extension` and `web`, and an open-source AI dev tool is `open-source`, `ai` and `dev`. Look at what the product actually ships before you answer: a manifest.json means `extension`, an ios or android target means `mobile`, a public repository means `open-source`, a workspace with several of those means all of them. Tags: ai, b2b, community, content, design, dev, directory, extension, free, hardware, indie, local, marketing, marketplace, mobile, no-code, open-source, prelaunch, productivity, saas, web."

changedInput schema / properties / categories / items / enum

Previous value: -[
-  "ai",
-  "b2b",
-  "content",
-  "design",
-  "dev",
-  "directory",
-  "extension",
-  "free",
-  "hardware",
-  "indie",
-  "local",
-  "marketing",
-  "marketplace",
-  "mobile",
-  "no-code",
-  "open-source",
-  "prelaunch",
-  "productivity",
-  "saas",
-  "web"
-]New value: +[
+  "ai",
+  "b2b",
+  "community",
+  "content",
+  "design",
+  "dev",
+  "directory",
+  "extension",
+  "free",
+  "hardware",
+  "indie",
+  "local",
+  "marketing",
+  "marketplace",
+  "mobile",
+  "no-code",
+  "open-source",
+  "prelaunch",
+  "productivity",
+  "saas",
+  "web"
+]

11 tool updatesAug 13, 2026
- First observedcreate_project
- First observedget_platform
- First observedlist_projects
- First observedlist_submissions
- First observedplan_submissions
- First observedqualify_project
- First observedrecord_submission
- First observedsearch_platforms
- First observedsubmission_playbook
- First observedupdate_project
- First observedwhoami

Related MCP Connectors

SubmitMyStartup A
com.submitmystartup
Find where to submit your startup. Searches a free list of directories with real submission results.
Marketing Search
51
SaaSCity A
io.saascity
Audit your site, pick from 1,600+ launch directories by DR and link type, and list on SaaSCity.
Marketing
131
Uneed A
best.uneed
Search uneed.best's curated product directory: launches, rankings, deals and alternatives
E-commerce & Retail Search
111
headlesshunt
com.headlesshunt
Launch board run by AI agents: find tools by what they do, launch products, vote, comment, discuss.
141

Related MCP Servers

ProdCheck
Testing & QA Tools Developer Tools Security
FarzamHabibi
A
license
Not graded
quality
A
maintenance
The checklist you wish someone had given you before launch.
Updated a month ago (2026-09-15 06:51 UTC)
203 npm
15
MIT
saascity-mcp
Marketing Product Management
nyyhao
A
license
Not graded
quality
C
maintenance
Enables an AI agent to audit a website for launch readiness, find suitable startup/SaaS/AI directories using filters like DR and link type, and submit product listings to SaaSCity as drafts.
Updated 19 days ago (2026-09-23 23:15 UTC)
MIT
LaunchOnIt MCP Serverofficial
Marketing Search Web Scraping
LaunchOnIt
A
license
Not graded
quality
C
maintenance
Enables AI agents to search launched software products, inspect weekly leaderboards and Hall of Fame winners, check upcoming launch calendar availability, and retrieve full product details. It can also draft a new product listing from a supplied URL, returning a private review link without publishing or charging.
Updated 11 days ago (2026-10-02 13:17 UTC)
1
MIT
AI Product Index
Search Open Data
110kc3
F
license
Not graded
quality
A
maintenance
Machine-readable directory of AI products that register themselves, plus an agent-readability grader for any URL.
Updated 2 days ago (2026-10-10 19:57 UTC)
1
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

LaunchOnIt MCP Serverofficial

Glama MCP Gateway

Resources