Skip to main content
Glama

get_crawler_analysis_summary

Получить сводку по аудиту сайта: состояние последнего аудита, оценку здоровья сайта (results.health.rank от 0 до 1), распределение страниц по HTTP-кодам и число страниц с каждой найденной проблемой — title, description, H1, canonical, noindex, скорость, ссылки, Open Graph и т.п. По запросу (параметр history) — историю этих показателей по дням, неделям или месяцам. Это отправная точка для разбора аудита: сводка показывает, каких проблем сколько, а сами страницы с проблемой получай через get_crawler_pages с соответствующим фильтром. Если is_updating = true, аудит сейчас выполняется и сводка собирается заново, поэтому цифры в ней неполные. Историю запрашивай, только когда нужна динамика: она заметно увеличивает ответ.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "get_crawler_analysis_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainYesДомен проекта, например example.com. Для проекта должен быть настроен аудит (паук), иначе вызов будет отклонён.
historyNoКакую историю показателей вернуть: none — без истории (самый лёгкий ответ), days — по дням за последние 31 день, weeks — медианы по неделям за последний год, months — медианы по месяцам за всё время. За вызов — один интервал.none
history_blocksNoБлоки results, по которым нужна история, например ["statusCode", "health"]. null — все блоки. При history = none не используется. Сначала смотри сводку без истории, потом запрашивай историю только тех блоков, где есть проблема.

Output Schema

NameRequiredDescriptionDefault
idYesИдентификатор аудита
domainYesДомен проекта
createdNoКогда аудит был создан, ISO 8601 с таймзоной
historyNoИстория показателей results за интервал из параметра history и только по блокам из history_blocks (если он задан); null, если историю не запрашивали (history = none). Ключ первого уровня — имя блока из results, второго — имя поля с суффиксом History, например history.health.rankHistory или history.title.noneHistory. У statusCode.codesHistory значения — словари {код: число страниц}. У блоков-списков хранится только dublicatesCountHistory. У loadTime история totalTime — сумма, а не среднее: среднее считай делением на totalCountHistory за ту же дату
resultsYesСводка проверок по последнему аудиту. Блок равен null, если проверка ещё ни разу не выполнялась. Страницы считаются только те, к которым проверка применима: например, title и H1 — только у HTML-страниц, поэтому их суммы бывают меньше indexed_links_count. Подробности по страницам — через get_crawler_pages с соответствующими фильтрами
startedNoНачало последнего аудита, ISO 8601 с таймзоной. null — аудит ещё не запускался
updatedNoОкончание последнего завершённого аудита, ISO 8601 с таймзоной. Если started позже updated, идёт новый аудит, а сводка пока от предыдущего
modifiedNoПоследнее изменение данных аудита, ISO 8601 с таймзоной. Во время аудита обновляется по мере обхода страниц
is_expiredYesУстарел ли аудит: не запускался, завис или последний аудит старше суток
robot_typeNoUser-agent, правила которого паук берёт из robots.txt; * — общие правила
is_updatingYesВыполняется ли сейчас аудит
pages_limitYesЛимит страниц на один аудит по тарифу владельца проекта
crawler_modeYesИсточники страниц для обхода: crawler — переход по ссылкам, sitemap — ссылки из sitemap.xml, userLinks — список страниц, заданный пользователем
used_sitemapsNoURL файлов sitemap, из которых взяты страницы в режиме sitemap
use_robots_txtYesУчитывает ли паук правила robots.txt
new_links_countYesСсылок в очереди на обход (ненулевое во время аудита)
is_not_respondingYesЗавис ли текущий аудит: больше минуты нет прогресса, а в очереди остались ссылки
crawler_user_linksNoСтраницы, заданные пользователем для обхода в режиме userLinks
failed_links_countYesАдресов, которые паук нашёл, но не смог загрузить: сервер не ответил за 15 секунд, соединение оборвалось или ответ больше 8 МБ. Проверок по ним нет, в get_crawler_pages они не попадают. Не путать со страницами с кодом ответа 4xx/5xx — те загрузились
indexed_links_countYesСтраниц, обойдённых пауком в последнем аудите
in_progress_links_countYesСсылок, которые паук загружает прямо сейчас
not_canonical_links_countYesНайдено неканонических ссылок — ведущих на страницы с canonical на другой URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

No annotations, so the description carries the burden, and it does disclose key traits: is_updating=true means the audit is running and numbers are incomplete, history inflates response size, and the call is rejected if no audit is configured. It stops short of describing auth/rate-limit context, but the behavioral profile is unusually well covered.

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 core purpose, then progressively adds history, drill-down routing, the is_updating caveat, and the history-cost warning. Every sentence earns its place with no 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?

An output schema exists, so return-value explanation isn't required; the description still explains the health rank semantics and the is_updating incompleteness edge case. Given a 3-param tool with one enum and full schema coverage, 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.

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description adds value beyond the schema by explaining the cost tradeoff of history ('noticeably increases the response') and the recommended sequencing ('first look at summary without history, then request history only for blocks with a problem'), which the schema's history_blocks text reinforces.

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: get a summary of the site audit, listing exactly what's included (audit state, health rank 0-1, HTTP code distribution, per-issue page counts). An agent can distinguish it from get_crawler_pages and other crawler tools 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 frames itself as the 'starting point' for audit analysis, tells the agent how to drill down ('get pages with the problem through get_crawler_pages with the corresponding filter'), and gives a when-to/when-not rule for history ('request only when you need dynamics: it noticeably increases the response').

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