Alternativas a las herramientas de IA más conocidas, con ingresos verificados con Stripe.
Scored across 6 tools
Each tool targets a distinct resource and action: search returns catalog matches, get_tool returns detailed listing, list_alternatives finds competitors, submit_tool creates a draft, list_offers describes purchasable add-ons, and create_checkout handles the purchase step. No two tools appear to overlap in purpose.
All tool names follow a consistent verb_noun pattern: create_, get_, list_, list_, search_, submit_. Verbs are specific and nouns clearly identify the object, making the set predictable and easy to navigate.
Six tools is well-scoped for a directory server with discovery, submission, and monetization features. Each tool covers a meaningful operation, with no redundancy or bloat.
The surface covers core workflows: finding tools, viewing full details, seeing alternatives, submitting a listing, and purchasing paid add-ons. Minor gaps remain around listing management—there is no update or delete operation for submitted tools—but these are plausibly handled outside the MCP or by the human claiming the listing.
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.
| 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. |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds essential behavioral details: checkout is not completed until a person opens the URL in a browser, no charge occurs during creation, and predictable errors occur when the listing is missing, the add-on is free early access, or payments are not configured. This gives the agent an accurate model of side effects 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the outcome, the second sets the buyer-authorization expectation, and the third lists failure cases. Every sentence adds distinct value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the required parameters, an output schema, and the relevant annotations, the description is complete enough for an agent to call the tool correctly. It explains the main caveat of creating a checkout link, when it errors, and that the resulting URL is for a human to complete, leaving no critical runtime surprise unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the parameters themselves, but the input schema fully documents both slug and product, including the product enum and pointer to list_offers. Since schema description coverage is 100%, the description adds no additional parameter semantics; the schema carries that weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: creating a Stripe checkout URL for one paid add-on on one listing. It also clarifies the intended recipient is a human, which distinguishes this tool from purchase-completion or listing-management siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when the tool is appropriate: whenever a checkout link for a paid add-on is needed before a human completes payment. It also gives important negative context by stating that this is not a completed purchase and will error in non-purchasable cases. It does not explicitly route the agent to sibling tools or name alternatives, though the schema pointing to list_offers partially fills that gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 Alternativas IA listing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The tool's listing slug. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | null when the slug does not resolve to a live listing on this site. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description wisely adds value by scoping what 'public detail' means (verified or self-reported revenue signals, for-sale status) and the null-return contract. It doesn't add auth, rate-limit, or ordering details, but for a simple read operation with strong annotation coverage, it discloses more than the calibration baseline (which scored 3).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences, each earning its place: what it does, when to call it, and the null edge case. The inline example is efficient, and there is zero fluff or repetition of schema data. This is a model of dense, front-loaded technical writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with an output schema, the description covers the input contract (slug format, source), the output scope (public detail, revenue signals, for-sale status), and the failure mode (null case). No critical context is missing for an agent to use this safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents the slug parameter. The description earns credit by adding real-world semantics: slug format via example ('/tools/acme-writer' -> 'acme-writer') and provenance ('as returned by search_tools' toolUrl'). This goes beyond a baseline of 3 by teaching the agent where valid values come from.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Fetch the full public detail for one AI tool by its listing slug" uses a specific verb+resource and immediately differentiates from the sibling search_tools by emphasizing 'full public detail.' The description also specifies the exact data returned (launch date, revenue signals, for-sale status), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly sequences usage with 'Call this after search_tools,' names search_tools as the source of the slug, and clarifies behavior for invalid slugs ('Returns null if the slug doesn't resolve'). This provides clear when-to-use context and names the alternative tool it works with, effectively covering the when/alternatives criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Slug of the well-known target tool, e.g. 'chatgpt'. |
| Name | Required | Description |
|---|---|---|
| target | Yes | null when the target slug is not a known product. |
| alternatives | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds the 'live' qualifier and clarifies that the input is a well-known tool slug rather than a catalog slug, preventing a common misuse. No contradictory behavior is stated, and the added context is relevant to how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core action ('List live, same-category alternatives') and then provide usage and parameter guidance without any fluff. Every word earns its place, making it easy for the agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a one-parameter schema, full schema description coverage, a documented output schema, and three annotations, the description is sufficiently complete. The explicit usage trigger and parameter disambiguation cover everything needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'target' with full coverage, but the description adds crucial disambiguation: the slug must be a well-known tool's slug, not a listing slug from this catalog. This nuance is not expressed in the schema and adds real semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'list' with the resource 'alternatives to a well-known AI tool' and clearly distinguishes itself from catalog-listing tools by noting the target is not a listing slug. This makes the tool's purpose unmistakable and differentiates it from siblings like 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It includes an explicit trigger phrase: 'Call this when a user asks...' and clarifies that it covers competitors/substitutes, giving the AI agent clear conditions for selecting this tool. This goes beyond generic context and provides actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| site | Yes | |
| offers | Yes | |
| purchasable | Yes | False during free early access — nothing can be bought. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by noting it returns purchasable flag (readOnlyHint) which is extra context. The description also discloses early-bird status effect, which is behavioral transparency. The description says what is the behavior (purchasable) but the description already covers that, but the description adds the early-bird context, which is valuable. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with three sentences, each packed with relevant information: what the tool lists, that it's free and optional, and the early-bird caveat. There is no fluff or repetition, making it appropriately sized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, annotations are provided (readOnlyHint, idempotentHint), and there is an output schema (though not detailed here). The description covers the key contextual points: that offers are optional add-ons, their purpose, and the early-access limitation. This is sufficient for the agent to use the tool correctly, and the output schema likely details the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so there is nothing for the description to explain. The description still adds meaning by describing what the tool returns (name, effect, price, purchasable flag), which is useful for the agent's decision. With no parameters, the schema coverage is 100% coverage, but the schema coverage is, but the description's description coverage is high, but the schema coverage is the same, but the output schema, but the schema coverage is the same as the same, but the same as the same as the same, so the description adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists optional paid add-ons (offers), specifies the details (name, effect, price), and distinguishes it from alternatives by noting it is the precursor to create_checkout. The verb 'List' with a specific resource (paid add-ons) is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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', providing clear when-to-use guidance. It also explains the purpose (promote listings) and clarifies that during early access, offers are not purchasable, which is a usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Alternativas IA 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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text search term, e.g. a tool name, use-case, or category. |
| Name | Required | Description |
|---|---|---|
| results | Yes | Matching live listings, newest first, capped at 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the description need not restate safety. It adds valuable behavioral detail beyond the annotations: case-insensitive substring matching on specific fields, scope limited to 'live, published' tools, and a 'Returns up to 20 results' limit. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with front-loaded primary action, followed by match behavior, result limit, and usage guidance. Every sentence adds 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with an output schema present, the description fully covers purpose, when to use it, matching behavior, scope, and result cap. The output schema removes the need to explain return values, so no meaningful gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the query parameter already has a description. The tool description enriches the parameter semantics by clarifying exactly what the free-text query matches against ('tool name, tagline, or category name') and that matching is case-insensitive and substring-based, which goes beyond the schema's generic example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair ('Search the Alternativas IA catalog of live, published AI tools') and clearly defines the match targets ('tool name, tagline, or category name'). It further distinguishes itself from siblings by stating 'Call this first when a user asks to find, discover, or compare AI tools', setting it apart from list/get/create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('Call this first when a user asks to find, discover, or compare AI tools by keyword, use-case, or category') with examples. It does not explicitly name when-not-to-use or alternatives, but the instruction to call it first provides strong situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a new AI tool to Alternativas IA 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.
| 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. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| error | No | |
| claimUrl | No | Where the maker signs up to claim the DRAFT. Present only when ok is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already indicate a non-read-only, non-idempotent mutation, the description adds meaningful behavior: the submission creates an unpublished draft, the maker must claim it via a returned claimUrl, and there is a global limit of 5 submissions per hour. This is useful operational context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence earns its place: what the tool does, when it is allowed, and which optional params matter. There is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full workflow—draft creation, claim process, and rate limiting—and the input schema covers parameter details. Since an output schema exists, the description does not need to restate return values, but it still clearly identifies the key output field claimUrl.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters already carry clear meaning. The description adds value by telling agents to provide tagline, problemSolved, logoUrl, and imageUrls whenever possible because they make listings look like real product pages instead of stubs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Submit a new AI tool to Alternativas IA on behalf of its maker.' It also distinguishes this from read/list/sibling tools by explaining that it creates a draft listing and returns a claimUrl, not a public listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use condition: 'Call this only when a user explicitly wants to list their own tool.' It also provides a clear exclusion: never submit a tool on someone else's behalf without their email, which prevents common misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_checkout2 fields changedInput 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."Input schema / properties / product / enumPrevious value: -[
- "premium_launch",
- "review_one",
- "review_monthly"
-]New value: +[
+ "premium_launch",
+ "review_one",
+ "review_monthly",
+ "network_all",
+ "network_three"
+]create_checkout1 field 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"
+}get_tool1 field 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"
+}list_alternatives1 field 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"
+}list_offers1 field 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"
+}search_tools1 field 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"
+}submit_tool1 field 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"
+}create_checkoutget_toollist_alternativeslist_offerssearch_toolssubmit_toolAlternativen zu bekannten KI-Tools, mit über Stripe geprüften Umsätzen statt Schätzungen.
Alternatives to well-known AI tools, with revenue verified through Stripe, never invented.
Catálogo de herramientas de IA por categoría, con fechas reales e ingresos verificados.
KI-Tools nach Kategorien, mit echten Startdaten und über Stripe geprüften Umsätzen.
Add one secure layer between your agents and this server.
