Skip to main content
Glama

Submit a new AI tool

submit_tool

Submit a new AI tool to Launchelion on behalf of its maker. We fetch the submitted url and look for the Launchelion badge. Badge found (status QUEUED): no account is needed — the badge proves the maker controls the site. The listing enters the free review queue and goes live within 7 days if it passes review; the result has its listingUrl. Badge not found (status DRAFT): the listing is a private draft. The result carries badgeHtml — once it is on the page, a later re-check queues the draft (drafts are re-checked in rotation, 25 per run, one run every 6 hours, for 90 days), so do not submit again — and a claimUrl where the maker can sign up with the same email instead. Refused: our own domains, private or non-https hosts (error reserved_host), and a host that already has a live, queued or pending listing (error duplicate_host). Call this only when a user explicitly wants to list their own tool — never to submit a tool on someone else's behalf without their email. Rate-limited globally to 5 submissions per hour. Supply tagline, problemSolved, logoUrl and imageUrls whenever you can: they are what make the published listing look like a real product page rather than a stub.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "url": "<url>",
      "description": "<description>",
      "category": "<category>",
      "email": "<email>"
    },
    "name": "submit_tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe tool's https homepage URL.
nameYesThe tool's name.
emailYesThe maker's email. Kept as the contact address; signing up with it on this site attaches the listing to the maker's account.
logoUrlNohttps URL of the tool's logo. We copy it to our own storage — we never hotlink the maker's host.
taglineNoOne line shown on every card (max 60 chars). Supply it — without one we fall back to a truncated description.
xHandleNoX/Twitter handle, without the @.
categoryYesCategory slug, e.g. 'agents', 'writing', 'coding', 'design', 'marketing', 'productivity', 'video', 'analytics'.
imageUrlsNoUp to 5 https screenshot URLs, best first. Copied to our own storage. Without any, the listing shows a generated placeholder card instead of a real screenshot.
descriptionYesA description of the tool (40-1000 chars).
problemSolvedNoWhat problem the tool solves, in the maker's words (max 160 chars). Rendered as its own block on the listing page.
xHandleIsFounderNoTrue when the handle is the founder's personal account rather than the product's.

Output Schema

NameRequiredDescriptionDefault
okYes
badgeNoResult of the badge check on the submitted url.
errorNoinvalid_input, bad_category, rate_limited, reserved_host (our own or a private host), or duplicate_host.
statusNoQUEUED: the badge was found on the submitted url; the listing is in the review queue with no account and goes live within 7 days if it passes review. DRAFT: no badge found; a private draft. Present only when ok is true.
messageNoWhat happened and what the maker can do next.
claimUrlNoWhere the maker signs up with the same email to manage (QUEUED) or claim (DRAFT) the listing. Present only when ok is true.
badgeHtmlNoDRAFT only: the badge HTML to put, unmodified and visible, on the submitted url. Drafts are re-checked in rotation (25 per run, one run every 6 hours, for 90 days).
listingUrlNoThe listing's public page. QUEUED only; it returns 404 until the listing goes live.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / email / description
      Previous value: -"The maker's email — used to claim the listing on signup."New value: +"The maker's email. Kept as the contact address; signing up with it on this site attaches the listing to the maker's account."
    • addedOutput schema / properties / badge
      Added value: +{
      +  "description": "Result of the badge check on the submitted url.",
      +  "enum": [
      +    "verified",
      +    "missing"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / badgeHtml
      Added value: +{
      +  "description": "DRAFT only: the badge HTML to put, unmodified and visible, on the submitted url. Drafts are re-checked in rotation (25 per run, one run every 6 hours, for 90 days).",
      +  "type": "string"
      +}
    • changedOutput schema / properties / claimUrl / description
      Previous value: -"Where the maker signs up to claim the DRAFT. Present only when ok is true."New value: +"Where the maker signs up with the same email to manage (QUEUED) or claim (DRAFT) the listing. Present only when ok is true."
    • addedOutput schema / properties / error / description
      Added value: +"invalid_input, bad_category, rate_limited, reserved_host (our own or a private host), or duplicate_host."
    • addedOutput schema / properties / listingUrl
      Added value: +{
      +  "description": "The listing's public page. QUEUED only; it returns 404 until the listing goes live.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / message
      Added value: +{
      +  "description": "What happened and what the maker can do next.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / status
      Added value: +{
      +  "description": "QUEUED: the badge was found on the submitted url; the listing is in the review queue with no account and goes live within 7 days if it passes review. DRAFT: no badge found; a private draft. Present only when ok is true.",
      +  "enum": [
      +    "QUEUED",
      +    "DRAFT"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "claimUrl": {
      +      "description": "Where the maker signs up to claim the DRAFT. Present only when ok is true.",
      +      "type": "string"
      +    },
      +    "error": {
      +      "type": "string"
      +    },
      +    "ok": {
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "ok"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With annotations already declaring readOnly=false, openWorld=true and non-idempotent, the description still adds substantial behavior: badge fetch semantics, the QUEUED/DRAFT/refused branch outcomes, error codes reserved_host and duplicate_host, a 5-per-hour global rate limit, a 7-day review window, and the 90-day/25-per-run re-check rotation. This is well beyond annotation coverage; only the response envelope itself is left unstated, and an output schema covers that.

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?

Front-loaded with the core action and outcome branches, and nearly every clause carries operational information (badge states, error codes, rate limit, draft handling). It is dense to the point of being a single long block rather than broken out by outcome, which costs it the top mark.

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 mutation tool with 11 parameters, 5 required, an output schema, and external side effects, the description covers prerequisites (badge ownership), failure modes, rate limits, resubmission hazards, and what to supply for a good result. An agent has everything needed to decide and call correctly.

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%, so each of the 11 parameters is already documented, making 3 the baseline. The description does add one piece of cross-parameter guidance — prioritize tagline, problemSolved, logoUrl and imageUrls because they determine whether the listing looks like a product page or a stub — but it does not explain fields like xHandleIsFounder or category semantics 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?

Opens with a specific verb and resource ('Submit a new AI tool to Launchelion on behalf of its maker') and frames the whole flow around badge verification. It is clearly distinguishable from siblings such as get_tool, search_tools and list_alternatives, which are read/lookup tools.

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?

Gives an explicit use condition ('only when a user explicitly wants to list their own tool') plus a prohibition ('never to submit a tool on someone else's behalf without their email'), and an anti-pattern for the draft path ('do not submit again' — use claimUrl or wait for re-check). That is when-to-use, when-not, and the alternative all in one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources