Launchelion

Server Details

Daily leaderboard of newly-launched AI tools with real launch dates and Stripe-verified revenue.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-07 20:26
Transport: Streamable HTTP
URL

TDQS

A4.7/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: searching listings, retrieving listing details, finding alternatives, viewing purchasable add-ons, creating a checkout, and submitting a tool. There is no meaningful overlap between any two tools, even though search and alternatives both relate to discovery, their inputs and outputs are clearly separated.

Naming Consistency5/5

All six tool names follow a consistent verb_noun snake_case pattern: create_checkout, get_tool, list_alternatives, list_offers, search_tools, submit_tool. The verb is always first and the resource focus is clear, making the toolset predictable and easy to navigate.

Tool Count5/5

Six tools is a well-scoped size for the server's purpose: discovering, retrieving, comparing, submitting, and optionally promoting AI tool listings. Each tool earns its place and there is no bloat or thinness.

Completeness5/5

The toolset covers the full public-facing lifecycle of the domain: search and discovery, detail retrieval, alternative lookup, submission of new tools, and monetization via offers and checkout. There are no obvious dead ends; the only intentionally external step is the human completing checkout, which is clearly documented.

Available Tools

6 tools

create_checkoutCreate a checkout link for a paid add-onAInspect

Create a Stripe checkout URL for one paid add-on on one listing, and return it for a HUMAN to open. Never present this as a completed purchase: nothing is charged until a person completes checkout in a browser. Returns an error when the listing doesn't exist, the add-on isn't purchasable yet (free early access), or payments aren't configured in this environment.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	The listing's slug (as in a toolUrl, e.g. '/tools/acme-writer' -> 'acme-writer').
`product`	Yes	Add-on key: premium_launch, review_one, review_monthly, network_all, network_three. See list_offers for names, effects, and prices.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`error`	No
`checkoutUrl`	No	A URL a HUMAN must open. Nothing is charged until a person completes it.
`instruction`	No

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the annotations, the description explains that nothing is charged until checkout is completed by a human and that errors occur for missing listings, non-purchasable add-ons, or unconfigured payments. This substantially clarifies the tool's operational behavior without contradicting the annotations.

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 compact sentences each contribute directly: what is returned, what it does not mean, and what error conditions to expect. No filler or repeated schema information.

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?

The definition covers the key operational details an agent needs: who must complete the action, what the URL is not, and the relevant failure modes. An output schema exists, so the description does not need to reproduce return-value details.

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 schema already documents both parameters with 100% coverage, including the slug format and an enum for the product. The description adds only broad context about the operation being for one paid add-on on one listing, which is sufficient at baseline.

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 names a concrete action ('Create a Stripe checkout URL') and a narrow scope ('for one paid add-on on one listing'), which clearly distinguishes it from sibling listing/search tools. It tells an agent exactly what resource is acted on and what artifact is produced.

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 clearly states when to call the tool: to produce a checkout URL for a human to complete a purchase. It also warns against presenting the result as a completed purchase and notes conditions that yield errors. However, it does not explicitly point to an alternative tool for cases like free early-access add-ons.

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

get_toolGet AI tool detailA

Read-onlyIdempotent

Inspect

