Skip to main content
Glama

toolfound

by com.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. 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 (first 100 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
NameRequiredDescriptionDefault
urlYesThe product's public https URL (e.g. https://yourproduct.com).
nameNoProduct name (optional — drafted from the site if omitted).
emailYesMaker's email — receives the verification link, queue updates, and launch results.
taglineNoOne-line tagline (optional).
x_handleNoThe 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.
price_usdNoOptional starting price in USD (e.g. the cheapest paid plan). Only used when pricing_model is 'paid', 'freemium', or 'trial'.
descriptionNoLonger description (optional — you can edit later).
pricing_modelNoThe product's pricing model (optional, but strongly recommended — captured now instead of after claim so the listing never sits at 'Pricing unlisted').
preferred_launch_dateNoPreferred 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.

TDQS

A4.6/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 burden, and it delivers: it discloses mandatory ownership verification, the three verification methods, returned fields (submission ID, queue position, launch date, free-slots counter), idempotency for known URLs, and content behavior around description word count and search indexing. This is unusually rich behavioral disclosure for a submission tool.

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 dense and information-packed, with important details front-loaded and a clear AGENTS: section for practical guidance. It earns most of its length, but the marketing phrase 'the launch platform where the whole launch runs agent-native, end to end' adds no operational value, and the paragraph could be slightly tighter.

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 no output schema, the description explains what the response contains and how to proceed with verification, which is critical for this complex tool. It covers idempotency, calendar usage, verification methods, and return values. Given the tool's 9 parameters and mandatory verification flow, this description is sufficiently complete for an agent to call it 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 description coverage is 100%, so the baseline is 3. The tool description adds extra useful semantics beyond the schema: description length recommendations (100–200 words, 100+ words qualifying for indexing) and idempotent behavior tied to the URL parameter. This raises it above baseline, though most parameter meaning still comes from 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 clearly identifies the tool's action ('Submit a product to launch'), the target resource (toolfound.com), and the overall outcome: creating a submission that returns an ID, verification instructions, queue position, and launch date. It also distinguishes itself from sibling tools by presenting this as the entry point for the launch flow, with idempotent resubmission behavior.

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 gives strong contextual guidance: agents are told they don't need inbox access, that verify_token works with meta_tag/dns_txt via toolfound_verify_submission, that toolfound_check_verification dry-runs checks, and that the calendar tool should be used for preferred dates. It does not explicitly state when not to use this tool or name alternatives like claim_listing, but the workflow context is clear.

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

All toolfound toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: verification dry-run vs actual verification, submission vs status vs calendar, search vs browse vs trending, etc. Even the two verification tools are cleanly separated by check (non-destructive) and verify (action).

Naming Consistency5/5

All tools follow the pattern toolfound_<verb>_<object>, with consistent verbs like get_, list_, search_, submit_, verify_, check_, claim_. No mixing of styles or vague verbs.

Tool Count5/5

12 tools is well-scoped for a launch platform server. It covers discovery, submission, verification, status tracking, and post-launch features without being bloated or thin.

Completeness4/5

The tool surface covers the full submission-verification-launch workflow plus discovery and post-launch actions. Missing explicit update/delete operations for submissions, though idempotent resubmission partially covers updates, so it's a minor gap rather than a fatal flaw.

Resources