TGGET Niche Research

Name: TGGET Niche Research
Author: tgget

Server Details

Validate app and SaaS ideas: search demand, competitors, app store data and a verdict.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.6% over 23 days
Last Tested: 2026-10-21 00:12
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: tgget/tgget-mcp
GitHub Stars: 0

TDQS

A4.2/5.0

Scored 2026-10-07 11:30 across 10 tools

Disambiguation5/5

Each tool targets a distinct purpose: starting research, polling status, retrieving the final report, following a niche, managing projects, comparing scans, or adding checks. Overlaps are minimal and descriptions clarify boundaries, such as get_research (status/findings) vs get_report (final markdown report).

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., start_research, get_report, list_projects, update_project). Verbs and nouns are used predictably, with no mixing of conventions.

Tool Count5/5

With 10 tools, the set is well-scoped for a niche research service. Each tool earns its place by covering distinct operations from research creation to reporting, following, comparing, and project management.

Completeness4/5

The tool surface covers the core lifecycle: creating research, checking status, retrieving reports, following niches, managing projects, comparing scans, and adding checks. Minor gaps exist, such as no way to cancel or delete a research, and no shareable link for individual reports (though compare_research provides one).

Available Tools

10 tools

compare_researchCompare ResearchA

Read-only

Inspect

Puts two to five finished niche scans side by side to help choose between ideas. items are the niches with their numbers, the report's positioning and napkin economics, and wins: in how many rows the niche holds the better value. rows are the ranked measures (verdict, demand, trend, cost per click, weak search results, competitor sites, App Store apps, fresh community signals) with the value of every niche and best, the indexes of the items that hold the better value; better says which way is better (max or min), null when the row is shown but not ranked. Every item names the country and the language its demand was measured in; demand and cost per click are not ranked across different markets, countries or languages (mixed_markets). The marks are computed from numbers, not written by a language model. Every scan needs a finished report. share_url is a read-only link to this comparison that works without signing in: give it to the person only when they want to share the comparison, it shows the numbers and the conclusions of their researches to whoever holds it.

ParametersJSON Schema

Name	Required	Description	Default
`ids`	Yes	Two to five ids of finished niche scans (or of their reports), as listed by list_research.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest and delivers real value: marks are computed from numbers rather than written by a language model, demand/CPC are never ranked across different markets (mixed_markets), and share_url is a no-sign-in link that exposes numbers and conclusions to anyone holding it.

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?

Purpose and prerequisite are front-loaded, and the dense output prose is justified because there is no output schema. It is nonetheless long and heavy for a single-parameter tool, with the rows/items/best/better enumeration bordering on verbose.

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?

With no output schema and only a readOnlyHint annotation, the description compensates fully: it explains the return structure (items, wins, rows, best, better), market-comparability rules, and the sharing semantics of share_url. An agent has everything needed to call and interpret it.

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

Parameters3/5

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

Schema description coverage is 100% and there is a single param, so the schema already documents 'ids'. The description reinforces that scans must be finished but adds no format or syntax detail beyond the schema, making the baseline 3 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?

States a specific verb (compare) and resource (two to five finished niche scans) plus the goal (choosing between ideas). This clearly distinguishes it from siblings like get_research and list_research, which handle single scans or listings.

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

Usage Guidelines4/5

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

Gives a clear use context ('help choose between ideas') and a hard prerequisite ('Every scan needs a finished report'), and constrains the range to two-to-five. It stops short of naming an explicit alternative tool for single-scan inspection, so it lands just below the top.

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

follow_nicheFollow NicheAInspect

Starts following the niche of a finished scan that has a report: the scan becomes the first measurement and the niche is scanned anew every month, with a digest of what changed sent to the account. Monthly checks do not spend researches; the plan limits how many niches are followed (FREE 1, Starter 2, Pro 10). Following a niche that is already followed returns its project. The niche is followed in the country and the language its scan was measured in (country and language of the project), so every monthly check measures the same audience.

ParametersJSON Schema

Name	Required	Description	Default
`research_id`	Yes	Id of a finished niche scan, or of its report.

TDQS

A4.4/5.0

Behavior5/5

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

With zero annotations the description carries the full burden and delivers: recurring monthly rescanning, change digests emailed to the account, no research spend on monthly checks, per-plan follow limits (FREE 1 / Starter 2 / Pro 10), idempotent repeat behavior, and country/language inheritance from the original scan. This is exactly the mutation-and-side-effect context an agent needs.

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

Conciseness5/5

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

Front-loaded with the action and its prerequisite, then layered with cost, quota, idempotency, and scoping facts. No sentence is filler and each one answers a distinct question an agent would otherwise have to guess at.

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?

For a no-annotation, no-output-schema tool the description is thorough on side effects, limits, and scoping. The only gap is the exact return payload on a first-time follow (the repeat case is described as returning the project, but the initial response is not spelled out).

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

Parameters3/5

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

Schema description coverage is 100% and the schema already states that research_id is the id of a finished scan or its report; the description adds the requirement that the scan be finished and have a report but no new syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ('Starts following the niche of a finished scan') and pins the precondition ('that has a report'), which no sibling tool offers. An agent can distinguish this from get_project, list_projects, or run_signal purely from the first clause.

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

Usage Guidelines4/5

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

Gives the operative precondition (a finished scan with a report) and the repeat-call behavior ('Following a niche that is already followed returns its project'), which tells the agent when a re-invocation is safe. It does not name an alternative sibling for the case of an unfinished scan, but the context is clear enough.

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

get_projectGet ProjectA

Read-only

Inspect

Returns a followed niche with the history of its checks, newest first: the first measurement (baseline) and the monthly checks, each with its numbers, what changed since the previous check and the id of the research it came from. Pass that research_id to get_report to read the fresh report of a check. Changes are computed from numbers and lists, not written by a language model.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Project id listed by list_projects.

TDQS

A3.7/5.0

Behavior4/5

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

With readOnlyHint already covering the safety profile, the description still adds real context: results are newest-first, the baseline is the first measurement, each check carries what changed since the previous check, and changes are computed deterministically rather than by an LLM. This is substantive disclosure beyond 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.

Conciseness4/5

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

Well front-loaded: the return shape leads, the downstream should not be the first focus, and each sentence carries information. Slightly dense with backticked field names but no wasted sentences.

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?

No output schema exists, so the description must describe return values, and it does so clearly (baseline, monthly checks, numbers, deltas, research_id). It is complete enough to call the tool correctly, with only the sibling-differentiation gap remaining.

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 coverage is 100% and there is one parameter, whose provenance is already documented in the schema ('Project id listed by list_projects'). The description adds no further meaning to the id argument, so the baseline of 3 for high coverage applies.

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?

States a specific verb (returns) and resource (a followed niche with its history of checks), and details the shape of the payload: baseline plus monthly checks, with numbers and changes. It implicitly distinguishes itself from get_report by routing the agent there for the fresh report, but does not explicitly contrast with siblings like get_research or list_projects.

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 a useful chain hint ('Pass that research_id to get_report'), which implies this tool is the entry point for reading a project's check history. However, it never states when to use get_project versus get_research, list_projects, or get_report directly, so the routing guidance is only inferred.

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

get_reportGet ReportA

Read-only

Inspect

Returns the final niche report of a finished scan (or the report research itself) as Markdown: verdict, what product to build (customer pains with evidence and severity, positioning, MVP with the pain each feature relieves, platform, monetization, competitor matrix), napkin economics (price hypothesis, acquisition cost from the cost per click in paid search, revenue per customer, whether it adds up, assumptions), SEO plan for the site (clusters, pages with title/H1/description, content plan, FAQ), ASO for App Store and Google Play, name options with domain and App Store availability, landing page draft, distribution channels by type with a first step, effort and priority, validation steps and risks. Pass format "json" for structured data (keys: verdict, product, economics, seo, aso, names, landing, channels, validation, risks).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Id of the scan research (its latest report is returned) or of the report itself.
`format`	No	markdown (default) for reading, json for structured fields.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest — it discloses that a research id returns that research's latest report, that markdown is the default output mode, and that json yields a fixed key set. It does not mention error behavior for an unfinished scan, which keeps it short of a 5.

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

Conciseness3/5

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

Purpose is front-loaded correctly, but the middle is a single sprawling sentence enumerating every report subsection (economics, SEO, ASO, names, landing, channels...). Much of that detail is useful for a missing output schema, yet it is delivered densely enough that the format instruction nearly gets lost at the end.

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?

There is no output schema, so the description must describe returns — and it does so exhaustively, mapping markdown content and json keys section by section, plus the id/format semantics. With readOnlyHint covering the safety profile, 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.

Parameters4/5

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: it clarifies that 'id' accepts either a research id (latest report returned) or a report id, and it lists the ten json keys the format switch produces, which the schema's bare enum does not convey.

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?

