KI Tools Heute

Server Details

Tägliche Rangliste neuer KI-Tools mit echten Startdaten und über Stripe geprüften Umsätzen.

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-06 16:38
Transport: Streamable HTTP
URL

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.5/5.0

Behavior5/5

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

The description significantly exceeds the minimal annotation hints: it explains that no charge occurs until a human completes checkout, that the link is meant for human interaction, and that errors are returned for missing listings, unpurchasable add-ons, or unconfigured payments. These are real behavioral details not present in 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 sentences, each earning its place: purpose, critical payment caveat, and failure conditions. The most important information is front-loaded with no repetition of schema content.

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 two-parameter tool with an output schema, the description covers the essential context: what it does, what it returns, how it should be used, and when it errors. Nothing critical is missing for an agent to select and invoke it reliably.

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 the schema itself fully explains `slug` and `product`. The description adds only a modest semantic constraint that the add-on must be paid and tied to a single listing, which matches but does not meaningfully exceed 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 specific verb and resource — 'Create a Stripe checkout URL' — and scopes it as 'for one paid add-on on one listing'. It also clearly distinguishes this from showing a purchase as completed, giving an agent unambiguous intent.

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 clear context: this tool is for generating a checkout link that a human must open to actually pay. It lists failure conditions that help an agent decide when the tool will not work, but it does not explicitly name alternative tools or when to use them.

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 KI Tools Heute 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

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. It adds context about the return value (null on invalid slug) and the scope of information retrieved (full description, launch date, revenue signals, for-sale status), which are beyond the schema. It doesn't discuss permissions or rate limits, but for a read-only fetch with good annotations, this is adequate.

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?

Two sentences with zero waste. The first sentence communicates purpose and input format; the second gives usage context and return behavior. Information is front-loaded with the most important details first.

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 the tool has one parameter, a clear input format, an output schema, and strong annotations, the description covers essential aspects. It explains when to use, what it returns (including null case), and the slug format. It doesn't detail the output structure since the output schema exists, and it doesn't mention any edge cases beyond null, but for a simple retrieval tool it's complete enough.

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% with a single parameter 'slug', and its description ('The tool's listing slug.') is minimal. The tool description adds crucial semantics by showing the exact format ('/tools/acme-writer' -> slug 'acme-writer') and clarifying it's the same slug returned by search_tools' toolUrl, which the schema alone doesn't convey. This exceeds 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 clearly states the tool fetches full public detail for one AI tool by slug, specifying the exact input format (e.g., '/tools/acme-writer' -> slug 'acme-writer') and its relationship to search_tools. It distinguishes itself from siblings like search_tools (which lists) and list_alternatives/list_offers (which retrieve other entities), making the purpose 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?

The description explicitly says 'Call this after search_tools' and elaborates that it retrieves a tool's full description, launch date, revenue signals, and for-sale status. It also mentions the failure mode ('Returns null if the slug doesn't resolve'), giving clear guidance on when to use it and what to expect.

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.7/5.0

Behavior4/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 'live' and 'same-category' filtering context, which helps. It doesn't add much beyond annotations, but the 'live' qualifier adds temporal context.

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?

Description is two sentences, front-loaded with the core action and usage trigger, no wasted words.

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 full schema coverage, clear usage trigger, and annotations covering safety, the description is sufficient for a simple one-parameter tool. Output schema exists, so return format disclosure isn't needed.

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% and the description reinforces `target`'s meaning by clarifying it's the well-known slug, not a listing slug, adding value beyond the schema's 'Slug of the well-known target tool'.

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 'List live, same-category alternatives to a well-known AI tool' and provides examples, distinguishing it from siblings by specifying the target is a well-known tool slug, not a catalog listing.

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 says 'Call this when a user asks...' and clarifies that `target` is a well-known tool's slug, not a listing slug, clearly differentiating from similar search_tools.

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

Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description adds meaningful behavioral context: listings are free, offers only add reach, add-ons are always labeled 'Sponsored', and early-bird offerings report purchasable=false. This gives the agent a clear model of expected 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?

The description is compact and front-loaded with the core purpose, followed by key behavioral nuances and usage context. Every sentence contributes distinct information with no redundancy or filler.

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, zero-parameter read-only tool with an output schema and supportive annotations, this description is complete. It covers purpose, output contents, relation to checkout, and the special early-access condition, leaving no important gap for an agent to misuse it.

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?

With zero parameters and 100% schema coverage, the description does not need to explain inputs. It adds useful output semantics by mentioning the returned fields (name, one-sentence effect, price in USD), which compensates for the empty 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 tool lists optional paid add-ons a maker can buy, which is a specific verb+resource combination. It distinguishes itself from create_checkout by framing this as the pre-purchase discovery step, and the title reinforces the same purpose.

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 to call this before create_checkout, providing a clear context for use. It does not explicitly list when-not-to-use cases or mention alternative sibling tools beyond create_checkout, so it falls just short of fully explicit exclusion 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 KI Tools Heute 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.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint and idempotentHint, but the description adds valuable behavioral context: case-insensitive substring matching, fields searched (name, tagline, category), and the 'returns up to 20 results' limit. This exceeds annotation coverage without contradicting it.

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?

