Skip to main content
Glama

WebAsk MCP

by io.webask.mcp
OverviewDiscussionsAdmin

Журнал посещений

get_quiz_visits
Read-onlyIdempotent

Список посещений опроса, сначала новые: когда, устройство, браузер, страна, параметры ссылки и что стало с посещением — статус no_answer, unfinished, screenout или completed (по лучшему ответу посещения) и answer_id, чтобы открыть ответ. total — сколько посещений подходит под все фильтры, counts — по статусам под теми же фильтрами без учёта status. Фильтры: status (started — все посещения с ответом), значение параметра ссылки (param_key + param_value; пустое значение допустимо) или его отсутствие (param_key + param_missing = true), устройство, браузер или страна (segment_by + segment_value, либо segment_unknown = true — значение неизвестно), период и устройство. На тарифе без незавершённых ответов answer_id у unfinished и screenout — null: такие ответы там не открываются. У посещения также city (город по IP на языке аккаунта), ip (null у посещений панели респондентов), referrer (только домен сайта, с которого пришли) и is_bot (поисковый робот, превью ссылки в мессенджере или соцсети, безголовый браузер или http-клиент — по User-Agent); bots — сколько роботов под теми же фильтрами без учёта hide_bots. hide_bots = true убирает роботов из items, total и counts. В опросе с анонимными ответами устройство, браузер, страна, город, ip и referrer — null.

Input Schema

NameRequiredDescriptionDefault
limitNoСколько посещений на странице, от 1 до 100. По умолчанию 30.
deviceNoТолько посещения с этого устройства: desktop, mobile, tablet.
offsetNoСколько посещений пропустить, от 0 до 1000000. По умолчанию 0.
statusNoall (по умолчанию), no_answer, started, completed, unfinished, screenout.
date_toNoПоследний день периода, YYYY-MM-DD, включительно.
quiz_idYesID опроса.
date_fromNoПервый день периода, YYYY-MM-DD, включительно. Период — по дню посещения в часовом поясе владельца опроса.
hide_botsNotrue — без роботов: их нет в items, total и counts.
param_keyNoИмя параметра ссылки, например utm_source. Нужен param_value или param_missing.
segment_byNodevice, browser или country. Нужен segment_value или segment_unknown.
param_valueNoТолько посещения с этим значением параметра. Пустая строка — параметр был, но пустой.
param_missingNotrue — только посещения, пришедшие без param_key.
segment_valueNoТолько посещения с этим устройством, браузером или страной — как их отдаёт get_quiz_visit_segments.
segment_unknownNotrue — только посещения, у которых segment_by неизвестен.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / hide_bots
      Added value: +{
+  "description": "true — без роботов: их нет в items, total и counts.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses substantive behavioral traits: total respects all filters while counts ignores the status filter, bots counts ignores hide_bots, and answer_id is null for unfinished/screenout on tariffs without unfinished answers. It also documents nullability of city/ip/referrer in anonymous surveys — rich context the schema cannot express.

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 dense but front-loads what the tool returns before moving to filters and edge cases. It is longer than average, and a few clauses could be tightened, but nearly every sentence carries information about return shape or filter interaction rather than 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?

With 14 parameters and no output schema, the description carries the burden of explaining the response object (items fields, total, counts, bots) and it does so explicitly, including nullability edge cases. An agent can call this correctly and interpret the result without seeing an output schema.

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 genuine meaning beyond the schema: the 'started' status definition, the best-answer basis for the status, the tally semantics of total vs counts vs bots, and the interaction of hide_bots with items/total/counts. That is more than the enum descriptions alone convey.

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+resource ('Список посещений опроса') and immediately states ordering (newest first) and the returned fields (time, device, browser, country, link params, status, answer_id). This clearly distinguishes it from sibling answer-listing tools like get_quiz_answers, which it implicitly contrasts by returning visit-level status and answer_id.

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 filter semantics in detail: status values including 'started — все посещения с ответом', the param_key+param_value/param_missing dichotomy, segment_by+segment_value/segment_unknown, and hide_bots. It gives clear conditions for each filter but does not explicitly name a sibling alternative to use instead, so a 4 rather than 5.

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

All WebAsk MCP toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources