webdata-tools-mcp

Check how new or crowded an idea is

validate_idea

Read-onlyIdempotent

Assess how much research already covers a product or research idea: matching works, recent activity, crowdedness, growth, key researchers and institutions, closest prior work and related patents.

Instructions

How much research already covers a product or research idea: matching works, works in the last two years, crowdedness (open, early, active, crowded), growth, who is working on it (researchers, institutions, companies), the closest prior work and related patents. For a written assessment, use the idea-validation prompt. Runs the Apify Actor tacps126/innovation-radar on your Apify account (about $0.03 per idea; spend per call is capped at $0.5).

Input Schema

Name	Required	Description	Default
`ideas`	Yes	Ideas in plain words, e.g. "a window that generates solar power with perovskite tandem cells".
`extra_input`	No	Advanced: extra Actor input fields, merged over the defaults.

Output Schema

Name	Required	Description
`tool`	Yes	Name of the tool that produced the result.
`count`	Yes	Number of records the Actor returned.
`items`	Yes	The records. Long text fields are shortened to 600 characters.
`shown`	Yes	Number of records included in `items` (can be lower than count when the result is long).
`truncated`	Yes	True when records were left out to keep the result short; ask for fewer items.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.10.1Oct 23, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful operational context beyond that: it runs the tacps126/innovation-radar Apify Actor on the user's Apify account, costs about $0.03 per idea, and caps spend per call at $0.5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with what the tool returns, then adds the prompt alternative and cost/account details. The first sentence is a dense list, but every element is useful and there is little wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values, but it helpfully summarizes them anyway. It also covers the external Actor, cost, and account context; only minor details such as authentication prerequisites or batch behavior for multiple ideas are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters, including the required ideas array and advanced extra_input. The description adds only implicit context such as 'per idea' and does not materially extend parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies what the tool returns for an idea: matching works, recent works, crowdedness level, growth, researchers/institutions/companies, prior work, and patents. This is much more specific than a generic idea-check tool, though it does not explicitly name sibling tools like search_research or analyze_field to sharpen differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one useful routing hint: use the idea-validation prompt for a written assessment. However, it does not explain when to choose this tool over sibling research tools, nor does it state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.