RightAIChoice

What changed in the AI tool market

whats_changed

Read-only

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).

Input Schema

TableJSON Schema

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

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All RightAIChoice tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation3/5

Most tools split cleanly by question shape (single-tool vs pair vs category vs market), but check_tool_status overlaps heavily with viability_score, market_sentiment, and pricing_reality by bundling the same evidence into one verdict. The extensive not-for cross-references help an agent route, yet several boundary cases like 'is this safe to adopt?' could reasonably go to multiple tools.

Naming Consistency3/5

The names are all readable lowercase snake_case, but they mix verb-led names (check_tool_status, compare_tools, find_alternatives, recommend_tools) with noun-phrase names (category_landscape, market_sentiment, pricing_reality, viability_score), and whats_changed follows neither pattern. There is no single consistent verb_noun convention, though the style is still predictable enough to be browsable.

Tool Count5/5

Ten tools is an appropriate size for a domain covering single-tool research, pairwise comparison, recommendations, alternatives, and aggregate market statistics. Each tool has a reasonably narrow slice of responsibility, so none feel redundant or like filler.

Completeness5/5

The set covers the key query lifecycle for AI-tool intelligence: liveness, viability, sentiment, pricing, change history, comparisons, alternatives, recommendations, category health, and market mortality. Cross-references between tools prevent dead ends, and the only notable limitations are explicitly disclosed rather than silently missing.

Resources

Need Help?