Skip to main content
Glama
deenesjakoruzh
jain-eshan

Google Trends MCP

by jain-eshan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

gutcheck

Check your gut against the internet before you commit.

gutcheck is a market researcher for Claude Code. Give it an idea you want to build, a problem you keep hitting, a topic you're curious about, or a decision you're stuck on. It works out what would actually answer the question, designs a study to match, pulls live evidence from Google Trends, Reddit, Google News, Wikipedia, Hacker News, GitHub, the App Store, YouTube and the web, then tells you what it thinks and why.

It scales with the stakes. A hunch gets ten minutes and a straight answer. A case competition, business plan, market landscape, or dissertation gets a research plan first, run in phases, in the shape that audience expects.

/gutcheck is there demand for a simpler meal-planning app for busy parents?
/gutcheck freelancers keep getting paid late, how common is this and what actually works?
/gutcheck is pickleball still growing or has it peaked?
/gutcheck should I learn Rust or Go in 2026?

Free and open source. Works with no API keys. Everything runs on your machine.

Install (30 seconds)

Open Claude Code and paste this. Claude does the rest.

Install gutcheck: run git clone --single-branch --depth 1 https://github.com/jain-eshan/gutcheck.git ~/.claude/skills/gutcheck && ~/.claude/skills/gutcheck/setup, then tell me to restart Claude Code and run /gutcheck setup.

Or run it yourself in a terminal:

git clone --single-branch --depth 1 https://github.com/jain-eshan/gutcheck.git ~/.claude/skills/gutcheck && ~/.claude/skills/gutcheck/setup

The setup script installs uv if you don't have it, installs the Python dependencies, registers the data tools with Claude Code, and creates a private settings file at ~/.config/gutcheck/.env. Restart Claude Code once afterwards.

Requirements: macOS or Linux, Claude Code, and git. Windows hasn't been tested yet; WSL is the likely route.

Related MCP server: Google Trends MCP Server

Setup: /gutcheck setup

Run this once after installing. It's a conversation, not a config file hunt:

  1. It asks what's actually on your mind first, and checks every data source in the background while you answer.

  2. It asks the little it can't infer (which country, what you do), so later runs know whether to check India or the US and which communities to search.

  3. It offers an optional key only when one would help your question, described by what it gets you rather than by its name, and saves it for you.

  4. It finishes by researching the thing you named, for real, so setup ends with an answer instead of instructions.

You can skip the keys. Seven sources work with zero setup, and step 4 works immediately, even before you restart Claude Code.

What you get

A point of view, not a pile of search results. Every run leads with what gutcheck thinks is true, backs it with the evidence, argues the other side, and ends with something you can do this week. Here's a real one:

GUTCHECK REPORT
════════════════════════════════════════════════════
Question:        freelancers keep getting paid late by clients - how common is this and what actually works?
Type:            PROBLEM
Checking:        Late payment is a widespread freelancer problem with no settled fix.
Verdict:         MODERATE_SIGNAL
Confidence:      MEDIUM (6 sources, 5-year window, worldwide)

THE READ
It's not you, and it's not rare: across the surveys, most freelancers get paid
late at least sometimes, and roughly a third of all invoices land after the due
date. But the second half of your question has an uncomfortable answer. The fixes
are known and boring, and they work: a deposit up front, a late fee written into
the contract, an invoice sent the day the work ends, and automatic reminders after.
Almost nobody is short of tools here, because every invoicing app already sends
reminders. What people are short of is the nerve to enforce terms with a client
they're afraid of losing. The threads aren't asking how to chase an invoice; they're
asking whether they're allowed to. That's a confidence problem wearing a process
problem's clothes, and it's why the pain persists even though the playbook is settled.

WHAT'S GOING ON
- What you're up against today is a polite reminder email and hoping. That's the
  status quo, and it mostly works slowly: most late invoices arrive within two
  weeks, so this reads as a cash-flow and dignity problem, not a bad-debt one.
- Desire, not demand. Search interest for the problem is climbing, but searches
  for tools that solve it sit near zero. People are looking for reassurance and
  scripts, not software.
- The sources disagree in a useful way: news coverage is about freelancer finance
  in general, while the actual complaints are about specific relationships with
  bigger clients. The power imbalance is the real subject.
- The sharpest thing anyone said: "these bigger companies are acting like Net 30
  means Net 60." Nobody in those threads is confused about what to do. They're
  weighing whether enforcing it costs them the account.

THE CASE AGAINST
The strongest counter is that this was checked worldwide and in English, and late
payment is heavily shaped by local law: the EU and UK have statutory interest rules
that change what "what works" even means. A second is that the survey numbers all
come from companies selling invoicing or payroll products, which have an interest in
the problem looking big. Checking one country properly, with its own rules, would
sharpen this a lot.

What would change this:
- Evidence that deposits and late fees get refused in practice would move this to
  STRONG_SIGNAL for "no settled fix", since the known playbook would then not work.