Two concise sentences: first states purpose and matching behavior, second provides usage guidance and result limit. No fluff, all information front-loaded, and each clause adds value. Ideal conciseness.

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 tool is simple (one parameter, read-only) and the description covers all essential aspects: what it searches, how it matches, when to use it, and the result limit. Given the high schema coverage and output schema exists, no additional context is needed.

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 has 100% coverage for the single 'query' parameter with a basic description. The tool description goes beyond that by detailing what the query matches (name, tagline, category in a case-insensitive substring), which enriches the parameter semantics. Fine for a one-param tool.

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 the verb 'Search' and the resource 'KI Tools Catalog of live, published AI tools'. It distinguishes from siblings like get_tool (exact retrieval) by specifying free-text query matching on name, tagline, or category, making the tool's purpose unique and clear.

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?

Clear when-to-use guidance: 'Call this first when a user asks to find, discover, or compare AI tools' — this sets priority. However, it does not explicitly name sibling alternatives (e.g., get_tool) for when not to use it, so it lacks explicit when-not/alternatives. There is no misleading guidance, but exclusions are implied rather than stated.

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 KI Tools Heute 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?

The description discloses that the submission is not immediately public, requires a claimUrl visit for publishing, and is rate-limited globally to 5 per hour. These behaviors are not covered by annotations (which only say readOnlyHint=false, etc.), adding critical context beyond structured metadata.

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 concise, with each sentence adding distinct value: purpose, behavior, usage caveat, rate limit, and parameter guidance. No filler or repetition of schema details.

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 complexity (11 params, 5 required) and the provided output schema, the description covers purpose, workflow, caveats, and parameter guidance sufficiently. The schema covers parameter formats, and the description fills in behavioral and contextual gaps, resulting in a complete picture.

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?

Although schema coverage is 100%, the description adds meaning for parameters like tagline, problemSolved, logoUrl, and imageUrls, explaining their impact on listing quality. It complements the schema without redundancy, adding value by motivating supply of these fields.

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 submits a new AI tool on behalf of its maker, with a specific outcome: creates a draft listing and returns a claimUrl. It clearly distinguishes from siblings like get_tool and search_tools by focusing on submission, not retrieval.

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 states when to use: only when a user wants to list their own tool, and warns against submitting on someone else's behalf without their email. This provides clear usage guidance and exclusions, distinguishing it from other tools like create_checkout.

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

6 tool updatesAug 20, 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

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
Launchelion A
com.launchelion
Daily leaderboard of newly-launched AI tools with real launch dates and Stripe-verified revenue.
AI & Machine Learning Finance Open Data
61
KI Alternativen A
com.ki-alternativen
Alternativen zu bekannten KI-Tools, mit über Stripe geprüften Umsätzen statt Schätzungen.
AI & Machine Learning Finance
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

Related MCP Servers

toolradar-mcp
Search Research & Data
Nadeus
A
license
A
quality
A
maintenance
Give your AI agent access to 8,400+ software tools — search, compare, get pricing, find alternatives, and discover the best tool for any use case.
Updated 12 days ago (2026-08-25 14:17 UTC)
8
141
4
MIT
stripe-analytics-mcp
Finance Payments & Billing
npow
A
license
Not graded
quality
F
maintenance
Provides real-time Stripe subscription analytics including MRR, churn, failed payments, and expiring trials. Enables AI assistants to answer business health questions like 'How's my business doing?'
Updated 6 months ago (2026-03-09 20:36 UTC)
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
Trends MCP
Search Research & Data
trendsmcp-ai
A
license
A
quality
A
maintenance
Live trend data for your AI. 25+ platforms. One connection.
Updated 8 days ago (2026-08-29 16:28 UTC)
8
3
37
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.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool targets a clearly distinct action: searching, retrieving details, finding alternatives, listing offers, creating a checkout, and submitting a tool. Though search_tools and list_alternatives both return catalog entries, their triggers and inputs are sufficiently different that an agent can reliably choose correctly.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: create_, get_, list_, list_, search_, submit_. The only variation is singular vs plural nouns, but the verb pattern is uniform and predictable enough that the toolset reads as one coherent convention.

Tool Count5/5

Six tools is a well-scoped size for a directory-plus-purchase workflow. Each tool covers a distinct step in the user journey, from discovery to submission to paid add-on checkout, without redundant bloat or a frustratingly thin surface.

Completeness4/5

The core workflows—search, detail retrieval, alternatives, listing creation, offer inspection, and checkout generation—are present and connect together without dead ends. However, there is no way to update, delete, or paginate through tool listings, and search_tools caps at 20 results, which is a minor gap for a full lifecycle.

Resources

Need Help?