Skip to main content
Glama

trends_search

Read-only

Лента трендов: какие ролики сейчас взлетают, с числами, x-фактором, скоростью набора просмотров и долей комментариев. Главный инструмент продукта — с него отвечают на «что нового в моей теме за сутки». Ниши берутся из niches_list.

ЧЕТЫРЕ ЛОВУШКИ, без которых вывод будет неверным:

  1. days — это НЕ «опубликовано за N дней». Условие в коде: trending_since >= cutoff ИЛИ published_at >= cutoff. days=1 вернёт и ролик, опубликованный позавчера, если движок признал его трендом сегодня. Называть выдачу «ролики за сутки» нельзя — это «попало в тренд за сутки ИЛИ вышло за сутки».

  2. Поверх любого days на вкладках global и for_you всегда стоит пол свежести: опубликовано не раньше 7 суток назад. days=90 на них не расширит окно — потолок останется недельным.

  3. sort=velocity — скорость набора, УЦЕНЁННАЯ возрастом замера (полураспад 12 ч): вчерашний рекорд уступает свежему замеру поскромнее, поэтому порядок может расходиться с сырым views_per_hour_at_last_check; ролики без замера скорости и с нулевой — в конце. sort=comment_rate — доля комментариев от просмотров; с долей null — в конце. Сортировки по hot_score нет: в коде это значение делает ORDER BY x_factor DESC.

  4. tab=my_authors — это НЕ тренды. Там сняты флаг тренда, порог min_x и семисуточный пол свежести, но окно days ДЕЙСТВУЕТ и там: это лента отслеживаемых авторов за окно days по дате публикации, а не вся их хронология. Чтобы получить всю, задайте days явно большим. x_factor у таких роликов чаще всего отсутствует, и это нормально.

Скорость набора (views_per_hour_at_last_check) измерена в момент последней проверки автора, а не сейчас, и может быть null — это «не измеряли», а не «ноль». Так же читаются comment_rate (доля комментариев), comment_rate_x (она же к норме автора) и funnel (признак воронки «напиши слово — пришлю»): null — не измеряли.

Input Schema

NameRequiredDescriptionDefault
qNoПоиск по подписи ролика и нику автора. На FREE недоступен.
tabNoglobal — все авторы базы; my_authors — ваши авторы без фильтров тренда, но в пределах окна days; for_you — тренды, суженные до ваших ниш и интересов. По умолчанию global.
daysNoОкно «признан трендом ИЛИ опубликован» в днях, 1..3650. По умолчанию 1 на global и for_you (там поверх всё равно стоит недельный пол) и 90 на my_authors — у автора, снимающего пару раз в неделю, суточное окно пусто, и это читалось бы как «автор молчит».
pageNoСтраница, с 1
sortNoПо умолчанию x_factor, а на my_authors — recent. velocity — скорость с уценкой возраста замера, comment_rate — доля комментариев. Сортировки по hot_score не существует.
min_xNoМинимальный x-фактор, по умолчанию 2.0. На tab=my_authors не применяется вовсе.
nicheNoНиши через запятую, до 20: slug ниши и/или group_key из niches_list. Неизвестное значение ошибки не даёт — молча сужает выдачу до пустой; нерезолвнутое перечислено в ответе полем niche_unresolved.
per_pageNoСтрок на страницу, до 50
platformNoinstagram | tiktok | youtube; пусто — все. Регистр и сокращения не понимаются: "Instagram" или "ig" — ошибка, а не пустая выдача.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive, and the description goes far beyond them: the days filter is an OR of trending_since and published_at, global/for_you carry a hard 7-day freshness floor that caps any days value, velocity is age-discounted with a 12h half-life, nulls in velocity/comment_rate/funnel mean 'not measured' rather than zero, and unknown niche slugs silently narrow to empty instead of erroring. This is exactly the non-obvious behavior an agent needs to interpret results correctly.

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 correctly: one sentence states the tool's identity, then a numbered list of four numbered traps that each earn their place. It is still long and overlaps the schema in places (the days definition appears both in the schema and in trap 1), which costs a point.

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 9-parameter, no-output-schema, multi-mode tool, the description closes every gap that matters: filter semantics, cross-parameter interactions (floor over days, min_x disabled on my_authors), sort behavior, null interpretation for all output metrics, and silent-empty failure modes. An agent could call this correctly and interpret the rows without further help.

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?

Although schema coverage is already 100%, the description adds meaning the schema does not carry: why days defaults to 90 on my_authors (a sporadic poster's 24h window reads as silence), that min_x is not applied at all on my_authors, that sort=hot_score does not exist because it is ORDER BY x_factor DESC, and that platform abbreviations or wrong casing error out rather than returning empty.

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 names a specific resource and its payload: a trends feed with x-factor, view velocity, and comment share, explicitly framed as the product's primary tool for 'what's new in my niche in the last 24h'. The scope is further pinned down by enumerating the three tabs and stating outright that tab=my_authors is not trends, which leaves no ambiguity about what this tool returns.

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 strongly contextualized: the agent is told this is the go-to tool for 'what's new in my topic over 24h', which tab to pick, and how to widen the window on my_authors ('set days explicitly large'). What is missing is routing against siblings — nothing says when to prefer query_reels or niche_search instead, so the comparison 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources