Verified data on 8,000+ AI tools for any AI assistant: live status, pricing reality, user sentiment, viability, and alternatives, every answer carries a last-verified date. Free, read-only, no auth.
Scored across 11 tools
Tools mostly target clearly distinct questions (category overview, head-to-head, alternatives, market-wide stats, changes over time), and descriptions include explicit 'Not for' routing. However, check_tool_status and viability_score overlap significantly—both report a tool's health using a 5-signal viability model—so an agent could plausibly confuse liveness verdicts with long-term viability bands.
All names are lowercase snake_case, which is consistent casing. However, the verb/noun convention is mixed: some are verb-first (check_tool_status, compare_tools, find_alternatives, recommend_tools), others are noun-first (category_landscape, market_sentiment, pricing_reality, stack_overlap, viability_score), and whats_changed is a question form.
Eleven tools sit well within the healthy 3-15 range. Each tool maps to a distinct question type (single tool, pair, category, market, stack, change), so every tool appears to earn its place.
The surface covers a strong lifecycle: single-tool status/viability/sentiment/pricing, pairwise comparison, alternatives, need-based recommendations, stack overlap, category and market aggregates, and change tracking. The main gap is a general catalog browse/list or profile lookup independent of a specific need or verdict.
Use this when the user asks what a whole category of AI tools looks like — how crowded it is, how healthy or risky it is overall, which tools in it are strongest, or which are in trouble. Examples: "how risky is the AI video generation market", "what does the code assistant category look like". Returns the number of tools we track in that category, how they distribute across survival bands, the category's vendor-link decay rate, and named examples at both the strongest and weakest ends — each with its own survival score and the date our record of it was last rebuilt. Categories are our own classification and tools belong to several at once, so category sizes overlap and never sum to the catalog total. Bands classify risk, not quality — the model has no notion of company size. Not for: choosing between named tools (use compare_tools), finding a tool for a job (use recommend_tools), or market-wide mortality statistics (use deadpool_digest).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The category, in plain words or as a slug — e.g. "image generation", "code-development". | |
| response_format | No | concise = size, distribution and the strongest few. detailed = adds the weakest end and the decay rate. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/non-destructive/openWorld=false; the description goes well beyond them by disclosing return contents, the overlapping-category caveat (sizes never sum to the catalog total), the semantic caveat that bands classify risk not quality and ignore company size, and the meaning of the last-rebuilt date. These are exactly the interpretive facts an agent needs and cannot get from 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?
Front-loaded with the trigger and the return payload before the caveats and exclusions, and every clause carries information. It is on the long side for a two-parameter tool, but the density means little could be cut without losing routing or interpretation value.
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?
There is no output schema, so the description must describe the response itself, and it does so field by field. Combined with the risk-vs-quality caveat and the accurate sibling routing, an agent has everything needed to invoke this correctly and interpret the result.
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% with a documented enum and default, so the baseline is 3 and the schema already carries the parameter mechanics. The description adds genuine semantic framing for the `category` argument — that categories are the vendor's own classification, that slugs are accepted, and that tools belong to several categories at once — which materially affects how an agent should phrase the 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?
States a specific verb and resource — reporting the risk landscape of an AI tool category — and enumerates exactly what the answer contains (count, band distribution, decay rate, strongest/weakest named examples). It explicitly contrasts itself with siblings compare_tools, recommend_tools and deadpool_digest, so an agent can route without opening a schema.
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?
Opens with a concrete trigger ("when the user asks what a whole category of AI tools looks like"), supplies two realistic example phrasings, and closes with an explicit three-item "Not for" list naming the correct alternative for each. When-to-use, when-not-to-use, and alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether a specific AI tool is alive, dead, shut down, still maintained, safe to adopt, or trustworthy — or asks for its current health, viability, or verification status. Returns a verified verdict (healthy / monitor / at-risk / shut down / delisted) with evidence: link-health probe results, a 5-signal viability assessment, real-user market sentiment, pricing reality, and verified-alive alternatives. Data comes from the RightAIChoice verification engine: 8,000+ AI tools with every vendor link re-probed on a rolling weekly cycle. Every answer states BOTH dates it stands on and does not merge them: when we last probed the vendor links (what the verdict is built on) and when our catalog record was last rebuilt. Not for: tools outside the AI/software space, historical company research, or legal/financial advice. "Not in the catalog" and a verdict of UNKNOWN are DIFFERENT answers: the first means we hold no entry, the second means we hold one whose signals are not measured yet. Neither is evidence the tool is dead.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | The AI tool to check — product name (e.g. "Jasper") or site slug (e.g. "jasper"). Pass an ARRAY of up to 20 names to assess a whole stack at once. | |
| response_format | No | concise = verdict + freshness + source link. detailed = adds viability signals, link health, sentiment, pricing, and alternatives. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds substantial context beyond that: the five verdict types, the evidence returned (link probes, viability signals, sentiment), the data source and refresh cycle, and the important behavior that every answer reports two distinct dates without merging them.
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 dense and front-loads the usage trigger and return value well, but it runs long with multiple clauses and parenthetical lists. Some sentences, such as the detailed explanation of catalog representation versus UNKNOWN, could be tightened without losing meaning.
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 there is no output schema, the description does a good job explaining what is returned (verdict and evidence) and the freshness model. It could say more about how multiple tools in an array are handled or the exact response format, but overall it covers what an agent needs to call and interpret the tool.
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%, so the baseline is 3. The description does not add syntax or format details beyond the schema, though it implicitly explains the concept of a verdict. The schema already documents array usage and response_format enum fully.
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?
States a specific verb (check) and resource (AI tool status) and enumerates the exact user questions it answers (alive, dead, shut down, maintained, safe to adopt). This clearly distinguishes it from sibling tools like viability_score or deadpool_digest, which are single-signal rather than a consolidated verdict.
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?
Explicitly says when to use it (user asks about liveness, viability, trustworthiness) and includes a 'Not for' clause excluding non-AI tools, historical research, and legal/financial advice. It also preempts a critical ambiguity by distinguishing 'not in catalog' from an UNKNOWN verdict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how two specific AI tools compare, which of two tools to choose, or "X vs Y". Returns live verification status for BOTH tools side by side (alive/at-risk/shut-down verdict, the vendor-link probe date AND the separate catalog-rebuild date, pricing reality, market sentiment) plus an editorial head-to-head verdict when a reviewed comparison exists for the pair. Data comes from the RightAIChoice verification engine: 8,000+ AI tools with every vendor link re-probed on a rolling weekly cycle, and 19,000+ maintained comparison analyses. Not for: single-tool checks (use check_tool_status), comparing more than two tools, or category browsing. If either tool is reported as not in the catalog, that is not evidence it is dead.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_a | Yes | First AI tool — product name (e.g. "Jasper") or site slug (e.g. "jasper"). | |
| tool_b | Yes | Second AI tool — product name or site slug. | |
| response_format | No | concise = per-tool verdict + pricing + editorial verdict. detailed = adds sentiment, viability signals, and link health per tool. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare a safe, closed-world read; the description goes well beyond that by disclosing what is returned for each tool (verdict, two distinct probe dates, pricing reality, sentiment, editorial verdict), the update cadence (weekly rolling re-probe), and an important interpretive caveat that absence from the catalog is not evidence of death. That caveat is exactly the kind of non-obvious behavior an agent could otherwise misreport to a user.
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?
Front-loads the trigger condition, then the payload, then provenance, then exclusions — a sound order with no wasted clause. The catalog-size and re-probe statistics are slightly promotional, but they do communicate data freshness, so they nearly earn their place.
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 no output schema, the description carries the return-value burden itself and does so thoroughly, enumerating each returned signal and the two comparison modes. Combined with the exclusions and the catalog caveat, an agent has everything needed to call this 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?
Schema description coverage is 100% and all three parameters carry their own descriptions, including the response_format enum semantics. The description adds no parameter-level detail (no name/slug format guidance, no note on what 'detailed' costs in tokens), so the baseline 3 applies.
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?
States a specific verb and resource ('compare two AI tools head-to-head') and immediately distinguishes itself from siblings by naming the exact conditions it serves ("X vs Y", which-of-two-to-choose). The scope limitation to exactly two tools is unambiguous, so an agent can separate it from check_tool_status and category_landscape without opening any schema.
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 opening trigger sentence tells the agent precisely when to reach for this tool, and the explicit 'Not for:' clause names three excluded cases, routing single-tool checks to check_tool_status and category browsing elsewhere. This is the when/when-not/alternatives trifecta.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how many AI tools die, AI startup failure or shutdown rates, which AI categories decay fastest, how risky the AI tool market is, or for data behind "most AI tools fail" claims. Returns two clearly separated datasets: (1) LIVE catalog decay — 8,000+ verified AI tools with broken vendor-link rates, dead-homepage counts, pricing opacity, and the fastest/slowest-decaying categories, updated daily; (2) a FROZEN dated survival study of 2,291 top Product Hunt launches (of the 2,066 with a determinable outcome, 24.4% are dead within ~2 years). Every figure carries its as-of date. Data comes from the RightAIChoice verification engine; link-decay figures count only VENDOR-published links (site/docs/changelog/repo), never our own derived URLs. Not for: checking one specific tool (use check_tool_status) or predicting a specific tool's future (use viability_score). Decay rates describe categories and cohorts, not individual products.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | concise = headline mortality figures from both datasets. detailed = adds fastest/slowest-decaying categories and survival splits by launch votes and rank. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral context: it returns two clearly separated datasets, provides update cadence ('updated daily'), data provenance ('RightAIChoice verification engine'), and clarifies that link-decay counts only vendor-published links. This goes 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 front-loaded with use cases and structured logically: usage triggers, dataset summary, exclusions, caveats. Every sentence adds value, with no redundancy or filler. It is appropriately sized for the tool's complexity.
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 no output schema, the description goes into sufficient detail about the two returned datasets, including specific numbers (8,000+ tools, 2,291 launches, 24.4% death rate) and the presence of as-of dates. It also clarifies the scope of decay rates (categories/cohorts, not individual products), making the tool's behavior fully understandable.
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 provides 100% coverage for the single parameter 'response_format', including enum values and descriptions for each. The tool description does not add additional parameter context, so the baseline of 3 is appropriate.
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 the tool provides mortality statistics and decay rates for AI tools, answering questions about failure rates and risky market data. It also explicitly distinguishes itself from siblings by saying 'Not for: checking one specific tool (use check_tool_status) or predicting a specific tool's future (use viability_score).'
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 explicit when-to-use guidance ('Use this when the user asks how many AI tools die...') and when-not-to-use, naming specific alternative tools. This covers both inclusion and exclusion criteria effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what to use instead of a specific AI tool, for its alternatives or competitors, or for a replacement because the tool shut down, got acquired, raised prices, or is unreliable. Returns up to 3 verified-alive alternatives from the same category, each with a one-line description, current health verdict, the date our record of it was last rebuilt, and pricing model. If the asked-about tool shut down, says so (with the recorded reason) and returns live replacements. Alternatives come from the RightAIChoice verification engine (8,000+ AI tools, every vendor link re-probed on a rolling weekly cycle), ranked by category and identity-tag match — never filler from unrelated categories. The response states whether results are curated matches or a category roll-up. Not for: comparing two named tools (use compare_tools) or checking a single tool's status (use check_tool_status).
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | The AI tool to find alternatives for — product name (e.g. "Jasper") or site slug (e.g. "jasper"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only safety, and the description adds substantive behavior beyond them: result cap (up to 3), the exact fields returned (description, health verdict, rebuild date, pricing model), the dead-tool fallback behavior with recorded reason, the ranking basis (category + identity-tag match, never cross-category filler), provenance from a weekly re-probed 8,000-tool index, and a flag distinguishing curated matches from category roll-ups.
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?
It is a long description, but it is front-loaded with the trigger and every sentence carries load — return shape, fallback semantics, ranking, provenance, exclusions. The verification-engine sentence is the only one that leans more toward trust marketing than operational guidance, which keeps it just short of 5.
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?
There is no output schema, so the description carries the full burden of describing returns — and it does: result count, per-item fields, the 'shut down' branch, and the curated-vs-roll-up indicator. Given a one-parameter, read-only, openWorld=false tool, nothing an agent needs to invoke or interpret it is missing.
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% and there is a single required param whose accepted forms (product name or site slug) are already documented in the schema. The description refers to 'the asked-about tool' but adds no syntax, normalization, or format guidance beyond what the schema provides, so the baseline 3 applies.
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 opens with a specific trigger verb and resource: 'the user asks what to use instead of a specific AI tool, for its alternatives or competitors.' It clearly separates this from sibling tools by naming compare_tools and check_tool_status as different jobs, so an agent can pick this one without opening any schema.
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 gives explicit positive triggers (replacement, shutdown, acquisition, price rise, unreliability) and an explicit negative section: 'Not for: comparing two named tools (use compare_tools) or checking a single tool's status (use check_tool_status).' Both the when and the when-not, with named alternatives, are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what people actually think of a specific AI tool, whether users like it, its reputation, reviews, community feedback, common complaints, or praised strengths. Returns a synthesized sentiment report from real user discussions (Reddit, Hacker News, GitHub, YouTube, Product Hunt and more): overall sentiment label, per-source positivity, top pros and cons, recurring themes, and mention volume — always stamped with the scan date. Reports come from the RightAIChoice sentiment engine and are served from the verified cache (usability gate: completed scans under 180 days old). If no usable scan is on file, this tool says so honestly instead of guessing. SUBJECT GATE: where we hold a scan but cannot establish that the posts are about this product rather than something else sharing its name, NO score, count or breakdown is returned and the reply says so explicitly. That reply means "we checked and disproved the subject" — it is not an absence of data and not a negative signal about the product. Not for: checking whether a tool is alive (use check_tool_status) or head-to-head choices (use compare_tools). Sentiment reflects public discussion volume, not product quality rankings.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | The AI tool to get sentiment for — product name (e.g. "Jasper") or site slug (e.g. "jasper"). | |
| response_format | No | concise = label, verdict line, top pro/con, mention count. detailed = adds per-source breakdown, up to 4 pros/cons, and recurring themes. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and non-destructive, and the description adds substantial behavioral context: reports come from a verified cache with a 180-day usability gate, the tool honestly reports no usable scan, and the SUBJECT GATE explains the meaning of a no-score reply. This goes well beyond the structured annotations and prevents misinterpretation of empty results.
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 long but front-loaded with the usage trigger and output summary, then covers cache behavior and gate semantics. Information is well organized, though the closing caveat about sentiment reflecting volume not quality is slightly redundant with the earlier 'Not for' sentence.
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?
There is no output schema, so the description must explain return content, which it does in detail (sentiment label, per-source positivity, pros/cons, themes, mention volume, scan date). It also covers failure modes and the distinction between no data and a disproved subject, making the tool fully understandable for an agent with no additional context.
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%: both 'tool' and 'response_format' already have detailed descriptions in the input schema. The description does not add extra parameter semantics beyond what the schema provides, so the baseline 3 is appropriate.
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 opens with a precise use case ('what people actually think of a specific AI tool'), names the resource ('AI tool'), and specifies the exact output: a synthesized sentiment report with label, per-source positivity, pros/cons, themes, and mention volume. It explicitly distinguishes itself from compare_tools by saying it is 'Not for product quality rankings or head-to-head choices'.
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 gives clear 'Use this when' triggers (likes, reputation, reviews, community feedback, complaints) and an explicit 'Not for' exclusion that routes head-to-head comparisons to compare_tools. It also details internal gates (cache usability, subject gate) that determine when results are returned or not, so an agent knows exactly when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what a specific AI tool costs, its pricing model, plans and tiers, whether it has a free tier, hidden costs, or whether the vendor even publishes prices. Returns the recorded pricing model, per-plan prices exactly as the vendor lists them, and — unique to this catalog — documented HIDDEN COSTS: annual-commitment markups, seat minimums, paywalled features, and undisclosed usage fees. Data comes from the RightAIChoice verification engine (8,000+ AI tools re-verified on a rolling weekly cycle). The response distinguishes "the vendor publishes no prices" (their choice — sales call required) from "not recorded in our catalog" (our gap), and never converts currencies. Not for: negotiating quotes, historical price tracking, or financial advice. Prices change frequently — treat the verification date as part of the answer.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | The AI tool to get pricing for — product name (e.g. "Jasper") or site slug (e.g. "jasper"). | |
| response_format | No | concise = pricing model + plan prices + top 2 hidden costs. detailed = full plan list with key features and up to 6 hidden costs. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and destructiveHint, but the description adds significant behavioral context: data source (RightAIChoice engine), re-verification frequency, differentiation between vendor-no-prices and catalog-gap, and currency non-conversion. Also notes 'Prices change frequently' and verification date as part of answer, going 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 lengthy but each sentence adds distinct value: hidden costs, data source, exclusions, and verification date. It is front-loaded with the use case and clearly structured. While not terse, it avoids fluff and maintains organization.
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 pricing tool with two parameters, no output schema, and rich annotations, the description provides complete context: return contents, hidden costs, distinction between no-prices and not-recorded, and verification date. It adequately covers user expectations and edge cases, making it self-sufficient.
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%, meeting the baseline, but the description adds meaning for response_format by explaining the exact differences (concise vs detailed outputs). The tool parameter is already descriptive in schema, but this extra detail for response_format elevates the score.
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?
Description uses specific verb ('get', 'fetch') and resource ('pricing of AI tools'), clearly distinguishing itself from siblings by highlighting hidden costs and verification engine. It explicitly states 'Use this when the user asks what a specific AI tool costs' and scopes to pricing queries.
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?
Explicitly states when to use ('when the user asks what a specific AI tool costs') and provides clear exclusions ('Not for: negotiating quotes, historical price tracking, or financial advice'). Though it doesn't name alternative tools, the exclusions and context are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user describes what they need an AI tool to DO rather than naming one — "something to transcribe interviews", "an image generator with an API", "a writing tool for a small team". Returns a verified shortlist matched on the described need, filtered by constraints the caller sets, and — unique to this catalog — screened against a survival bar: tools failing our link-health probes or scoring badly on the 5-signal viability model can be excluded outright. Each result carries its own health verdict, the date our record of it was last rebuilt, and pricing model. Matching is keyword and fuzzy text search over 8,000+ verified tools; the response states this. Tools with no viability measurement yet are listed separately by name rather than silently dropped. Not for: questions about a tool the user already named (use check_tool_status), head-to-head choices (use compare_tools), or filtering by price amount — prices are recorded verbatim in mixed currencies and are never converted or compared numerically.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What the tool must do, in the user's own words. e.g. "transcribe podcast interviews with speaker labels". | |
| limit | No | How many results to return (max 10). | |
| requires_api | No | Only return tools recorded as offering an API. | |
| survival_bar | No | exclude_at_risk = drop tools scoring below the at-risk threshold, with a failing main site, or whose published website now redirects to a different company. safe_bet_only = only the strongest band. none = no survival screening (moved-identity tools are then returned WITH the move stated). | exclude_at_risk |
| pricing_model | No | Filter by recorded pricing model. has_free_option = free or freemium. There is no price-amount filter: prices are verbatim strings in mixed currencies. | any |
| exclude_wrappers | No | Exclude tools assessed as thin wrappers around a third-party model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, openWorldHint=false) already declare this is a safe, closed-world read. The description goes well beyond them by disclosing survival screening mechanics (link-health probes, 5-signal viability model), the separate listing of unmeasured tools, and the response contents (health verdict, record rebuild date, pricing model). However, it does not cover pagination, ordering, or how fuzzy-match confidence is surfaced.
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?
Long but densely front-loaded: the trigger condition comes first, then return shape, then the 'Not for' routing. Every sentence carries routing or behavioral information; the length is justified by the number of decision points, though it is near the upper bound of what an agent will parse comfortably.
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?
No output schema exists, and the description compensates fully by describing the response (shortlist matched on need plus constraints, per-result health verdict, rebuild date, pricing model, CTA that the matching method is keyword/fuzzy). With 6 params and 2 enums, nothing an agent needs to call correctly is missing.
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%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains what survival_bar=exclude_at_risk actually drops (below-threshold scores, failing main site, redirected domain) and why no price-amount filter exists. These enrich the enum semantics rather than restating them.
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?
States a specific verb+resource (recommend AI tools for a described need) and immediately frames the distinguishing condition — user describes a job, not a named tool. It also names the sibling tools it is not (check_tool_status, compare_tools), so an agent can route without opening another schema.
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?
Explicit 'use this when' trigger is given with concrete example phrasings, plus a 'Not for:' clause naming two alternatives and the exact condition that selects each. The price-amount exclusion is also stated as a hard boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether the AI tools they pay for duplicate each other — "are we paying twice", "does our stack overlap", "can we consolidate these". Give it the tools they actually pay for. Returns the pairs we classify the same way, with the shared categories and shared capability tags named for each pair so the user can judge the claim themselves. IMPORTANT: this compares how RightAIChoice classifies two products — not their features, their APIs, or what a team does with them. It is a prompt to review a pair, never evidence that either is redundant. It never recommends cancelling anything and never totals cost, because plan and seat count are unknown. Not for: feature-by-feature comparison of two named tools (use compare_tools), finding a replacement (use find_alternatives), or calculating spend.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | Yes | The tools the team pays for — product names or slugs. Between 2 and 15. | |
| response_format | No | concise = overlapping pairs only. detailed = also lists pairs we found no overlap between. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (read-only, closed-world), so the description carries the substantive disclosure: the output is classification-based pairs with named shared categories/tags, it is a review prompt rather than proof of redundancy, and it deliberately never recommends cancellation or totals cost because plan/seat count is unknown. That is meaningful context an agent cannot get from 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?
Front-loaded with the trigger condition and tightly packed with routing and limitation info, but slightly redundant — the 'never recommends cancelling' and 'never totals cost' clauses restate the same non-actionable-output point and could be compressed.
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?
There is no output schema, so the description correctly specifies what comes back (overlapping pairs with shared categories and capability tags) and what will not (cost totals, cancellation advice). Combined with the trigger and exclusion guidance, nothing needed to call it correctly is missing.
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%, so the baseline is 3, but the description adds real guidance on the tools parameter ("give it the tools they actually pay for"), scoping input to paid products rather than tools merely used or evaluated. response_format semantics are fully covered by the schema, so no further gain.
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?
States a specific verb and resource (detect duplicate/overlapping paid AI tools) and immediately disambiguates from siblings by naming compare_tools and find_alternatives as different operations. An agent can distinguish this from every sibling without opening a schema.
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?
Gives concrete user phrasings that should trigger it ("are we paying twice", "does our stack overlap"), plus an explicit Not-for list with the correct alternative for each excluded case. When/when-not/alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether a specific AI tool is safe to adopt or build on, likely to still exist next year, well-maintained, gaining or losing momentum — or asks about its long-term viability or abandonment risk. Returns a viability BAND (safe bet / moderate / at risk) with the five measured drivers behind it: what the vendor publishes, site health, traction, user sentiment, and recent activity — plus which signal is weakest and why, in plain language. Assessments come from the RightAIChoice verification engine (8,000+ AI tools, every vendor link re-probed on a rolling weekly cycle). A null driver means "not yet measured", which is different from a bad score. Bands are NOT a leaderboard: they classify risk, they do not rank tools against each other. Not for: comparing two tools (use compare_tools), liveness checks alone (use check_tool_status), or investment decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | The AI tool to assess — product name (e.g. "Jasper") or site slug (e.g. "jasper"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate read-only and non-destructive behavior, the description goes far beyond by detailing the output structure (viability band with five drivers, weakest signal explanation), the data source (RightAIChoice verification engine with weekly re-probing), and handling of nulls ('null driver means "not yet measured"'). It also clarifies that bands classify risk rather than rank, preventing misinterpretation. 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 longer than average but every sentence serves a purpose: usage, output description, data source, null handling, band interpretation, and exclusions. It is well-organized and front-loaded with the primary use case. A slight reduction in wordiness could earn a 5, but it remains concise relative to the information density.
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 no output schema, the description fully specifies what is returned (band, drivers, weakest signal) and clarifies nuances (null vs bad, band not a leaderboard). It also provides context on the verification engine's scope and freshness. Combined with the clear input schema and usage boundaries, nothing important is missing for the agent to invoke and interpret results 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?
The only parameter 'tool' is already thoroughly described in the schema (product name or site slug with examples). Since schema coverage is 100% and the description does not add new parameter semantics beyond the schema, the baseline score of 3 is appropriate. The description's mention of 'specific AI tool' in the usage does not add extra meaning 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 opens with a specific verb-resource pairing: assessing the viability of an AI tool for adoption or building. It enumerates the types of queries it answers (safe to adopt, likely to survive, maintenance, momentum, abandonment risk) and explicitly distinguishes itself from sibling tools (compare_tools, check_tool_status), 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use criteria: user asks about safety, longevity, maintenance, momentum, or abandonment risk. Also gives explicit exclusions with alternatives: 'Not for: comparing two tools (use compare_tools), liveness checks alone (use check_tool_status), or investment decisions.' This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what has changed recently in AI tools — whether a specific tool has changed its pricing, links, domain or health, or what has moved across the market since a given date. Returns dated, field-level changes we actually observed: vendor pricing-page edits, recorded price changes, link health moving, domain and certificate changes, and vendors moving their site. Each carries the date we observed it and how. Reports only VENDOR-OBSERVABLE changes by default — our own editorial rewrites are excluded and the response says so, because our writing changing is not the market moving. Our change record begins on a fixed date stated in every answer; asking about an earlier period returns that date rather than an empty result. Not for: predicting future changes, or a tool's current status (use check_tool_status).
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Optional. A single AI tool — product name or slug. Omit for a market-wide summary. | |
| since | No | Optional ISO date (YYYY-MM-DD). Defaults to 7 days ago. Earlier than our coverage floor returns the floor. | |
| include | No | vendor_changes = only what the vendor did. vendor_and_our_assessment = also our survival re-scores. Our editorial rewrites are never included. | vendor_changes |
| response_format | No | concise = counts plus the most notable changes. detailed = the individual dated changes. | concise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior beyond that: the fixed coverage floor date, the vendor-observable-only default, the exclusion of editorial changes, and the fact that each change carries an observation date and method. 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?
Although longer than average, every sentence earns its place: usage trigger, return format, exclusion policy, coverage floor, and alternatives. The most decision-critical information is front-loaded, and the 'Not for' clause cleanly closes ambiguity.
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 read-only, four-optional-parameter tool with no output schema, the description is complete. It explains what is returned, how data is observed, what is excluded, the coverage floor behavior, and when not to use it. The sibling name for current status closes the main routing gap.
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 all four parameters (tool, since, include, response_format) are already documented with defaults and enums in the schema. The description reinforces the conceptual model (e.g., coverage floor) but does not need to repeat parameter mechanics. Baseline 3 is appropriate.
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 the tool's specific purpose: reporting observed, dated changes in AI tools (pricing, links, domain, health) and market movement since a date. It names the resource (AI tool market changes) and distinguishes itself from check_tool_status by explicitly excluding current-status queries.
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 concrete when-to-use triggers ('when the user asks what has changed recently'), states what is excluded (editorial rewrites, future predictions), and explicitly routes current-status queries to check_tool_status. This is exemplary usage guidance.
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.
stack_overlaprecommend_tools1 field changedInput schema / properties / survival_bar / descriptionPrevious value: -"exclude_at_risk = drop tools scoring below the at-risk threshold or with a failing main site. safe_bet_only = only the strongest band. none = no survival screening."New value: +"exclude_at_risk = drop tools scoring below the at-risk threshold, with a failing main site, or whose published website now redirects to a different company. safe_bet_only = only the strongest band. none = no survival screening (moved-identity tools are then returned WITH the move stated)."category_landscapecheck_tool_status5 fields changedInput schema / properties / tool / anyOfAdded value: +[
+ {
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / tool / descriptionPrevious value: -"The AI tool to check — product name (e.g. \"Jasper\") or site slug (e.g. \"jasper\"). One tool per call."New value: +"The AI tool to check — product name (e.g. \"Jasper\") or site slug (e.g. \"jasper\"). Pass an ARRAY of up to 20 names to assess a whole stack at once."Input schema / properties / tool / maxLengthRemoved value: -120Input schema / properties / tool / minLengthRemoved value: -1Input schema / properties / tool / typeRemoved value: -"string"recommend_toolswhats_changedcheck_tool_statuscompare_toolsdeadpool_digestfind_alternativesmarket_sentimentpricing_realityviability_score
Add one secure layer between your agents and this server.