A
licenseA
qualityA
maintenanceGive your AI agent access to 8,400+ software tools — search, compare, get pricing, find alternatives, and discover the best tool for any use case.
8
141
4
MIT
Beste KI Tools
Server Details
KI-Tools nach Kategorien, 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
- Transport
- Streamable HTTP
- URL
Available Tools
6 toolscreate_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 goes beyond the annotations by explaining the real-world side effect boundary: no charge occurs until a person completes checkout in a browser. It also names specific failure cases and the important instruction not to present the returned URL as a completed purchase. This is exactly the kind of behavioral nuance an agent needs.
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 tightly written, with the core action front-loaded and the critical payment caveat placed immediately after. Every sentence earns its place, including the error conditions, without unnecessary detail.
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 checkout-link creation tool, the description covers what it returns, who should open it, the most important safety caveat, and the common failure conditions. Combined with the output schema and annotations, this gives an agent enough to invoke the tool correctly and interpret the result appropriately.
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%, and both parameters have meaningful schema descriptions. The tool description adds some context by mapping 'one listing' and 'one paid add-on' to the slug and product, but it does not need to compensate for missing schema documentation. Baseline of 3 is appropriate.
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 action ('Create a Stripe checkout URL') and the exact resource scope: one paid add-on on one listing. It clearly distinguishes this tool from the sibling tools by focusing on purchase/checkout rather than lookup or submission.
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 makes the intended use clear: generate a checkout link for a human to open, and never treat this as a completed purchase. It also documents error conditions that tell the agent when the tool cannot be used. It does not explicitly name sibling alternatives, but the context is clear enough to avoid misselection.
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 detailARead-onlyIdempotentInspect
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 Beste KI Tools 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.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds useful behavioral context beyond annotations: it discloses that the tool returns null for invalid slugs, indicating no error throw, and specifies the type of data returned (description, launch date, revenue signals, for-sale status). This is more than the annotations alone provide, hence a 4.
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, tightly written, and front-loaded with the core action and input. Every phrase adds value: the slug format example, the recommended call sequence, and the null return behavior. There is no verbose or redundant text.
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 single parameter, high schema coverage, the presence of an output schema (automatically defining return structure), and read-only annotations, the description covers all necessary context: what to call, when to call, what to expect in return, and the null edge case. There is no gap that would hinder correct invocation.
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 has 100% coverage of the parameter 'slug' with its description 'The tool's listing slug.' The description reinforces this by explaining how the slug is derived (from search_tools' toolUrl) and gives an example. This matches the baseline of 3 for high schema coverage, and the added example provides slight extra value without overstepping.
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, distinguishing it from siblings. It specifies the verb ('fetch'), the resource ('one AI tool'), and the precise input (slug from search_tools' toolUrl). It also provides an example of slug format, eliminating ambiguity.
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 to call this after search_tools to obtain full description, launch date, revenue signals, and for-sale status. It clarifies that the slug comes from search_tools' toolUrl, and notes that it returns null for unresolvable slugs, which guides the agent on when and how to use it.
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 toolARead-onlyIdempotentInspect
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=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond the schema by noting results are 'live', 'same-category', and that the target must be a well-known tool's slug rather than a catalog listing slug.
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 tight sentences: the first states the operation with examples, the second gives the exact user-intent trigger and a critical parameter clarification. No filler; every clause 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?
For a single-parameter tool with a full output schema, strong annotations, and clear usage guidance, the description is complete. It covers what the tool does, when to use it, what the target parameter means, and the special constraint about slugs.
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 parameter already has an example, so the baseline is 3. The description adds value by explicitly warning that `target` is the well-known tool's slug, not a listing slug from this catalog, which prevents a likely misuse.
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 uses a specific verb and resource: 'List live, same-category alternatives to a well-known AI tool'. It also gives concrete examples and distinguishes itself from sibling tools like search_tools by clarifying that the input is a well-known tool's slug, not a listing slug from the catalog.
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 clearly states when to use the tool: 'Call this when a user asks “what are the alternatives to X” or wants competitors/substitutes for a named product.' It provides the trigger context but does not explicitly name alternative tools or state when not to use this tool versus search_tools, 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)ARead-onlyIdempotentInspect
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.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior, and the description adds valuable context: listing is always free, offers are labeled 'Sponsored', and early-bird mode returns purchasable=false. This goes beyond the structured metadata and helps the agent understand expected response semantics.
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, front-loaded with the main purpose, and every sentence adds meaningful information: what is listed, what is returned, and the early-access behavior. No filler or redundancy.
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 absence of parameters, the presence of an output schema, and strong annotations, the description fully covers the situational nuance (early access, purchasable flag, Sponsored labeling). Nothing important is missing for an agent to invoke and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema carries no burden. The description appropriately focuses on the returned data (name, effect, price, purchasable flag) rather than input semantics, which is sufficient for a parameterless list operation.
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 uses a specific verb ('List') and a clear resource ('optional paid add-ons (offers)'), with details about name, effect, and price. It distinguishes itself from siblings like create_checkout by explicitly framing list_offers as the lookup step before checkout.
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 to see what's purchasable before create_checkout,' giving a clear when-to-use directive. It also explains the early-access caveat, telling the agent that offers may not be purchasable yet and will show purchasable=false, which prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_toolsSearch AI toolsARead-onlyIdempotentInspect
Search the Beste KI Tools 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.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, so the description doesn't need to restate that. It adds valuable behavioral details: case-insensitive substring matching on three fields, and a result cap of 20. This goes beyond annotations but doesn't cover pagination or sorting, which is minor given the output schema and simplicity.
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: the first covers purpose and matching scope, the second provides usage guidance and examples. No filler, front-loaded with the core purpose, and every sentence adds value.
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 simple tool (1 parameter, no nested objects) and presence of an output schema, the description fully covers what the agent needs: what it searches, how it matches, the usage context, and result limit. It is complete for its complexity level.
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 schema already describes query as 'Free-text search term', but the description enriches it with what it matches against (name, tagline, category) and the case-insensitive nature. With 100% schema coverage, baseline is 3, but the added semantics about matching logic earns a 4.
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 the 'Beste KI Tools catalog' of live, published AI tools by free-text query, matching on name, tagline, or category. This specific verb+resource+scope distinguishes it from siblings like get_tool (exact retrieval) and list_alternatives (alternative discovery), and includes concrete examples.
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?
It explicitly instructs to 'Call this first when a user asks to find, discover, or compare AI tools by keyword, use-case, or category', providing clear guidance on when to use. It also gives example queries ('agents', 'writing assistants'). The mention of 'first' implies it's the entry point, aligning with sibling tools for follow-ups, though it doesn't enumerate exclusions. Still, the explicit directive is strong.
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 Beste KI Tools 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 | Default |
|---|---|---|---|
| url | Yes | The tool's https homepage URL. | |
| name | Yes | The tool's name. | |
| 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 adds substantial behavioral detail beyond annotations: listings are drafts, not public; a claimUrl is returned; the tool is globally rate-limited to 5 submissions per hour; logo/image URLs are copied to storage. This gives the agent important operational expectations not conveyed by the readOnlyHint/idempotentHint/destructiveHint flags.
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, front-loaded with the core purpose and result, followed by usage constraints and field guidance. No filler or repetition; every sentence adds value.
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 and an output schema, the description covers the most decision-critical context: draft vs public state, claim flow, rate limit, ownership/consent rule, and the role of optional fields. It is complete enough for an agent to invoke correctly without further documentation.
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 already 100%, so the baseline is 3. The description adds meaningful parameter guidance by emphasizing tagline, problemSolved, logoUrl, and imageUrls, explaining why they matter, and noting fallback behavior (e.g., truncated description, placeholder card) that is not in the schema itself.
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 action ('Submit a new AI tool to Beste KI Tools on behalf of its maker') and the concrete result ('Creates a draft listing... returns a claimUrl'). It clearly differentiates this tool from read/list/search siblings by describing the submission and claimed-publish workflow.
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?
Explicit when-to-use guidance is provided: 'Call this only when a user explicitly wants to list their own tool.' It also states a boundary condition ('never to submit a tool on someone else's behalf without their email'), which helps the agent avoid misuse despite there being no sibling tool with overlapping submission behavior.
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 update
- Changed
create_checkout2 fields changed- changed
Input schema / properties / product / descriptionPrevious 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." - changed
Input schema / properties / product / enumPrevious value: -[ - "premium_launch", - "review_one", - "review_monthly" -]New value: +[ + "premium_launch", + "review_one", + "review_monthly", + "network_all", + "network_three" +]
6 tool updates
- Changed
create_checkout1 field changed- changed
Output 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" +}
- Changed
get_tool1 field changed- changed
Output 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" +}
- Changed
list_alternatives1 field changed- changed
Output 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" +}
- Changed
list_offers1 field changed- changed
Output 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" +}
- Changed
search_tools1 field changed- changed
Output 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" +}
- Changed
submit_tool1 field changed- changed
Output 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 updates
- First observed
create_checkout - First observed
get_tool - First observed
list_alternatives - First observed
list_offers - First observed
search_tools - First observed
submit_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 asio.github.acme/serveralso 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.jsonon 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.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Tägliche Rangliste neuer KI-Tools mit echten Startdaten und über Stripe geprüften Umsätzen.
Alternativen zu bekannten KI-Tools, mit über Stripe geprüften Umsätzen statt Schätzungen.
Catálogo de herramientas de IA por categoría, con fechas reales e ingresos verificados.
AI tools filed by category, with real launch dates and revenue verified through Stripe.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceSearch and discover 500+ tools, APIs, and services for AI agents. Browse 15 categories, get recommendations, and access structured metadata including auth methods, free tiers, and example calls.1-
- FlicenseNot gradedqualityBmaintenanceProvides verified pricing data for SaaS, AI tools, and LLMs across 490+ tools. No API key required, returns sourced records with attribution links.2-
- AlicenseNot gradedqualityFmaintenanceProvides 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?'MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.7/5.0
Disambiguation5/5
Each tool has a clear, distinct purpose: search for discovery, get for details, list alternatives for comparison, list offers for add-ons, create checkout for purchasing, and submit for adding new tools. No overlapping functionality is apparent.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, with clear verbs like create, get, list, search, and submit. The naming is uniform and intuitive.
Tool Count5/5
With six tools, the set is appropriately sized for a catalog server covering search, retrieval, submission, and purchase flows. It's neither sparse nor bloated.
Completeness5/5
The tool surface covers the key user journeys: discovering tools (search, get, list alternatives), purchasing add-ons (list offers, create checkout), and contributing (submit). No essential operation seems missing for the stated purpose.