- A survey showing most late invoices go unpaid entirely, rather than arriving late,
  would change this from a cash-flow problem to a much more serious one.

Next steps:
- Put a 50% deposit and a late-fee line in your next two contracts and see whether
  either client actually pushes back. Most don't, and that's the fastest way to learn it.
- Check whether your current invoicing tool already sends automatic reminders before
  you pay for anything new. It probably does.
- Ask in r/freelance what finally got someone's worst payer to pay on time, and count
  how many answers are about process versus about firing the client.

Caveats:
- "late payment" on Google Trends also covers loans and credit cards, so part of that
  rise has nothing to do with freelancing.
- All survey figures come from vendors selling invoicing or payroll tools.
- Reddit without an API key returns posts without upvote counts, so popularity is unknown.
- Wikipedia had no usable article here (under 25 views a month), so it was dropped.

── Evidence ──
Google Trends, 5 years, worldwide: "late payment" rose from ~26 (2021) to a 55-86
range through 2026. "unpaid invoice" and "invoice reminder" stayed at 1-5 throughout.

Reddit, r/smallbusiness + r/graphic_design, 2026: "Do you guys actually enforce late
fees on Net 30 invoices or is it an empty threat?", "I'm constantly chasing money
I've already earned."

App Store, US: Invoice Simple (122k ratings), Invoice Fly (105k), Invoice2go (56k),
all updated within the month. Standalone late-payment chasers: 0 ratings.

[surveys, news and advice blocks trimmed for this README]

Sources used:    interest_over_time, related_queries, reddit_signal, news_coverage, app_store_apps, wikipedia_pageviews, web search
════════════════════════════════════════════════════
Bottom line: "Most freelancers get paid late, the fixes are known and boring (deposit,
late fee, instant invoice, auto-reminders), and the real blocker is enforcing terms
with clients you're afraid to lose."

The raw numbers sit at the bottom on purpose, so you can check the work without wading through it first. After the report, gutcheck asks you something specific about what it found. Say "save this" and it writes the report to ~/gutcheck-reports/.

How it works