Fetch the full public detail for one AI tool by its listing slug (as returned by search_tools' toolUrl, e.g. '/tools/acme-writer' -> slug 'acme-writer'). Call this after search_tools to get a tool's full description, launch date, revenue signals (verified or self-reported), and for-sale status. Returns null if the slug doesn't resolve to a live Launchelion listing.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	The tool's listing slug.

Output Schema

ParametersJSON Schema

Name	Required	Description
`tool`	Yes	null when the slug does not resolve to a live listing on this site.

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds critical behavioral context: the null return for non-resolving slugs and the nature of data (verified or self-reported revenue signals). No contradictions found.

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-loaded with the primary action, and includes an example and edge-case note without redundancy. Every sentence earns its place; no fluff.

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?

With an output schema present, the description need not explain return structure, but it covers all key aspects: purpose, usage sequence, data content, and null behavior. It is complete for a simple read-only fetch tool.

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?

The description adds substantial meaning beyond the schema's minimal 'The tool's listing slug' by illustrating the exact format and transformation from toolUrl to slug (e.g., '/tools/acme-writer' -> 'acme-writer'). This is highly valuable for correct invocation.

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 the verb 'Fetch' and specific resource 'full public detail for one AI tool by its listing slug'. It distinguishes from siblings by explicitly referencing search_tools and listing what data is returned (description, launch date, revenue signals, for-sale status). The purpose is unambiguous.

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 explicit usage instruction: 'Call this after search_tools to get a tool's full description...' and explains the slug derivation from toolUrl. It sets expectations for null return, which guides when to use. This clearly frames the tool's role relative to alternatives.

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

list_alternativesList alternatives to a toolA

Read-onlyIdempotent

Inspect

List live, same-category alternatives to a well-known AI tool (e.g. 'chatgpt', 'notion-ai', 'figma'). Call this when a user asks 'what are the alternatives to X' or wants competitors/substitutes for a named product. target is the well-known tool's slug, not a listing slug from this catalog.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes	Slug of the well-known target tool, e.g. 'chatgpt'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`target`	Yes	null when the target slug is not a known product.
`alternatives`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safe read-only nature is known. The description adds useful context beyond annotations: results are 'live', alternatives are 'same-category', and the target must be a well-known tool slug rather than a catalog listing slug. This gives a clearer behavioral picture.

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 with no filler. The first sentence states the core purpose and examples; the second gives usage trigger and a critical parameter clarification. Information is front-loaded and each sentence earns its place.

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 low complexity (one parameter, read-only, output schema provided), the description fully covers purpose, usage triggers, and parameter nuances. It does not need to explain return values because an output schema exists. Everything the agent needs to decide when and how to invoke is present.

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 input schema already fully describes the parameter with 100% coverage and an example. The description adds additional disambiguation by emphasizing that `target` is 'not a listing slug from this catalog', which helps prevent misuse. This goes beyond the schema's description.

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 the tool lists live, same-category alternatives to well-known AI tools, with specific examples. It distinguishes itself from siblings like get_tool and search_tools by focusing on alternatives and clarifying the target is a well-known tool slug, not a catalog listing slug.

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 explicitly says 'Call this when a user asks what are the alternatives to X' which provides clear when-to-use guidance. However, it does not explicitly mention when not to use it or point to alternative tools for other scenarios, so it stops short of a full 5.

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

list_offersList paid add-ons (offers)A

Read-onlyIdempotent

Inspect

List the optional paid add-ons a maker can buy to promote their listing (name, one-sentence effect, price in USD). Listing is always free; these only ADD reach and are always labeled 'Sponsored'. Call this to see what's purchasable before create_checkout. During free early access (early-bird), offers are not yet purchasable and this says so (purchasable=false).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`site`	Yes
`offers`	Yes
`purchasable`	Yes	False during free early access — nothing can be bought.

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already mark this as read-only and idempotent, and the description adds meaningful behavioral context: listing is free, offers only add reach, they are labeled 'Sponsored', and purchasable=false during early access. This goes beyond the structured hints without contradicting them.

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 three sentences long with no filler. Every sentence adds useful information, and the most important purpose is front-loaded.

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 zero-parameter, read-only tool with an output schema, the description is fully complete: it covers the purpose, output semantics, relationship to create_checkout, and the early-access caveat. Nothing essential is missing.

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 input schema has zero parameters, so there are no parameter semantics to clarify; the baseline of 4 applies. The description usefully describes output content (name, one-sentence effect, price, purchasable flag), which helps the agent understand the returned data.

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 the tool lists optional paid add-ons for makers, including their name, effect, and price in USD. It uses a specific verb ('List') and resource ('paid add-ons') and distinguishes itself from the related create_checkout tool.

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 explicitly instructs to call this tool before create_checkout, establishing a clear usage context. It also explains the early-access condition where offers are not purchasable, giving the agent useful when-to-use and when-not-to-buy guidance.

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

search_toolsSearch AI toolsA

Read-onlyIdempotent

Inspect

Search the Launchelion catalog of live, published AI tools by a free-text query. Matches on tool name, tagline, or category name (case-insensitive substring). Call this first when a user asks to find, discover, or compare AI tools by keyword, use-case, or category (e.g. 'agents', 'writing assistants'). Returns up to 20 results.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Free-text search term, e.g. a tool name, use-case, or category.

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes	Matching live listings, newest first, capped at 20.

TDQS

A4.6/5.0

Behavior4/5

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

With annotations declaring readOnlyHint=true and idempotentHint=true, the behavior is already clear as a safe read operation. The description adds the specific behavioral detail of matching on name, tagline, or category with case-insensitive substring, and limits to live/published tools, which goes beyond the annotation. It does not mention pagination or result ordering, but the output schema likely covers the structure, so minor gap only.

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 four sentences, each providing essential information: what it searches, what it matches, when to use it, and a result limit. There is no redundancy or filler, and the information is front-loaded with the main purpose in the first sentence. It earns the full score for its efficiency and 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?

The tool is simple (one parameter) with strong annotations and a full param schema, so the description doesn't need extensive detail. The output limit (up to 20 results) and matching criteria are covered. The only omission is an explicit note about ordering or sorting, but since an output schema exists and the search semantics are clear, it is nearly complete. A score of 4 is justified.

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 single 'query' parameter is already fully described in the schema ('Free-text search term, e.g. a tool name, use-case, or category.') with 100% coverage. The description reinforces this by giving examples and specifying the matching behavior (case-insensitive substring), but does not add additional format requirements. Given the schema handles the parameter fully, a slight bonus is given for the clear guidance in the description, but it stays near baseline per the rubric.

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 the tool searches a catalog of live AI tools by free-text query, matching name, tagline, or category. It explicitly mentions case-insensitive substring matching and scope (live, published tools), distinguishing it from siblings like get_tool which likely fetches a specific tool.

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 explicitly instructs to call this tool first when a user wants to find, discover, or compare AI tools by keyword, use-case, or category, with examples. It implies this is the primary search entry point, contrasting with siblings such as get_tool, list_alternatives, or list_offers, which serve more specific post-discovery purposes.

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

submit_toolSubmit a new AI toolAInspect

Submit a new AI tool to Launchelion on behalf of its maker. Creates a draft listing (not yet public) and returns a claimUrl the maker must visit to sign up and claim/publish it. 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.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The tool's https homepage URL.
`name`	Yes	The tool's name.
`email`	Yes	The maker's email — used to claim the listing on signup.
`logoUrl`	No	https URL of the tool's logo. We copy it to our own storage — we never hotlink the maker's host.
`tagline`	No	One line shown on every card (max 60 chars). Supply it — without one we fall back to a truncated description.
`xHandle`	No	X/Twitter handle, without the @.
`category`	Yes	Category slug, e.g. 'agents', 'writing', 'coding', 'design', 'marketing', 'productivity', 'video', 'analytics'.
`imageUrls`	No	Up 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.
`description`	Yes	A description of the tool (40-1000 chars).
`problemSolved`	No	What problem the tool solves, in the maker's words (max 160 chars). Rendered as its own block on the listing page.
`xHandleIsFounder`	No	True when the handle is the founder's personal account rather than the product's.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`error`	No
`claimUrl`	No	Where the maker signs up to claim the DRAFT. Present only when ok is true.

TDQS

A4.9/5.0

Behavior5/5

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

Despite annotations being all false, the description adds substantial behavioral detail: the listing is a draft (not public), requires maker signup via claimUrl, has a global rate limit, and image files are copied to Launchelion's storage. These are not in annotations, so the description carries the burden well.

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?

Five sentences, each packed with relevant information. The main purpose is front-loaded, followed by usage constraints, rate limit, and parameter advice. No redundant wording or fluff.

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 11 parameters, 5 required, and an output schema, the description covers the essential context: what the tool does, when to use it, constraints, and tips on filling parameters. The output schema presumably details the return fields, so the description doesn't need to.

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 input schema has 100% description coverage, so the baseline is 3. The description adds extra guidance by highlighting which optional parameters matter most ('Supply tagline, problemSolved, logoUrl and imageUrls whenever you can') and explains their impact (makes listing look like a real product page). This goes slightly 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 clearly states the action ('Submit a new AI tool'), the resource ('to Launchelion'), and the outcome ('creates a draft listing... returns a claimUrl'). It also distinguishes from siblings by mentioning the claim process, which is unique to this tool compared to get_tool or search_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?

Explicitly states when to call: 'only when a user explicitly wants to list their own tool.' It also gives a negative constraint: 'never to submit a tool on someone else's behalf without their email,' which provides clear usage boundaries. The rate limit also sets expectations on frequency.

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. Dates show when Glama detected each change.

1 tool updateAug 23, 2026

Changedcreate_checkout2 fields changed

changedInput schema / properties / product / description

Previous value: -"Add-on key: premium_launch, review_one, review_monthly. See list_offers for names, effects, and prices."New value: +"Add-on key: premium_launch, review_one, review_monthly, network_all, network_three. See list_offers for names, effects, and prices."

changedInput schema / properties / product / enum

Previous value: -[
-  "premium_launch",
-  "review_one",
-  "review_monthly"
-]New value: +[
+  "premium_launch",
+  "review_one",
+  "review_monthly",
+  "network_all",
+  "network_three"
+]

6 tool updatesAug 20, 2026

Changedcreate_checkout1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "checkoutUrl": {
+      "description": "A URL a HUMAN must open. Nothing is charged until a person completes it.",
+      "type": "string"
+    },
+    "error": {
+      "type": "string"
+    },
+    "instruction": {
+      "type": "string"
+    },
+    "ok": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

Changedget_tool1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "tool": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "askingPriceUsd": {
+              "type": "number"
+            },
+            "category": {
+              "type": "string"
+            },
+            "description": {
+              "type": "string"
+            },
+            "faviconUrl": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "forSale": {
+              "const": true,
+              "type": "boolean"
+            },
+            "launchDate": {
+              "description": "ISO 8601 timestamp of the real launch date.",
+              "type": "string"
+            },
+            "logoUrl": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "name": {
+              "type": "string"
+            },
+            "ogImageUrl": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "revenueVerifiedAt": {
+              "description": "ISO 8601 timestamp of the last Stripe verification.",
+              "type": "string"
+            },
+            "selfReported": {
+              "const": true,
+              "description": "Marks selfReportedMrrUsd as unverified. Never report it as verified.",
+              "type": "boolean"
+            },
+            "selfReportedMrrUsd": {
+              "description": "Present only when the figure is the maker's own claim.",
+              "type": "number"
+            },
+            "tagline": {
+              "type": "string"
+            },
+            "toolUrl": {
+              "type": "string"
+            },
+            "url": {
+              "type": "string"
+            },
+            "verifiedMrrUsd": {
+              "description": "Present only when the maker connected Stripe.",
+              "type": "number"
+            }
+          },
+          "required": [
+            "name",
+            "tagline",
+            "description",
+            "url",
+            "category",
+            "launchDate",
+            "toolUrl",
+            "logoUrl",
+            "faviconUrl",
+            "ogImageUrl"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "null when the slug does not resolve to a live listing on this site."
+    }
+  },
+  "required": [
+    "tool"
+  ],
+  "type": "object"
+}

