Skip to main content
Glama

WebAsk MCP

by io.webask.mcp
OverviewDiscussionsAdmin

Сборка опроса по описанию

generate_ai_quiz

Собирает опрос по текстовому описанию. Сборка идёт в фоне: вызов возвращает ID будущего опроса и ставит работу в очередь, а сам опрос сначала пустой. Готовность спрашивают этим же инструментом, передав quiz_id — придёт pending или ready. Так же это устроено в кабинете; синхронной сборки нет, потому что обращения к модели занимают до минуты и обрывались по таймауту.

Input Schema

NameRequiredDescriptionDefault
promptNoПользовательское описание того, какой опрос нужно создать.
ai_typeNoЧто собирать: quiz — обычный опрос, у вопросов нет правильных ответов; test — тест, где у вариантов проставлены баллы и отмечены правильные ответы, а респондент в конце получает результат. По умолчанию quiz.
projectNoМетка проекта для своего учёта: произвольная строка, которая просто сохраняется у опроса. На поведение не влияет, респондент её не видит. Не просите её у человека сами.
quiz_idNoID опроса из предыдущего вызова. Передайте его, чтобы узнать, готова ли сборка. Вместе с ним folder_id и prompt не нужны.
folder_idNoID папки, в которой нужно создать AI-опрос. Взять из folder://list.
with_logicNoПросить ли AI сразу построить логику переходов между вопросами (ветвление по ответам). Без неё вопросы идут подряд.
source_textNoНеобязательный исходный материал, по которому строить вопросы, например текст статьи. Передавать, только если человек дал такой материал. Принимается до 100 000 символов, в работу идут первые 20 000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / source_text
      Added value: +{
+  "description": "Необязательный исходный материал, по которому строить вопросы, например текст статьи. Передавать, только если человек дал такой материал. Принимается до 100 000 символов, в работу идут первые 20 000.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare the safety profile (not read-only, not idempotent). The description adds the critical non-obvious behavior: the call is asynchronous, returns only an ID, the quiz starts empty, readiness is polled via the same tool, and the reason synchronous assembly was rejected (model calls take up to a minute and timed 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?

Front-loaded with the core action, then the async mechanics, keeping every operative detail early. The closing justification about the UI is slightly expendable but reinforces why no synchronous path exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully explains the return contract (an ID followed by pending/ready polling). For a 7-parameter asynchronous generator this is close to complete, though the interplay of with_logic/source_text/ai_type during polling could be stated more tightly.

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 coverage is 100%, and the schema already documents each parameter in detail, including that quiz_id mutual exclusion with folder_id/prompt. The description repeats that polling mode rather than adding syntax or format beyond the schema, so the baseline 3 applies.

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 states a specific verb and resource — assembling a quiz from a text description — and the AI-from-prompt scope inherently distinguishes it from manual siblings like create_quiz and create_quiz_from_template. An agent immediately understands what this tool produces.

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 clearly explains the operating context (background assembly, no synchronous option) and how to poll with quiz_id for pending/ready. It does not, however, explicitly route the agent between this tool and the manual/template creation siblings.

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