Tanod MCP server

utilpeek: topic trends over time from public attention (Wikipedia views, Hacker News, news), not Google Trends

get_topic_trends_attention

Read-onlyIdempotent

Track whether interest in up to five topics is rising or fading using daily Wikipedia views, Hacker News counts, and news mentions over time.

Instructions

utilpeek: Use when an agent must tell if interest in a topic is rising or fading: Wikipedia, Hacker News and news over time. For the articles use news_search. Returns daily topic trends for 1 to 5 topics: Wikipedia page views per language, Hacker News counts, news mentions, with 7- and 28-day change, spike days, direction and share. Not Google Trends data. Public attention signals, not Google Trends or search volume. related: related Wikipedia topics ranked by page views; not search queries and not Google Trends data. Topic = top English Wikipedia hit (see article.title). Complete days to yesterday; news only for the last 14 days. Cached 6 h. Bad input is a 422 and an upstream failure a 503 or 504 (not charged). Typically 3 to 15 s (first call for a topic; cached for 6 hours). Price: USD 0.005. Free: 10 utilpeek calls per IP per UTC day. Docs: https://tanod.dev/learn/topic-trends-attention-api.html

Input Schema

TableJSON Schema

Name	Required	Description
`end`	No	Last day, YYYY-MM-DD (UTC), at most yesterday (later is clamped to it). Default: yesterday. The range is at most 365 days.
`start`	No	First day, YYYY-MM-DD (UTC). Default: 90 days ending at `end`.
`topics`	Yes	1 to 5 topics (words or a name, up to 100 characters each). Each is resolved to the top English Wikipedia search hit, reported as `article.title`. Several topics are compared: each gets its relative share.
`related`	No	Default false. True (one topic only) adds `related`: up to 10 `top` and 10 `rising` related Wikipedia topics, ranked by page views; not search queries and not Google Trends data.
`languages`	No	Optional Wikipedia language codes, at most 6 (en, de, ja ...). Default: en plus the four most-read languages that have the article. A language without the article is listed under `languages_skipped`.

Output Schema

TableJSON Schema

Name	Required	Description
`end`	No
`days`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`label`	No
`start`	No
`method`	No
`topics`	No
`caveats`	No
`related`	No
`warnings`	No
`comparison`	No
`attribution`	No
`not_google_trends`	No
`end_clamped_to_yesterday`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/open-world, but the description adds much more: 6 h caching, 3-15 s latency, USD 0.005 price with a 10-calls/IP/day free tier, 422/503/504 error semantics (503/504 not charged), and data completeness (complete days to yesterday). This is exactly the operational context annotations cannot convey.

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?

The core is front-loaded well, but the 'not Google Trends' disclaimer is repeated three-plus times and the 'not search queries' caveat twice, which inflates the text without adding information. Much of the operational detail earns its place, but the redundancy costs it.

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 complex, paid, open-world data tool this is unusually complete: pricing, rate limits, latency, cache TTL, error codes, topic resolution, language fallback behavior, and data recency are all covered. Return structure is documented by the output schema, so no gap remains.

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: `related` only applies with a single topic, each topic resolves to the top English Wikipedia hit surfaced as `article.title`, and multiple topics are compared by relative share. These behavioral couplings are not obvious from the schema alone.

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 purpose (tell if interest in a topic is rising or fading) and names the concrete signals (Wikipedia page views, Hacker News, news). It explicitly disambiguates from Google Trends and routes to the news_search sibling for articles, so an agent can place it precisely.

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?

Opens with 'Use when an agent must tell if interest in a topic is rising or fading', giving a clear trigger, and names an alternative ('For the articles use news_search'). It also states the data window limits (news only last 14 days) that constrain when results are meaningful.

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

Deploy Server