Changedlist_alternatives1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "alternatives": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "tagline": {
+            "type": "string"
+          },
+          "toolUrl": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "tagline",
+          "toolUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "target": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "name": {
+              "type": "string"
+            },
+            "url": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "name",
+            "url"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "null when the target slug is not a known product."
+    }
+  },
+  "required": [
+    "target",
+    "alternatives"
+  ],
+  "type": "object"
+}

Changedlist_offers1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "note": {
+      "type": "string"
+    },
+    "offers": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "key": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "priceUsd": {
+            "type": "number"
+          },
+          "whatItDoes": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "key",
+          "name",
+          "whatItDoes",
+          "priceUsd"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "purchasable": {
+      "description": "False during free early access — nothing can be bought.",
+      "type": "boolean"
+    },
+    "site": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "site",
+    "purchasable",
+    "note",
+    "offers"
+  ],
+  "type": "object"
+}

Changedsearch_tools1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "results": {
+      "description": "Matching live listings, newest first, capped at 20.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "category": {
+            "type": "string"
+          },
+          "faviconUrl": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "logoUrl": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "name": {
+            "type": "string"
+          },
+          "site": {
+            "type": "string"
+          },
+          "tagline": {
+            "type": "string"
+          },
+          "toolUrl": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "tagline",
+          "url",
+          "category",
+          "site",
+          "toolUrl",
+          "logoUrl",
+          "faviconUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "results"
+  ],
+  "type": "object"
+}

Changedsubmit_tool1 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"
+}

5 tool updatesAug 20, 2026

Changedcreate_checkout1 field changed

changedInput schema / properties / slug / description

Previous value: -"The listing's slug (as in a toolUrl, e.g. '/tools/skillselion' -> 'skillselion')."New value: +"The listing's slug (as in a toolUrl, e.g. '/tools/acme-writer' -> 'acme-writer')."

Changedget_tool1 field changed

removedInput schema / properties / site

Removed value: -{
-  "description": "Which network site's wording/locale to render the tool through. Defaults to the tool's origin site.",
-  "enum": [
-    "launchelion",
-    "aitoolsindex",
-    "aialtfinder",
-    "lanzamientosia",
-    "iaselecta",
-    "alternativasia",
-    "kitoolsheute",
-    "bestekitools",
-    "kialternativen"
-  ],
-  "type": "string"
-}

Changedlist_alternatives1 field changed

removedInput schema / properties / site

Removed value: -{
-  "description": "Defaults to the aialtfinder alternatives site.",
-  "enum": [
-    "launchelion",
-    "aitoolsindex",
-    "aialtfinder",
-    "lanzamientosia",
-    "iaselecta",
-    "alternativasia",
-    "kitoolsheute",
-    "bestekitools",
-    "kialternativen"
-  ],
-  "type": "string"
-}

Changedlist_offers1 field changed

removedInput schema / properties / site

Removed value: -{
-  "description": "Which network site to price the offers for. Defaults to launchelion.",
-  "enum": [
-    "launchelion",
-    "aitoolsindex",
-    "aialtfinder",
-    "lanzamientosia",
-    "iaselecta",
-    "alternativasia",
-    "kitoolsheute",
-    "bestekitools",
-    "kialternativen"
-  ],
-  "type": "string"
-}

Changedsearch_tools1 field changed

removedInput schema / properties / site

Removed value: -{
-  "description": "Restrict to one launchelion-network site id (launchelion, aitoolsindex, aialtfinder, lanzamientosia, iaselecta, alternativasia, kitoolsheute, bestekitools, kialternativen). Omit to search across the whole network.",
-  "enum": [
-    "launchelion",
-    "aitoolsindex",
-    "aialtfinder",
-    "lanzamientosia",
-    "iaselecta",
-    "alternativasia",
-    "kitoolsheute",
-    "bestekitools",
-    "kialternativen"
-  ],
-  "type": "string"
-}

6 tool updatesAug 19, 2026
- First observedcreate_checkout
- First observedget_tool
- First observedlist_alternatives
- First observedlist_offers
- First observedsearch_tools
- First observedsubmit_tool

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

KI Tools Heute A
com.kitoolsheute
Tägliche Rangliste neuer KI-Tools mit echten Startdaten und über Stripe geprüften Umsätzen.
AI & Machine Learning Open Data
61
The AI Tools Index A
com.theaitoolsindex
AI tools filed by category, with real launch dates and revenue verified through Stripe.
AI & Machine Learning Open Data
61
IA Selecta A
com.iaselecta
Catálogo de herramientas de IA por categoría, con fechas reales e ingresos verificados.
AI & Machine Learning Developer Tools
61
Beste KI Tools A
com.bestekitools
KI-Tools nach Kategorien, mit echten Startdaten und über Stripe geprüften Umsätzen.
AI & Machine Learning Research & Data
61

Related MCP Servers

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 3 days ago (2026-09-05 07:51 UTC)
1
-
Launch Engine
Marketing Product Management Autonomous Agents
ZionHopkins
A
license
B
quality
C
maintenance
Agentic pipeline that transforms ideas to revenue — for solo founders and bootstrappers.
Updated 5 months ago (2026-04-04 03:04 UTC)
2
45
4
4
MIT
competlab-mcp-server
Marketing Monitoring Product Management
competlab
A
license
A
quality
B
maintenance
Competitive intelligence platform with 24 tools. Monitor competitor pricing, content, positioning, tech stacks, and AI visibility — track how ChatGPT, Claude, and Gemini rank your brand.
Updated 2 months ago (2026-07-08 14:13 UTC)
33
2
MIT
FounderSignal
Research & Data Search
carlosalvite
A
license
A
quality
F
maintenance
Ask Claude what SaaS ideas are worth building. Aggregates revenue data, growth signals and pain points from AppSumo, TrustMRR, Product Hunt, Indie Hackers, Reddit and more.
Updated 3 months ago (2026-05-28 20:51 UTC)
2
67
1
MIT

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.

Resources

Need Help?