It designs the study before running it. It works out what decision you're making, what would change your mind, and who the output is for, then picks from nine study types and writes a short plan: the research questions, what evidence would answer each, what's out of scope, and what only you can find out (nobody's public data can replace ten customer conversations, and it will say so).

Study

What you get

Quick check

The default. One claim, ten minutes, a straight answer.

Opportunity validation

Demand, incumbents, the narrow group with the problem worst, what would kill it

Case competition

Industry structure, players, what's changing, customer evidence, recommendation, and the rebuttals a jury will throw

Business plan / investment memo

Bottom-up market size with the arithmetic shown, competition, go-to-market, ranked assumptions

Market landscape

Players grouped by approach, pricing picture, underserved segments

Problem diagnosis

How common, in whose words, what actually works

Decision analysis

The axis that really decides it, options compared on one scale

Deep study

Research questions, method, findings, limitations, references

Trend watch

Five-year shape, what's rising underneath, fad or trend, what to watch

For a small question it skips the ceremony entirely and just answers. For a big one it shows the plan, asks what to cut, then runs it in phases and tells you what changed after each.

How it thinks

  • It forms a view. The analysis comes from crossing sources, which no single tool can do: flat search plus a crowded App Store means a settled market; loud Reddit plus flat search means an intense problem for a small group; busy builders plus silent users means a solution chasing a problem.

  • Desire versus demand. Saying you want something is not downloading, paying, or switching. gutcheck says which one the evidence actually shows.

  • It names the status quo. Every idea competes with a spreadsheet, an incumbent, or people deciding to live with it. "Nothing" is the hardest competitor there is.

  • Four kinds of question. An idea (is there room), a problem (is it just me, what works), a topic (growing or fading), a decision (which one, and on what axis). Each gathers different evidence.

  • One claim, one verdict. Your question becomes a single testable sentence, rated STRONG_SIGNAL, MODERATE_SIGNAL, WEAK_SIGNAL, MIXED_SIGNAL or INSUFFICIENT_DATA. "Not enough data" is an allowed answer, and it will say what would settle it.

  • It argues against itself. Every report includes the strongest case that its own read is wrong.

  • Receipts, never invented numbers. Every figure traces to a tool result or a cited page.

  • It remembers. What you check is saved locally, so a similar question later opens with what you found last time and what moved.

  • --deep pulls in more sources (regional breakdowns, GitHub, App Store, YouTube, Product Hunt launches, review sites) when the decision is expensive.

Sources

Source

What it tells you

Key needed?

Google Trends

Is search interest rising or falling, what related searches are breaking out, where

No

Reddit

What people actually say, ask, and complain about, in their own words

No (1 search a minute). Optional key removes the limit

Google News

Is the press covering it, and what angle it takes

No

Wikipedia pageviews

Reading interest, a check on search hype

No

Hacker News + GitHub

Are builders shipping in this space

No. Optional token raises GitHub's limit

App Store

Who already serves this need, and how many people rate them

No

Web search

Competitors, surveys, forum threads, Product Hunt launches

No (built into Claude Code)

YouTube

How much people watch content about it

Free key, about 3 minutes

OpenCorporates

Is a named company officially registered, and since when

Free account

Using the data tools outside Claude Code

The /gutcheck playbook is a Claude Code skill, but the data tools are a standard MCP server that any MCP client can use (Cursor, Codex, Claude Desktop, and others). After cloning and running setup, add this to your client's MCP config:

{
  "mcpServers": {
    "gutcheck": {
      "command": "/Users/YOU/.local/bin/uv",
      "args": ["run", "--directory", "/Users/YOU/.claude/skills/gutcheck", "server.py"]
    }
  }
}

Use the full path to uv (run which uv to find it), since desktop apps often can't see your terminal's PATH. You'll get the 11 tools. Ask your assistant to use them, or point it at SKILL.md for the full method.

Update and uninstall

gutcheck checks GitHub at most once a day when you run it. If there's something new it says so in one line and offers to update after answering your question, rather than interrupting it:

(gutcheck is 3 commits behind: "sharper verdicts on thin B2B evidence". Want me to update after this?)

Say yes and it runs the pull for you, then tells you what changed. Or update whenever you like with /gutcheck upgrade. If your copy has local edits, it won't touch them; it tells you instead.

Uninstall:

claude mcp remove gutcheck --scope user && rm -rf ~/.claude/skills/gutcheck ~/.config/gutcheck

Privacy

gutcheck has no server, account, or analytics. Your questions go only to the sources listed above, straight from your machine. API keys stay in ~/.config/gutcheck/.env (readable only by you). Your history stays in ~/.config/gutcheck/history.jsonl.

Known limits

  • Google Trends has no official API. gutcheck uses pytrends, which reads the public site. If you run many checks back to back, Google may block you for a few minutes. The report marks that source as unavailable and carries on.

  • Keyless Reddit allows one search a minute. gutcheck waits it out, so a report can take about a minute. A Reddit API key removes the limit, but Reddit reviews new API apps by hand, which can take days.

  • Trends numbers are relative (0-100), not search counts. The report treats them that way.

  • OpenCorporates covers registration facts only, never funding or revenue. No free source for that exists.

How it's built

SKILL.md                  router, voice, and what to do before researching
design.md                 scope the job, pick the study, write the plan
research.md               run it: gather, form a view, write the report
setup.md                  the /gutcheck setup conversation
references/
  study-types.md          nine study archetypes, their questions and output shapes
  research-craft.md       desire vs demand, the status quo, triangulation, source tilt
  reading-signals.md      what each source's numbers mean, and the traps
  playbooks.md            how to aim an idea, problem, topic, or decision question
server.py                 MCP server: 11 tools that fetch raw data, no interpretation
setup                     installer (uv, dependencies, MCP registration, settings file)
tests/                    contract tests (mocked or recorded, no network)
tests/eval/               report-structure checks plus evals that run through `claude -p`

The tools also run from a terminal, which is how setup can research something in the session you installed it in:

cd ~/.claude/skills/gutcheck && uv run server.py call reddit_signal '{"query":"meal prep app"}'
cd ~/.claude/skills/gutcheck && uv run server.py doctor   # health-check every source

The split is deliberate. The server only fetches data. Every judgment lives in the markdown, in plain English, so you can read exactly how a verdict gets decided and change it. If you think a verdict was wrong, the fix is usually one paragraph in references/research-craft.md.

Run the tests:

uv sync --group dev && uv run pytest

Contributing

Issues and PRs are welcome, especially new keyless data sources, sharper interpretation rules in the markdown, and reports where gutcheck got the verdict wrong (paste the report and say why).

Working on gutcheck itself

Keep two copies. The one in ~/.claude/skills/gutcheck is what Claude Code runs; leave it alone and let it update itself. Work somewhere else:

git clone https://github.com/jain-eshan/gutcheck.git ~/dev/gutcheck
cd ~/dev/gutcheck && uv sync --group dev

Edit there, run uv run pytest, push, then let the installed copy pick it up the next time you run /gutcheck (or force it with /gutcheck upgrade). Editing the installed copy directly works but blocks updates, since a pull would overwrite your changes — the update check notices and refuses rather than clobbering.

Most changes are markdown, not Python. The judgment lives in SKILL.md (voice, routing), design.md (how a study gets planned), research.md (how a report gets written), and references/ (what it knows about reading evidence). A verdict that felt wrong is usually a paragraph in references/research-craft.md, not a code change.

To try a change before pushing, point Claude Code at your dev copy for one session:

claude mcp add --scope local gutcheck-dev -- uv run --directory ~/dev/gutcheck server.py

gutcheck started as market-signal-mcp, a Google Trends wrapper for startup-idea checks. The install flow borrows from Garry Tan's gstack.

License

MIT. See LICENSE.

Available Tools

11 tools
app_store_appsA

Existing iPhone/iPad apps matching a query, from Apple's public iTunes Search API - who already serves this need, and how many people rate them (rating count is a rough proxy for user base). No setup needed.

Args: query: search terms, e.g. "meal planner" or "invoice". country: ISO country code for the store, e.g. "US" (default), "IN", "GB". limit: max apps, capped at 50.

Returns: A list in App Store relevance order, each with "name", "developer", "rating", "rating_count", "price", "genre", "released", "last_updated", "url".

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
countryNoUS

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral disclosure burden and does so well: it names the public API source, states no setup is needed, explains that results are in App Store relevance order, and caps the limit at 50. It does not mention rate limits, data freshness, or error behavior, but for a read-only search tool the disclosed behavior is reasonably complete.

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 organized with clear Args and Returns sections and keeps each parameter explanation short. The opening sentence is slightly awkward and could be tightened, but there is no redundant filler and the most important details are front-loaded.

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 simple three-parameter search tool with no output schema and no annotations, the description is quite complete: it documents all parameters, explains the return fields, and notes ordering and the rating-count proxy. It could add edge-case behavior like empty results or country-specific quirks, but nothing essential is missing for calling it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description fully compensates by documenting every parameter: query with examples, country with ISO code format and default, and limit with its 50 cap. This adds meaningful semantics beyond the raw JSON schema types and defaults.

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 identifies the tool as returning existing iPhone/iPad apps matching a query from Apple's public iTunes Search API. It conveys the search behavior and domain, though it lacks a crisp verb like 'search' and does not explicitly differentiate from sibling tools. The odd phrasing 'who already serves this need' slightly weakens clarity but does not obscure the purpose.

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 explains the use case: finding apps that already serve a need and using rating count as a proxy for user base, plus 'No setup needed' signals ease of use. It does not provide explicit when-not-to-use guidance or name alternative tools, but the sibling list contains no direct app-store alternative, so the implied context is sufficient.

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

builder_activityA

Are people actually building and shipping in this space? Hacker News stories (launches, Show HNs, debates) plus GitHub repositories - a builder signal, as opposed to search interest or community chatter. Works with no setup; a GITHUB_TOKEN saved via /gutcheck setup raises GitHub's limit from 10 to 30 searches a minute.

For Product Hunt launches, use web search restricted to producthunt.com instead - Product Hunt's API has no search endpoint.

Args: query: search terms, e.g. a product category ("habit tracker") or problem.

Returns: {"hn": {"total": int, "stories": [...]}, "github": {"total": int, "repos": [...]}}. Each story: title, points, num_comments, url, created_at. Each repo (top 10 by stars): name, description, stars, last_push, url.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It openly describes the data sources, optional GITHUB_TOKEN requirement, rate-limit implications, and return structure including that GitHub results are the top 10 by stars. It does not mention edge cases or failure modes, but it is substantially transparent for a read-style search tool.

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?

The description is well-structured with a clear purpose statement, setup note, alternative routing, and an Args/Returns breakdown. Every sentence contributes useful information, and the return format is compactly documented. It earns its length.

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?

Given a single parameter, no annotations, and no output schema, the description is remarkably complete. It explains the query semantics, the result shape, per-item fields, the GitHub top-10 behavior, rate limits, and an important alternative for Product Hunt. An agent has enough information to invoke the tool correctly and interpret its response.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully explain the single query parameter. It does so clearly: 'search terms, e.g. a product category ("habit tracker") or problem.' This adds meaningful semantic guidance beyond the bare schema's type and required flag.

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 identifies the tool's function: combining Hacker News stories and GitHub repositories into a 'builder signal'. It distinguishes itself from sibling tools by contrasting with 'search interest or community chatter' and mentions specific sources, making it easy for an agent to disambiguate from tools like related_topics or interest_over_time.

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?

The description gives useful context for when to use the tool: when there is interest in real building/shipping activity rather than search interest or chatter. It also provides an explicit exclusion and alternative for Product Hunt launches, directing users to web search instead. It does not exhaustively enumerate when not to use it versus every sibling, but the guidance is clear.

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

company_registrationA

Company registration lookup via OpenCorporates - registration facts only (incorporation date, status, company number). Does NOT cover funding, valuation, or traction data - no free API exists for that (see README for why).

Requires a free OpenCorporates API token: as of 2026 OpenCorporates requires a token on every request, even on the free tier (roughly 50 requests/day, 200/month). Register at https://opencorporates.com/api_accounts/new and save it as OPENCORPORATES_API_TOKEN via /gutcheck setup.

Args: name: company name to search for. jurisdiction: optional OpenCorporates jurisdiction code (e.g. "in", "us_de") to narrow results.

Returns: A list of up to 5 matches, each containing "company_name", "jurisdiction_code", "incorporation_date", "company_number", "current_status", "opencorporates_url". Empty list if no matches. A setup-instructions string if OPENCORPORATES_API_TOKEN is unset, or OpenCorporates' own rejection message if the token is invalid/expired.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
jurisdictionNo

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden, and it succeeds: it discloses token requirements, rate-limit context (~50/day, 200/month), behavior when the token is unset or invalid, return format, match limit, and empty-list behavior. This gives the agent a reliable model of tool behavior.

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?

The description is longer than average but every sentence serves a purpose: scope, exclusions, auth setup, arguments, and return contract. It is front-loaded with the core purpose and structured so an agent can quickly extract what it needs.

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?

Despite having no output schema, the description specifies the exact returned fields, the cap of 5 matches, the empty-list case, and error/setup responses. For a lookup tool with only two parameters and one sibling-group mismatch, nothing material is missing for correct invocation.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must define the parameters, and it does: it explains that name is the company name to search, and jurisdiction is optional with concrete examples like 'in' and 'us_de'. This adds real meaning beyond the raw schema.

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 states a specific verb and resource ('Company registration lookup via OpenCorporates') and immediately scopes it to registration facts only. It also explicitly distinguishes itself from funding/valuation/traction data, so an agent can tell exactly what this tool is and is not for.

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 explains when to use it (registration lookup) and when not to use it (funding, valuation, or traction data), noting that no free API exists for those. It also gives setup prerequisites for the required token, which is essential operational guidance.

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

interest_by_regionA

Search interest for a keyword broken down by state/region within a country, or by country when geo is "" (worldwide).

Args: keyword: a single search term. timeframe: pytrends timeframe string, e.g. "today 12-m". geo: ISO country code (e.g. "US", "IN"), or "" for worldwide (default). response_format: "concise" (default) returns only the top 10 regions by interest, rounded to whole numbers. "full" returns every region, unrounded.

Returns: A list of records, one per state/region within the specified geo, each containing: - "geoName": the state/region name (e.g. "California"), or the country name when worldwide - A column with the keyword name as the key: relative search interest (0-100 scale) for that region. Higher values indicate higher relative interest in that region compared to others in the same country. This is Google Trends' standard region-relative scale.

ParametersJSON Schema
NameRequiredDescriptionDefault
geoNo
keywordYes
timeframeNotoday 12-m
response_formatNoconcise

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output format, the scale (0-100) and its meaning, and the difference between 'concise' and 'full' response formats. It also notes the relative nature of interest scores. It does not mention potential limitations (e.g., rate limits, data availability), but the core behavior is transparent.

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 well-organized with a clear opening purpose, followed by args and returns. It is detailed but not verbose; every sentence adds value. The structure is logical, though the args/returns section is somewhat lengthy, but that is justified given the need to explain the output format.

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?

The tool has 4 parameters, no output schema, and no annotations. The description covers all parameters, explains the output structure precisely, and gives examples. It is complete enough for an agent to call correctly without further information. No critical information is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must explain all parameters. It does so thoroughly: keyword (single search term), timeframe (with example 'today 12-m'), geo (ISO codes, '' for worldwide), and response_format (with definitions of 'concise' and 'full'). It adds meaning well beyond the schema's bare types.

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 purpose: searching interest for a keyword broken down by state/region within a country, or by country when geo is empty. This is a specific verb+resource combination that distinguishes it from sibling tools like interest_over_time (time series) and related_topics (related queries).

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?

The description clearly indicates when to use this tool: when you need regional breakdown of interest within a country, or by country worldwide. It does not explicitly state when not to use it, but the context is clear and the parameter descriptions (geo, timeframe) provide implicit guidance. The return format explanation further clarifies usage.

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

interest_over_timeA

Relative Google search interest (0-100) over time for up to 5 keywords, compared side by side.

Args: keywords: 1-5 search terms to compare. Only the first 5 are used; additional keywords are silently dropped. timeframe: pytrends timeframe string, e.g. "today 12-m", "today 5-y", "now 7-d", or "YYYY-MM-DD YYYY-MM-DD". geo: ISO country code (e.g. "US", "IN", "GB"), or "" for worldwide (default). response_format: "concise" (default) covers the whole requested timeframe, thinned to about 26 evenly spaced points (first and last always kept) and rounded to whole numbers, so the shape of the window is intact at a low token cost. "full" returns every point unrounded - use it when you need week-by-week detail.

Returns: A list of records, one per date, each containing: - "date": ISO date string - "isPartial": present and true only when the period is incomplete (most recent point) - omitted when false in "concise" mode, since false is the common case. - One numeric key per keyword (0-100 relative interest value)

ParametersJSON Schema
NameRequiredDescriptionDefault
geoNo
keywordsYes
timeframeNotoday 12-m
response_formatNoconcise

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 full behavioral disclosure. It reveals key quirks: extra keywords beyond 5 are silently dropped, 'concise' mode thins to ~26 evenly spaced points with rounding, and 'isPartial' appears only for incomplete periods. This is unusually transparent and useful for an agent.

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?

The description is long but every section earns its place: purpose, parameter semantics, and return format. It is front-loaded with the core purpose and structured into Args/Returns, making it easy for an agent to scan.

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 return-structure explanation is essential and provided in detail: date, isPartial semantics, and per-keyword interest values. All four parameters are covered, and the behavioral nuances are disclosed. Nothing critical is missing for an agent to invoke the tool correctly.

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

Parameters5/5

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

Schema coverage is 0%, so the description must document all parameters. It does so comprehensively: keywords with the 1-5 limit and drop behavior, timeframe with pytrends string examples, geo with country-code examples and default, and response_format with both modes fully explained.

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 states a specific verb and resource: it retrieves relative Google search interest (0-100) over time for up to 5 keywords. It also communicates the comparative, time-series nature that distinguishes it from siblings like interest_by_region or related_topics.

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?

The description clearly conveys the tool's context: search-interest trends over time, compared across keywords, with geographic filtering. It also gives specific guidance on when to use 'concise' vs 'full' response formats. It does not explicitly name alternatives or exclusion conditions, but the intended use is strongly implied.

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

news_coverageA

Recent news coverage from Google News - is the press writing about this, and what angle are they taking? Useful for spotting funding rounds, regulation, launches, and whether a topic is getting more or less attention. No setup needed.

Args: query: search terms. geo: ISO country code for the news edition, e.g. "US" (default), "IN", "GB". recent: how far back - "7d", "1m", "1y" (default). Uses Google News' own when: filter. limit: max headlines to return (Google returns up to ~100; "total" counts all of them).

Returns: {"total": int, "last_30_days": int, "headlines": [{"title", "source", "published", "url"}]}, newest first. "total" and "last_30_days" are counts within Google's capped result set, so treat them as a rough attention gauge, not an exact article count.

ParametersJSON Schema
NameRequiredDescriptionDefault
geoNoUS
limitNo
queryYes
recentNo1y

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries full responsibility for behavioral disclosure, and it delivers: it explains the data source (Google News), the capped result set, how 'total' and 'last_30_days' should be interpreted as rough gauges rather than exact counts, the newest-first ordering, and the use of Google News' `when:` filter. This is strong transparency beyond the bare schema.

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 well-structured with a clear lead sentence, an Args section, and a Returns section. It is somewhat longer than strictly necessary, but the extra details (cap caveat, newest first, rough attention gauge) are genuinely useful and not redundant filler.

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?

Even with no output schema, the description fully specifies the return structure, field semantics, and important caveats about counts. It also covers setup expectations ('No setup needed') and the tool's intended analytical uses, so an agent has enough context to select and invoke it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly: query is defined as search terms, geo as an ISO country code with examples, recent as a time range with the underlying filter explained, and limit as a max-headline count with a note about Google's ~100 cap. It adds meaning and usage guidance that the schema alone does not provide.

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 opens with a specific verb and resource: 'Recent news coverage from Google News' and immediately frames the purpose ('is the press writing about this, and what angle are they taking?'). The use cases (funding rounds, regulation, launches, attention trends) make it clear what this tool does and how it differs from the sibling tools like related_topics or interest_over_time.

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?

The description gives clear context for when to use the tool ('Usable for spotting funding rounds, regulation, launches, and whether a topic is getting more or less attention') and notes 'No setup needed.' It does not explicitly name alternatives or say when not to use it, but the stated use cases are sufficient orientation.

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

reddit_signalA

What real people on Reddit are saying, asking, or complaining about - qualitative community signal, as opposed to Trends/Wikipedia's passive search/reading numbers.

Works with no setup via Reddit's public search feed (which returns post text but not scores, and rate-limits after a burst of requests). If REDDIT_CLIENT_ID and REDDIT_CLIENT_SECRET are saved via /gutcheck setup, uses the official API instead, which adds score and comment counts.

Args: query: search terms. subreddits: optional subreddit names to restrict the search to (e.g. ["startups", "SaaS"]). limit: max results, capped at 100. time_filter: "week", "month", "year" (default), or "all".

Keep the query short (2-4 words) and pass subreddits when obvious communities exist. Reddit's keyless search matches loosely on long questions, so results that share no meaningful word with the query are dropped and the rest are ranked by how many query words they match.

Returns: A list of records with "title", "subreddit", "snippet" (first ~300 chars of the post body), "url", "created". "score" and "num_comments" are included only in API mode.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
subredditsNo
time_filterNoyear

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 thoroughly: it discloses rate limits, mode differences (public feed omits scores; API adds score and comment counts), setup prerequisites via /gutcheck setup, and the loose-matching/ranking behavior of the keyless search. This is strong behavioral disclosure beyond typical one-line definitions.

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?

Despite length, the description is front-loaded (purpose first) and every section earns its place: signal type, mode setup, args, querying heuristics, and return format. The structured Args/Returns layout makes the extra behavioral context navigable rather than bloated.

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?

Because there is no output schema, the description supplies the return record fields and mode-dependent omission of score/num_comments, which is essential. It also covers prerequisites, rate limiting, and parameter behaviors, leaving little an agent needs to infer before calling.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it defines all four parameters: query as search terms, subreddits as optional restriction with examples, limit as max results capped at 100, and time_filter with valid values and default. The only schema-default it omits is limit's 25, which the schema itself exposes.

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 opening sentence identifies the resource (Reddit), the kind of data (qualitative posts by real people), and explicitly contrasts it with 'Trends/Wikipedia's passive search/reading numbers,' making sibling differentiation obvious. The query argument and return record names make it clear this is a Reddit post-search/signal tool.

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 positions the tool as qualitative community signal versus Trends/Wikipedia numeric data and gives concrete query/subreddit guidance ('Keep the query short (2-4 words) and pass subreddits when obvious communities exist'). It clearly explains when API mode will be used versus the keyless feed, but it never states an explicit 'use when / do not use when' rule, so no hard exclusion is given.

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

wikipedia_pageviewsA

Monthly Wikipedia pageview counts for an article - a free, no-auth reference/reading interest signal that complements Google Trends' search-interest signal. The two diverging (e.g. a term trending in search but flat on Wikipedia) can itself be a signal worth flagging.

Args: article: an English Wikipedia article title, e.g. "Artificial_intelligence" or "Machine learning" (spaces are handled automatically). timeframe: how far back to request, as a simple duration - "P1Y" (1 year, default), "P6M" (6 months), "P90D" (90 days). Only whole Y/M/D forms are supported. response_format: "concise" (default) returns only the most recent 12 months. "full" returns the entire requested timeframe.

Returns: A list of records, one per month, each containing: - "month": "YYYY-MM" - "views": total pageviews that month (all access methods, human traffic only - bot traffic is excluded by Wikimedia's "user" agent filter)

ParametersJSON Schema
NameRequiredDescriptionDefault
articleYes
timeframeNoP1Y
response_formatNoconcise

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses free/no-auth access, monthly granularity, human-only traffic (bot traffic excluded by Wikimedia's 'user' agent filter), all access methods, and the behavior of response_format. It also notes automatic space handling and supported duration forms.

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?

The description is well-structured: purpose first, then usage context, then parameter details, then return format. Every sentence contributes useful information without filler or redundancy, and the sections are easy to parse.

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?

Given no output schema and no annotations, the description is operationally complete. It specifies all inputs with defaults, explains the output record structure, and documents behavioral caveats such as bot filtering and response format differences. An agent can invoke it correctly without additional documentation.

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

Parameters5/5

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

Schema description coverage is 0%, but the description fully compensates. For article it gives title format and space-handling behavior; for timeframe it lists duration examples, the default, and supported forms; for response_format it explains 'concise' vs 'full' and the default. This adds significant meaning beyond the bare schema.

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 opens with a specific verb and resource: 'Monthly Wikipedia pageview counts for an article.' It further distinguishes itself from Google Trends' search-interest signal by framing it as a free, no-auth reference/reading-interest signal, making its purpose and differentiation clear.

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 positions the tool as complementary to Google Trends and explains that divergence between the two signals can be worth flagging, giving the agent context on when to use it. It does not explicitly name sibling tools or state when not to use it, but the guidance is sufficiently clear.

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

youtube_videosA

YouTube videos matching a query, with view and comment counts - shows how much people watch content about a topic (tutorials, reviews, "I tried X" videos), which is often a stronger consumer-interest signal than search volume.

Requires a free YOUTUBE_API_KEY (Google Cloud, YouTube Data API v3), saved via /gutcheck setup. Each call uses about 101 of the free 10,000 daily quota units.

Args: query: search terms. limit: max videos, capped at 25. published_after_days: only videos from the last N days; omit for any time.

Returns: A list in YouTube relevance order, each with "title", "channel", "published", "views", "likes", "comments", "url". A setup-instructions string if no key is saved.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
published_after_daysNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/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 well: it discloses the required YOUTUBE_API_KEY, quota consumption of about 101 units per call, and the fallback behavior of returning setup instructions if no key is saved. It does not cover API error cases, but the main behavioral traits are transparent.

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 well organized into purpose, preconditions, arguments, and return value, with the main purpose front-loaded. There is slight redundancy in repeating view/comment counts in both the opening and the Returns section, but overall it is compact and scannable.

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 3-parameter tool with an output schema, the description is complete: it covers setup, quota, parameter semantics, return shape, and the no-key fallback. An agent has enough context to select and invoke the tool correctly without needing additional documentation.

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

Parameters5/5

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

Schema description coverage is 0%, so the Args section is essential and fully compensates. It defines query as search terms, explains limit is capped at 25, and clarifies published_after_days filters to the last N days or can be omitted for any time period. This adds real meaning beyond the bare schema types and defaults.

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 opens with a specific verb and resource: 'YouTube videos matching a query, with view and comment counts.' It also clarifies the tool's role as a consumer-interest signal compared to search volume, making it distinct from unrelated siblings like reddit_signal, news_coverage, and related_topics.

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 provides clear use context: to measure how much people watch content about a topic, with examples like tutorials and reviews, and notes this is often stronger than search volume. It includes the important API-key prerequisite, but does not explicitly say when to prefer an alternative sibling or when not to use this tool.

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. 12 tool updatesv1.0.0
    • Addedapp_store_apps
    • Addedbuilder_activity
    • Addedcompany_registration
    • Changedinterest_by_region2 fields changed
      • changedInput schema / properties / geo / default
        Previous value: -"IN"New value: +""
      • addedInput schema / properties / response_format
        Added value: +{
+  "default": "concise",
+  "title": "Response Format",
+  "type": "string"
+}
    • Changedinterest_over_time2 fields changed
      • changedInput schema / properties / geo / default
        Previous value: -"IN"New value: +""
      • addedInput schema / properties / response_format
        Added value: +{
+  "default": "concise",
+  "title": "Response Format",
+  "type": "string"
+}
    • Addednews_coverage
    • Addedreddit_signal
    • Changedrelated_queries2 fields changed
      • changedInput schema / properties / geo / default
        Previous value: -"IN"New value: +""
      • addedInput schema / properties / response_format
        Added value: +{
+  "default": "concise",
+  "title": "Response Format",
+  "type": "string"
+}
    • Changedrelated_topics2 fields changed
      • changedInput schema / properties / geo / default
        Previous value: -"IN"New value: +""
      • addedInput schema / properties / response_format
        Added value: +{
+  "default": "concise",
+  "title": "Response Format",
+  "type": "string"
+}
    • Removedtrending_now
    • Addedwikipedia_pageviews
    • Addedyoutube_videos
  2. 5 tool updatesv0.1.0
    • First observedinterest_by_region
    • First observedinterest_over_time
    • First observedrelated_queries
    • First observedrelated_topics
    • First observedtrending_now
Deploy Server
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

TDQS

A4.5/5.0

Scored across 11 tools

Disambiguation5/5

Each tool targets a distinct data source or dimension: Google Trends topics, queries, time series, regional breakdown, plus Wikipedia, OpenCorporates, Reddit, HN/GitHub, Google News, App Store, and YouTube. Even within Trends, related_topics vs related_queries are clearly separated by content type. No ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case noun phrase pattern (e.g., interest_over_time, reddit_signal, builder_activity). No mixing of conventions or verb styles, making the set predictable and easy to navigate.

Tool Count5/5

With 11 tools covering a wide but focused range of market research signals, the count is well-scoped. Each tool contributes a unique data source, and none feel redundant or missing for the server's stated purpose.

Completeness4/5

The surface covers search interest, related topics/queries, regional data, reference interest (Wikipedia), community chatter (Reddit), builder activity (HN/GitHub), news coverage, app ecosystem, and YouTube viewership. Minor gaps exist (e.g., no global 'trending now' without a keyword, no multi-keyword regional comparison), but core workflows are well supported.

Maintenance

ActivityMaintained
ResponsivenessResponsive

Resources

Related MCP Connectors

  • Google Trends MCP
    ai.trendsmcp

    Google Trends: Search, Images, News, Shopping over time, growth metrics. Free key at trendsmcp.ai

    SearchWeb ScrapingMarketing
    28
  • Google Trends
    io.github.pipeworx-io

    MCP server for google-trends

    Research & DataMarketingOpen Data
    1
  • Social Media Intelligence MCP
    ai.trendsmcp

    Cross-platform social media intelligence. Trend volume and growth signals. Free key at trendsmcp.ai

    Social MediaResearch & Data
    237
  • AIsa Content & SentimentAOAuth
    one.aisa

    Your agent needs to know where a brand or a phrase is being talked about across the web — with the trend line, the sentiment and the ratings attached. **What you can ask for** • "Where is our brand cited across the web this quarter, and is that rising?" • "What is the sentiment around this phrase?" • "How do ratings for this product distribute?" • "Which categories is this topic trending in?" • "Summarise everything published about this term." **How to use it** Point any MCP client at https://mcp.aisa.one/seo-content/mcp and sign in with OAuth — there is no key to create or paste. 10 tools: content search, summary, phrase and category trends, sentiment analysis, rating distribution, plus the filters, categories, languages and locations behind them. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find where you are mentioned here, then ask the same agent who links to those pages — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo/mcp for all of it at once — rankings, keywords, backlinks, site health and AI-answer visibility across DataForSEO, Semrush and Ahrefs.

    MarketingResearch & DataSocial Media
    151

Related MCP Servers