States a specific verb and resource ('returns the final niche report of a finished scan') and enumerates the exact contents it returns, so an agent can distinguish it from get_research or get_project without opening a schema. The parenthetical '(or the report research itself)' further pins the scope.

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?

Usage is implied (call this to read a finished scan's report) and it gives one actionable instruction — pass format "json" for structured data. However, it never states when to prefer this over sibling retrieval tools like get_research, nor any prerequisite such as the scan having finished.

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

get_researchGet ResearchA

Read-only

Inspect

Returns the current state and findings of a research by id: status, country and language the demand was measured in (null where a source does not measure by country), headline numbers, ranked candidate phrases, competitor overview, child researches (sub-topics, competitor checks, signals) with their ids, and skipped stages. Call repeatedly until status is completed and pending is 0.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Research id returned by start_research or listed by list_research.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description goes further by disclosing the polling/eventually-complete nature of the resource and the null semantics of the country field when a source does not measure by country — real behavioral context beyond the annotation.

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?

One dense front-loaded sentence that names the resource first, followed by a short operational instruction. The long field enumeration is justified because there is no output schema, and no sentence is padding.

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?

With no output schema, the description carries the burden of describing the return payload, and it does so thoroughly, plus the polling termination condition. It omits failure modes (invalid id, failed/cancelled research) and pagination, which would be the remaining 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% and the single id parameter is fully documented in the schema, including its provenance ('returned by start_research or listed by list_research'). The description adds only 'by id' with no extra format or validation detail, so the baseline 3 applies.

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 states a specific verb (returns) and resource (research by id) and enumerates the payload contents — status, headline numbers, ranked phrases, competitor overview, child researches. It is clearly distinct from a bare getter, though it never explicitly contrasts itself with siblings like get_report, compare_research, or list_research.

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

Usage Guidelines4/5

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

It gives a concrete usage protocol: 'Call repeatedly until status is completed and pending is 0', which tells the agent this is a polling endpoint and defines the termination condition. It does not, however, say when to prefer it over list_research (discovery) or get_report (exported output).

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

list_projectsList ProjectsA

Read-only

Inspect

Lists the niches the account follows. A followed niche (a project) is scanned anew once a month and compared with its previous check. For each project: status, whether the plan serves it, the date of the next check, the latest numbers (verdict, demand, cost per click, competitor sites, App Store, community signals) and what changed at the latest monthly check, as structured changes and as digest lines of text. Also returns how many niches the plan follows.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many projects to return, 1-50 (default 20).

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds genuinely useful behavior beyond that, disclosing the monthly rescan-and-compare cadence and enumerating what each returned record contains (status, plan coverage, next check date, latest metrics, changes/digest). It stops short of mentioning pagination behavior or input constraints.

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?

Front-loaded with the core action and definition, then a dense but purposeful inventory of returned fields. Slightly heavy in the middle clause listing every metric, but no sentence is filler given the absence of an output schema.

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?

With no output schema and only one parameter, the description fully carries the burden of describing the return payload, including change data as both structured `changes` and `digest` text plus a count of followed niches. An agent has everything needed to call and interpret this tool.

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 coverage is 100% and the single `limit` parameter is fully documented in the schema (range 1-50, default 20). The description adds nothing about the parameter, which is acceptable given the schema does the work, so the baseline 3 applies.

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?

States a specific verb and resource ('Lists the niches the account follows') and immediately resolves the domain ambiguity by defining a project as a followed niche that is rescanned monthly. This cleanly separates it from siblings like list_research, get_project, and follow_niche without needing to name them.

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?

Usage is only implied: an agent can infer this is the enumeration tool for followed niches, but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as get_project for a single niche or list_research for research artifacts.

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

list_researchList ResearchA

Read-only

Inspect

Lists the researches the account started itself, newest first: niche scans of a phrase and descriptions of an idea, without the checks they spawned. Use it to find the id of an earlier research before get_research, get_report, compare_research or follow_niche, or to see what is still running. Each item has id, kind, phrase, status (queued, running, completed, failed), mode, country and language the demand was measured in, created_at, url of its page and total_count: monthly searches of the phrase, null for a description. quota tells how many researches the plan has left. Reads only; spends nothing.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many researches to return, from 1 to 50. Default 10.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description goes further: 'Reads only; spends nothing' rules out quota consumption, and it explains that `quota` reports researches left in the plan, plus the meaning of each status value. It stops short of describing pagination/ordering behaviour beyond 'newest first' or rate limits, so not a 5.

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?

Purpose and scoping come first, then routing guidance, then field semantics — a logical front-loaded order with no filler. The field enumeration earns its place because there is no output schema to document return values.

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?

With no output schema, the description takes on return-value documentation and does so field by field, including null semantics for descriptions and the status enum values. Combined with routing guidance and the 'spends nothing' note, an agent has everything needed to call it correctly.

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 coverage is 100% and the single `limit` parameter (1-50, default 10) is fully documented in the schema; the description never mentions it. Baseline 3 is appropriate since the schema carries all parameter meaning, though it does add useful semantics for the returned `total_count` and `quota` fields.

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?

States a specific verb and resource plus precise scope: researches the account started itself, newest first, excluding the checks they spawned. An agent can distinguish it from get_research or list_projects 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.

Usage Guidelines5/5

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

Explicitly names the downstream alternatives (get_research, get_report, compare_research, follow_niche) and the condition for using this tool first — resolving a research id. It also covers the secondary use case of seeing what is still running, so nothing is left to inference.

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

run_signalRun SignalAInspect

Adds one check to a finished research and returns the id of the new child research. Use it when the scan skipped a stage, when a person asks about one phrase in particular, or to rebuild the report after new checks. A niche scan already runs the usual checks by itself, so this tool is for what is missing. Checks added this way are free: they do not spend researches of the plan.

Checks of a demand research (kind):

competitors: who holds the search results for a phrase of the research; pass the phrase in phrase.
dynamics: two years of demand history.
appstore: App Store apps for the phrase with ratings and freshness.
wiki, radar, youtube: public interest and community signals.
paid: paid search for the phrase and its strongest candidates: volume, advertiser competition, cost per click.
insight: a summary of the findings written by the language model.
report: the final niche report, written anew from the current data; needs a finished niche scan.

Checks of a child research:

fingerprint: product sites found by a competitors check, with pricing and app links; the parent is that competitors check.
reviews: recent App Store reviews of the leaders; the parent is an App Store research.
insight also accepts a competitors check as the parent.

The parent must be completed and belong to the account. The check runs in the background: poll get_research with the returned id every 20-30 seconds until status is completed. insight and report are rebuilt at most once an hour.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Id of the completed research the check is added to, as returned by start_research, get_research or list_research.
`kind`	Yes	Which check to add. competitors, dynamics, appstore, wiki, radar, youtube, paid and report need a demand research as the parent; fingerprint a competitors check; reviews an App Store research; insight a demand research or a competitors check.
`locale`	No	Only for insight and report: language of the text. Defaults to the language the research was started with, then to the language of the account.
`phrase`	No	Only for competitors: the phrase whose search results are checked, usually one of the candidate phrases of the parent. Defaults to the phrase of the parent. Ignored by the other checks.

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses that checks run in the background, that the caller must poll get_research every 20-30 seconds until status is completed, that added checks are free, and that insight/report are rebuilt at most once an hour. It also states the parent must be completed and owned by the account.

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?

Purpose and the background/polling contract are front-loaded, and the check catalog is neatly grouped into demand-research vs child-research bullets. The length is largely justified by eleven enum values, though a few lines border on redundant with the schema's own kind description.

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 no-output-schema tool, the description covers the return value (the new child research id), the async completion contract, rate limits, cost, and parent constraints. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining what each of the eleven kind values actually means and which parent each requires, and clarifies locale/phrase defaults and scope. It adds real semantic value beyond the enum labels.

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?

States a specific verb and resource ('Adds one check to a finished research') plus the return value (id of the new child research). An agent can immediately distinguish this from start_research (creates the research) and get_research (polls it).

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?

Explicitly enumerates when to use it ('when the scan skipped a stage, when a person asks about one phrase in particular, or to rebuild the report after new checks') and when not to ('a niche scan already runs the usual checks by itself, so this tool is for what is missing'). It also routes to correct parents per check type.

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

start_researchStart ResearchAInspect

Starts a niche research from a short search phrase or a plain-language description of an app or service idea. A phrase is scanned directly (demand, sub-topics, competitors, signals); a description is first turned into real search queries, the best one is then scanned automatically. Demand is measured in one country and one language: country and language when given, otherwise the country and the language of the phrase (English: United States, Spanish: Spain, Portuguese: Brazil); write the phrase in the language people search in there. country and language of the answer tell how the numbers were measured. Returns the research id to poll with get_research. Counts as one research of the plan allowance, whether the data comes from the sources or from the shared cache.

ParametersJSON Schema

Name	Required	Description
`deep`	No	Deeper scan with more sub-topics and competitor checks. Available on plans that include it (Pro) and to administrators; counted as two researches.
`text`	Yes	Search phrase (e.g. "expense tracker") or a description of the idea in your own words, up to 400 characters.
`locale`	No	Language of the conclusions and the final report. Defaults to the interface language of the account. Texts meant for the site and the stores are always written in the language of the market.
`country`	No	Country to measure demand in, as an ISO 3166-1 alpha-2 code (BR, MX, PT, AR, CO, US, GB, DE, KZ, RU, BY…). App Store apps are looked up in the same country, the report writes prices, channels and copy for it, and sub-topics are measured there too. Omit it to use the country of the phrase's language. The phrase is measured in its own language when the country has it (Spanish in the United States), otherwise in the country's main language, so write it the way people search in that country.
`language`	No	Language the demand is measured in, when the guess from the phrase is not enough: French in Canada (CA + fr), Italian in Switzerland (CH + it), Spanish in the United States (US + es). It must be one of the languages of `country`; given without `country` it picks the main country of the language (pt: Brazil, nl: Netherlands). Omit it to use the language of the phrase.

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does add real behavioral context: it discloses billing (counts as one research, from sources or shared cache; deep counts as two), availability gating (Pro/admin), and how country/language are resolved and reported. It omits auth requirements and latency/rate details, but the cost and defaulting behavior is unusually well disclosed.

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 the core action and stays in a single dense paragraph with no filler sentences. It is somewhat long and overlaps with schema documentation, but every clause carries information.

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

Completeness5/5

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

For a tool with no output schema, the description supplies the missing return contract ("returns the research id to poll with get_research"), plus billing, defaulting, and language-resolution rules. Nothing an agent needs to invoke it correctly appears to be missing.

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 the country/language/deep semantics in detail. The description largely restates the same defaulting logic (English: US, Spanish: Spain, Portuguese: Brazil) and adds the useful note that the answer's country/language reveal how numbers were measured, but contributes little beyond the schema. Baseline 3 applies.

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 states a specific verb+resource ("Starts a niche research") and explains the two input modes: a phrase is scanned directly, a description is converted to queries first. It names get_research as the polling target, but does not differentiate from other siblings like compare_research or follow_niche.

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

Usage Guidelines4/5

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

It clearly explains the conditions under which each input type is treated (phrase scanned directly vs. description converted and best query scanned) and what to do next (poll with get_research). No explicit when-not or comparison against sibling tools, but the usage context is clear.

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

update_projectUpdate ProjectA

Destructive

Inspect

Pauses a followed niche (paused: no monthly checks, its place in the plan is freed), follows it again (active, needs a free place in the plan) or stops following it (deleted: the project with its checks and digests is removed for good, the researches stay in the history). Ask the person before deleting.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Project id listed by list_projects.
`status`	Yes	active, paused or deleted.

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only declare destructiveHint=true, and the description substantially enriches this: deletion removes the project, its checks and digests permanently while research stays in history, pausing frees the plan slot, and reactivation consumes a free slot. It also flags a human confirmation requirement before destructive action.

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?

A single dense sentence with parenthetical mode glosses, front-loading 'pauses... follows... stops following' then qualifying each. Nothing is wasted, though the nested parentheses make it slightly harder to scan than a clean list.

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?

For a two-parameter mutation with no output schema and minimal annotations, the description covers consequences, preconditions and the human-confirmation need. It still omits what happens on failure (e.g., activating with no free plan slot) and does not mention the follow_niche relationship.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the schema's own status description merely restates the enum values. The description adds genuine semantics for each value (freed plan slot, required free slot, permanent removal, history retention) that the schema does not convey.

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 gives a specific verb+resource+effect: it updates a followed project's status to one of three named states and describes what each one means. It fails to differentiate from the sibling follow_niche, which also causes a project to become 'active', so the agent must infer the boundary.

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

Usage Guidelines4/5

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

Usage is clear per mode: pause frees the plan slot, active requires a free slot, deleted is permanent, and the user should be asked before deleting. There is no explicit 'prefer X over Y' routing against follow_niche, so it stops short of full when/when-not guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 7, 2026

Changedstart_research3 fields changed

changedInput schema / properties / country / description

Previous value: -"Country to measure demand in, as an ISO 3166-1 alpha-2 code (BR, MX, PT, AR, CO, US, GB, DE…). App Store apps are looked up in the same country, the report writes prices, channels and copy for it, and sub-topics are measured there too. Omit it to use the country of the phrase's language. The phrase is measured in its own language when the country has it (Spanish in the United States), otherwise in the country's main language, so write it the way people search in that country."New value: +"Country to measure demand in, as an ISO 3166-1 alpha-2 code (BR, MX, PT, AR, CO, US, GB, DE, KZ, RU, BY…). App Store apps are looked up in the same country, the report writes prices, channels and copy for it, and sub-topics are measured there too. Omit it to use the country of the phrase's language. The phrase is measured in its own language when the country has it (Spanish in the United States), otherwise in the country's main language, so write it the way people search in that country."

changedInput schema / properties / country / enum

Previous value: -[
-  "AE",
-  "AL",
-  "AM",
-  "AO",
-  "AR",
-  "AT",
-  "AU",
-  "AZ",
-  "BA",
-  "BD",
-  "BE",
-  "BF",
-  "BG",
-  "BH",
-  "BO",
-  "BR",
-  "CA",
-  "CH",
-  "CI",
-  "CL",
-  "CM",
-  "CO",
-  "CR",
-  "CY",
-  "CZ",
-  "DE",
-  "DK",
-  "DZ",
-  "EC",
-  "EE",
-  "EG",
-  "ES",
-  "FI",
-  "FR",
-  "GB",
-  "GH",
-  "GR",
-  "GT",
-  "HK",
-  "HR",
-  "HU",
-  "ID",
-  "IE",
-  "IL",
-  "IN",
-  "IT",
-  "JO",
-  "JP",
-  "KE",
-  "KH",
-  "KR",
-  "KZ",
-  "LK",
-  "LT",
-  "LV",
-  "MA",
-  "MC",
-  "MD",
-  "MK",
-  "MM",
-  "MT",
-  "MX",
-  "MY",
-  "NG",
-  "NI",
-  "NL",
-  "NO",
-  "NZ",
-  "PA",
-  "PE",
-  "PH",
-  "PK",
-  "PL",
-  "PT",
-  "PY",
-  "RO",
-  "RS",
-  "SA",
-  "SE",
-  "SG",
-  "SI",
-  "SK",
-  "SN",
-  "SV",
-  "TH",
-  "TN",
-  "TR",
-  "TW",
-  "UA",
-  "US",
-  "UY",
-  "VE",
-  "VN",
-  "ZA"
-]New value: +[
+  "AE",
+  "AL",
+  "AM",
+  "AO",
+  "AR",
+  "AT",
+  "AU",
+  "AZ",
+  "BA",
+  "BD",
+  "BE",
+  "BF",
+  "BG",
+  "BH",
+  "BO",
+  "BR",
+  "BY",
+  "CA",
+  "CH",
+  "CI",
+  "CL",
+  "CM",
+  "CO",
+  "CR",
+  "CY",
+  "CZ",
+  "DE",
+  "DK",
+  "DZ",
+  "EC",
+  "EE",
+  "EG",
+  "ES",
+  "FI",
+  "FR",
+  "GB",
+  "GH",
+  "GR",
+  "GT",
+  "HK",
+  "HR",
+  "HU",
+  "ID",
+  "IE",
+  "IL",
+  "IN",
+  "IT",
+  "JO",
+  "JP",
+  "KE",
+  "KH",
+  "KR",
+  "KZ",
+  "LK",
+  "LT",
+  "LV",
+  "MA",
+  "MC",
+  "MD",
+  "MK",
+  "MM",
+  "MT",
+  "MX",
+  "MY",
+  "NG",
+  "NI",
+  "NL",
+  "NO",
+  "NZ",
+  "PA",
+  "PE",
+  "PH",
+  "PK",
+  "PL",
+  "PT",
+  "PY",
+  "RO",
+  "RS",
+  "RU",
+  "SA",
+  "SE",
+  "SG",
+  "SI",
+  "SK",
+  "SN",
+  "SV",
+  "TH",
+  "TN",
+  "TR",
+  "TW",
+  "UA",
+  "US",
+  "UY",
+  "VE",
+  "VN",
+  "ZA"
+]

changedInput schema / properties / language / enum

Previous value: -[
-  "ar",
-  "az",
-  "bg",
-  "bn",
-  "bs",
-  "cs",
-  "da",
-  "de",
-  "el",
-  "en",
-  "es",
-  "et",
-  "fi",
-  "fr",
-  "he",
-  "hi",
-  "hr",
-  "hu",
-  "hy",
-  "id",
-  "it",
-  "ja",
-  "ko",
-  "lt",
-  "lv",
-  "mk",
-  "ms",
-  "nb",
-  "nl",
-  "pl",
-  "pt",
-  "ro",
-  "ru",
-  "sk",
-  "sl",
-  "sq",
-  "sr",
-  "sv",
-  "th",
-  "tl",
-  "tr",
-  "uk",
-  "ur",
-  "vi",
-  "zh-CN",
-  "zh-TW"
-]New value: +[
+  "ar",
+  "az",
+  "be",
+  "bg",
+  "bn",
+  "bs",
+  "cs",
+  "da",
+  "de",
+  "el",
+  "en",
+  "es",
+  "et",
+  "fi",
+  "fr",
+  "he",
+  "hi",
+  "hr",
+  "hu",
+  "hy",
+  "id",
+  "it",
+  "ja",
+  "ko",
+  "lt",
+  "lv",
+  "mk",
+  "ms",
+  "nb",
+  "nl",
+  "pl",
+  "pt",
+  "ro",
+  "ru",
+  "sk",
+  "sl",
+  "sq",
+  "sr",
+  "sv",
+  "th",
+  "tl",
+  "tr",
+  "uk",
+  "ur",
+  "vi",
+  "zh-CN",
+  "zh-TW"
+]

1 tool updateOct 7, 2026

Changedstart_research1 field changed

addedInput schema / properties / language

Added value: +{
+  "description": "Language the demand is measured in, when the guess from the phrase is not enough: French in Canada (CA + fr), Italian in Switzerland (CH + it), Spanish in the United States (US + es). It must be one of the languages of `country`; given without `country` it picks the main country of the language (pt: Brazil, nl: Netherlands). Omit it to use the language of the phrase.",
+  "enum": [
+    "ar",
+    "az",
+    "bg",
+    "bn",
+    "bs",
+    "cs",
+    "da",
+    "de",
+    "el",
+    "en",
+    "es",
+    "et",
+    "fi",
+    "fr",
+    "he",
+    "hi",
+    "hr",
+    "hu",
+    "hy",
+    "id",
+    "it",
+    "ja",
+    "ko",
+    "lt",
+    "lv",
+    "mk",
+    "ms",
+    "nb",
+    "nl",
+    "pl",
+    "pt",
+    "ro",
+    "ru",
+    "sk",
+    "sl",
+    "sq",
+    "sr",
+    "sv",
+    "th",
+    "tl",
+    "tr",
+    "uk",
+    "ur",
+    "vi",
+    "zh-CN",
+    "zh-TW"
+  ],
+  "type": "string"
+}

1 tool updateOct 7, 2026

Changedstart_research1 field changed

addedInput schema / properties / country

Added value: +{
+  "description": "Country to measure demand in, as an ISO 3166-1 alpha-2 code (BR, MX, PT, AR, CO, US, GB, DE…). App Store apps are looked up in the same country, the report writes prices, channels and copy for it, and sub-topics are measured there too. Omit it to use the country of the phrase's language. The phrase is measured in its own language when the country has it (Spanish in the United States), otherwise in the country's main language, so write it the way people search in that country.",
+  "enum": [
+    "AE",
+    "AL",
+    "AM",
+    "AO",
+    "AR",
+    "AT",
+    "AU",
+    "AZ",
+    "BA",
+    "BD",
+    "BE",
+    "BF",
+    "BG",
+    "BH",
+    "BO",
+    "BR",
+    "CA",
+    "CH",
+    "CI",
+    "CL",
+    "CM",
+    "CO",
+    "CR",
+    "CY",
+    "CZ",
+    "DE",
+    "DK",
+    "DZ",
+    "EC",
+    "EE",
+    "EG",
+    "ES",
+    "FI",
+    "FR",
+    "GB",
+    "GH",
+    "GR",
+    "GT",
+    "HK",
+    "HR",
+    "HU",
+    "ID",
+    "IE",
+    "IL",
+    "IN",
+    "IT",
+    "JO",
+    "JP",
+    "KE",
+    "KH",
+    "KR",
+    "KZ",
+    "LK",
+    "LT",
+    "LV",
+    "MA",
+    "MC",
+    "MD",
+    "MK",
+    "MM",
+    "MT",
+    "MX",
+    "MY",
+    "NG",
+    "NI",
+    "NL",
+    "NO",
+    "NZ",
+    "PA",
+    "PE",
+    "PH",
+    "PK",
+    "PL",
+    "PT",
+    "PY",
+    "RO",
+    "RS",
+    "SA",
+    "SE",
+    "SG",
+    "SI",
+    "SK",
+    "SN",
+    "SV",
+    "TH",
+    "TN",
+    "TR",
+    "TW",
+    "UA",
+    "US",
+    "UY",
+    "VE",
+    "VN",
+    "ZA"
+  ],
+  "type": "string"
+}

2 tool updatesSep 29, 2026

Changedlist_research3 fields changed
- changedInput schema / properties / limit / description
```
Previous value: -"How many researches to return, 1-50 (default 10)."New value: +"How many researches to return, from 1 to 50. Default 10."
```
- addedInput schema / properties / limit / maximum
```
Added value: +50
```
- addedInput schema / properties / limit / minimum
```
Added value: +1
```

Changedrun_signal4 fields changed

changedInput schema / properties / id / description

Previous value: -"Id of the completed parent research."New value: +"Id of the completed research the check is added to, as returned by start_research, get_research or list_research."

changedInput schema / properties / kind / description

Previous value: -"Which check to run."New value: +"Which check to add. competitors, dynamics, appstore, wiki, radar, youtube, paid and report need a demand research as the parent; fingerprint a competitors check; reviews an App Store research; insight a demand research or a competitors check."

changedInput schema / properties / locale / description

Previous value: -"For \"insight\" and \"report\": language of the text. Defaults to the language the research was started with, then to the interface language of the account."New value: +"Only for insight and report: language of the text. Defaults to the language the research was started with, then to the language of the account."

changedInput schema / properties / phrase / description

Previous value: -"For \"competitors\": the phrase to check competitors for (one of the parent's candidate phrases). Defaults to the parent phrase."New value: +"Only for competitors: the phrase whose search results are checked, usually one of the candidate phrases of the parent. Defaults to the phrase of the parent. Ignored by the other checks."

10 tool updatesSep 29, 2026
- First observedcompare_research
- First observedfollow_niche
- First observedget_project
- First observedget_report
- First observedget_research
- First observedlist_projects
- First observedlist_research
- First observedrun_signal
- First observedstart_research
- First observedupdate_project

Related MCP Connectors

PreVibe AOAuth
io.previbe
Validate your SaaS idea with market research before you build it.
Marketing Product Management Workplace & Productivity
171
IdeaKillerOAuth
app.ideakiller
Validate a startup idea with live web research: GO, PIVOT or NO_GO, with evidence and a first test.
1
DDMarketer A
io.github.CodePhantom-1
Find and validate SaaS ideas from real user complaints, scored for commercial intent.
Marketing
41
fluenta
io.github.Fluenta-Team
Score business ideas on six live market signals. Launch Readiness Score (LRS) for AI agents.
Product Management Research & Data Finance
1

Related MCP Servers

prelaunch-mcp
Research & Data AI & Machine Learning
Heman10x-NGU
A
license
A
quality
D
maintenance
Analyzes startup ideas against 6 sources (GitHub, HN, npm, PyPI, Google, Reddit) with LLM-powered intent parsing to assess competition, demand, and gaps.
Updated 8 months ago (2026-03-05 20:16 UTC)
1
MIT
DDMarketer MCP Server
Product Management Research & Data Search
CodePhantom-1
A
license
Not graded
quality
B
maintenance
Enables agents to discover and validate SaaS opportunities mined from real user complaints across eight public sources, scoring ideas for commercial intent. Also allows fetching detailed dossiers on specific gaps with source complaints, MVP scope, pricing, competitors, and risks.
Updated 2 months ago (2026-08-31 15:43 UTC)
MIT
idea-reality-mcp
Developer Tools Product Management Search
mnemox-ai
A
license
A
quality
D
maintenance
Pre-build reality check for AI coding agents. Scans GitHub, Hacker News, npm, PyPI & Product Hunt in parallel — returns a 0-100 reality signal with real competitor data.
Updated a month ago (2026-09-18 08:23 UTC)
1
80 PyPI
825
MIT
NUVC MCP Serverofficial
Finance Research & Data
repyh-com
A
license
Not graded
quality
D
maintenance
Provides VC-grade startup intelligence, allowing founders to validate ideas and VCs to screen deals using tools like scoring, investor matching, and financial analysis.
Updated 5 months ago (2026-05-23 23:58 UTC)
8 npm
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

NUVC MCP Serverofficial

Glama MCP Gateway

Resources