Skip to main content
Glama

get_project_events

Получить события таймлайна проекта: изменения индексации в Яндексе и Google, ИКС, состояние SSL и robots.txt, подключение систем аналитики, результаты краулер-аудита и т.п. Проект задаётся доменом — именно доменом, а не идентификатором. События отсортированы по дате по убыванию (новые первыми), выбрать другую сортировку нельзя. Поле status показывает значимость события: fail — проблема, warning — предупреждение, success — положительное изменение, info — информация. Тексты событий приходят на языке аккаунта, параметра языка нет. Листай по offset и ориентируйся на has_more: событий в ответе может быть меньше, чем limit, даже когда следующая страница не пустая, поэтому длина списка не признак его конца. total_events_count — число событий проекта за период без учёта exclude_events, при фильтрации оно больше числа отданных событий. Границы периода несимметричны: date_from включительно, date_to — нет, события последнего дня в выборку не попадают.

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_project_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoКоличество событий на странице.
domainYesДомен проекта, например example.com. Если известен только идентификатор проекта, возьми домен через get_user_project.
offsetNoСмещение выборки событий.
date_toNoКонец периода в формате YYYY-MM-DD, НЕ включительно: граница — 00:00:00 UTC этого дня, поэтому события самого date_to в выборку не попадают. Чтобы получить период по нужный день включительно, укажи следующий за ним день. Должно быть > date_from. Если не задано, период сверху не ограничен; предела длины периода нет.
date_fromNoНачало периода в формате YYYY-MM-DD, включительно: события этого дня входят в выборку (граница — 00:00:00 UTC). Должно быть <= date_to. Если не задано, период снизу не ограничен.
exclude_eventsNoКоды событий, которые нужно исключить из выборки. Достаточно одного неизвестного кода, чтобы вызов был отклонён целиком — валидные коды из того же списка тогда не применятся. Перечень кодов зашит в схему инструмента и может отставать от бэкенда: новый код придёт в поле type, но исключить его не получится.

Output Schema

NameRequiredDescriptionDefault
eventsYesСобытия таймлайна, отсортированные по дате по убыванию (новые первыми)
has_moreYesОстались ли события за пределами текущей страницы (offset + limit < total_events_count). Значение приблизительное: total_events_count не учитывает exclude_events, поэтому следующая страница может оказаться пустой. Ориентироваться на длину events вместо has_more нельзя — она бывает меньше limit и в середине списка
total_events_countYesЧисло событий проекта за запрошенный период. Границы периода счётчик учитывает и всегда исключает события о создании заметок (note:created), но не учитывает exclude_events, поэтому при фильтрации оно больше числа реально отдаваемых событий

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/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 fixed descending sort, status field semantics (fail/warning/success/info), account-language text, the has_more pagination trap where list length is not an end indicator, and total_events_count diverging from returned events under exclude_events. The asymmetric date boundary (date_from inclusive, date_to exclusive) is also spelled out.

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 paragraph, front-loaded with purpose and domain-keying before the operational details. Most sentences earn their place, though the date_to exclusivity note partly duplicates the schema's own wording, adding minor redundancy.

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 an output schema exists and no annotations, the description fills the behavioral gaps thoroughly: sort, status meanings, language, pagination semantics, count divergence, and date boundaries. Nothing an agent needs in order to call and interpret this tool correctly appears 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 baseline is 3. The description reinforces date-boundary behavior that the schema already documents and adds useful context on total_events_count under filtering, but most parameter meaning (limit, offset, exclude_events rejection/staleness) is already in the schema, so it adds only marginal value.

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 enumerates exactly what kinds of events it covers (indexing changes, IKS, SSL, robots.txt, analytics connections, crawler audits). The explicit note that the project is keyed by domain rather than ID further pins down the semantics, letting an agent distinguish this broad timeline tool from narrower siblings like get_changed_crawler_pages or get_project_notes.

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 concrete operational guidance: paginate via offset and has_more rather than list length, sorting is fixed, and there is no language parameter. However it never explicitly names when to prefer a sibling (e.g. get_changed_crawler_pages or get_project_notes) or when-not to use it, which keeps it short of a 5.

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