toolfound

Submit a product for launch

toolfound_submit_product

Submit a product to launch on toolfound.com — the launch platform where the whole launch runs agent-native, end to end. A logo URL is optional; without one the site's own icon is used. One call returns everything: your submission id, ownership-verification instructions (mandatory — DNS TXT, meta tag, or email magic link), transparent queue position and assigned launch date, and the live free-slots counter (launches are free). AGENTS: you do not need inbox access — the verify_token in this response works with the meta_tag or dns_txt method via toolfound_verify_submission, and toolfound_check_verification dry-runs the checks; the emailed magic link is a human fallback that can also be completed later from the dashboard. Description renders as plain-text paragraphs on the listing page: 100–200 words reads best, and entries over 100 words qualify for search-engine indexing. Resubmitting a known URL returns the existing submission (idempotent).

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The product's public https URL (e.g. https://yourproduct.com).
`name`	No	Product name (optional — drafted from the site if omitted).
`email`	Yes	Maker's email — receives the verification link, queue updates, and launch results.
`tagline`	No	One-line tagline (optional).
`logo_url`	No	Direct public URL for the product's real logo (PNG, JPG, GIF or WebP; max 2MB). Optional; defaults to the site's icon.
`x_handle`	No	The maker's X (Twitter) handle, e.g. @yourproduct (optional). Shown on the listing. If the listing wins that UTC day, @toolfoundcom tags this handle the next morning. We do not tag every launch.
`price_usd`	No	Optional starting price in USD (e.g. the cheapest paid plan). Only used when pricing_model is 'paid', 'freemium', or 'trial'.
`description`	No	Longer description (optional — you can edit later).
`pricing_model`	No	The product's pricing model (optional, but strongly recommended — captured now instead of after claim so the listing never sits at 'Pricing unlisted').
`preferred_launch_date`	No	Preferred launch date, YYYY-MM-DD (optional). Must be within the next 180 days. Free launches cannot take today or tomorrow: a date earlier than the next free date is moved to it (a later date is honoured). Use toolfound_get_launch_calendar to find open seats. If that day is full by the time you verify, the earliest open day is assigned and reported. Omit to get the earliest open date automatically.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

changedInput schema / properties / logo_url / description

Previous value: -"Direct public URL for the product's real logo (PNG, JPG, GIF or WebP; max 2MB). Required for new submissions."New value: +"Direct public URL for the product's real logo (PNG, JPG, GIF or WebP; max 2MB). Optional; defaults to the site's icon."

Changed1 schema field changedOct 6, 2026

changedInput schema / properties / preferred_launch_date / description

Previous value: -"Preferred launch date, YYYY-MM-DD (optional). Must be within the next 180 days; use toolfound_get_launch_calendar to find open featured seats. If that day is full by the time you verify, the earliest open day is assigned and reported. Omit to get the earliest open date automatically."New value: +"Preferred launch date, YYYY-MM-DD (optional). Must be within the next 180 days. Free launches cannot take today or tomorrow: a date earlier than the next free date is moved to it (a later date is honoured). Use toolfound_get_launch_calendar to find open seats. If that day is full by the time you verify, the earliest open day is assigned and reported. Omit to get the earliest open date automatically."

Changed1 schema field changedSep 11, 2026

addedInput schema / properties / logo_url

Added value: +{
+  "description": "Direct public URL for the product's real logo (PNG, JPG, GIF or WebP; max 2MB). Required for new submissions.",
+  "maxLength": 2000,
+  "minLength": 1,
+  "type": "string"
+}

Changed1 schema field changedSep 8, 2026

changedInput schema / properties / x_handle / description

Previous value: -"The maker's X (Twitter) handle, e.g. @yourproduct (optional). Shown on the listing; the launch-day email includes a ready share kit (copy + badge) to post from this handle, and we tag this handle from the toolfound X account on launch day."New value: +"The maker's X (Twitter) handle, e.g. @yourproduct (optional). Shown on the listing. If the listing wins that UTC day, @toolfoundcom tags this handle the next morning. We do not tag every launch."

Changed1 schema field changedSep 6, 2026

changedInput schema / properties / x_handle / description

Previous value: -"The maker's X (Twitter) handle, e.g. @yourproduct (optional). Shown on the listing; the launch-day email includes a ready share kit (copy + badge) to post from this handle."New value: +"The maker's X (Twitter) handle, e.g. @yourproduct (optional). Shown on the listing; the launch-day email includes a ready share kit (copy + badge) to post from this handle, and we tag this handle from the toolfound X account on launch day."

Changed2 schema fields changedAug 31, 2026

addedInput schema / properties / preferred_launch_date

Added value: +{
+  "description": "Preferred launch date, YYYY-MM-DD (optional). Must be within the next 180 days; use toolfound_get_launch_calendar to find open featured seats. If that day is full by the time you verify, the earliest open day is assigned and reported. Omit to get the earliest open date automatically.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

changedInput schema / properties / x_handle / description

Previous value: -"The maker's X (Twitter) handle, e.g. @yourproduct (optional). Recommended: on launch day, toolfound's own account posts the launch and @-mentions this handle, so the maker gets tagged and can amplify."New value: +"The maker's X (Twitter) handle, e.g. @yourproduct (optional). Shown on the listing; the launch-day email includes a ready share kit (copy + badge) to post from this handle."

Changed2 schema fields changedAug 30, 2026

addedInput schema / properties / price_usd

Added value: +{
+  "description": "Optional starting price in USD (e.g. the cheapest paid plan). Only used when pricing_model is 'paid', 'freemium', or 'trial'.",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / pricing_model

Added value: +{
+  "description": "The product's pricing model (optional, but strongly recommended — captured now instead of after claim so the listing never sits at 'Pricing unlisted').",
+  "enum": [
+    "free",
+    "freemium",
+    "trial",
+    "paid",
+    "unknown"
+  ],
+  "type": "string"
+}

Changed1 schema field changedAug 11, 2026

addedInput schema / properties / x_handle

Added value: +{
+  "description": "The maker's X (Twitter) handle, e.g. @yourproduct (optional). Recommended: on launch day, toolfound's own account posts the launch and @-mentions this handle, so the maker gets tagged and can amplify.",
+  "maxLength": 120,
+  "type": "string"
+}

First observedAug 9, 2026

TDQS

A4.6/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 and does disclose substantial behavior: mandatory ownership verification, idempotent resubmission, free launches, no inbox access needed, and what one call returns. It does not cover error/failure behavior or any rate or size limits beyond what the schema states, so it falls short of a 5.

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?

Dense but tightly written single paragraph with the core action front-loaded and the AGENTS: block clearly separated for the calling agent. It is long, and a few clauses (free-slot counter, ordering of returned fields) could be trimmed without loss.

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 10-parameter creation tool with no annotations and no output schema, the description covers the essential ground: required inputs, the mandatory verification follow-up, idempotency, free-vs-paid expectations, and the contents of the response. An agent can invoke this correctly and know its next step without further discovery.

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 is 100%, so the baseline is 3, and the description adds real meaning on top: logo_url defaults to the site icon, description renders as plain-text paragraphs with 100-200 words reading best and >100 words qualifying for indexing, and preferred dates earlier than the next free date are moved forward. It leaves the x_handle and pricing_model semantics largely to 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?

States a specific verb and resource ('Submit a product to launch on toolfound.com') and identifies the platform's role, which cleanly separates it from siblings like toolfound_relaunch, toolfound_verify_submission and toolfound_get_product. An agent knows this is the entry-point creation call.

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?

Explicitly routes the agent: verification is mandatory, the verify_token works with toolfound_verify_submission via meta_tag/dns_txt, toolfound_check_verification dry-runs the checks, and the emailed magic link is a human fallback. It also states the idempotency rule for resubmitting a known URL, so when/when-not is fully covered.

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

All toolfound tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?