Skip to main content
Glama

срезAI — MCP-сервер и поисковый API для ИИ-агентов

Глубокое исследование / Deep research

deep_research
Read-only

Проводит многошаговое исследование: сам формулирует запросы, ищет, читает источники и возвращает готовый связный ответ со ссылками на использованные страницы.

Когда: вопрос требует сопоставления нескольких источников и вывода - «сравни», «разберись», «что известно о». Когда не: нужен один факт или список ссылок - это web_search, он в 20 раз дешевле и отвечает за секунды. Как это работает: исследование идёт долго - по замерам от 13 секунд (простой факт) до 42 минут, обычно 3-10 минут, и это дольше, чем живёт одно соединение. Поэтому инструмент запускает задачу и ждёт 45 секунд. Если за это время ответ готов - возвращает его сразу. Если нет - возвращает строку с пометкой [research_pending] и талоном (ticket). Тогда вызовите этот же инструмент ещё раз, передав ticket (query можно не повторять), чтобы дождаться готового результата; опрашивайте с паузой в минуту-две, пока не придёт ответ. Такой дозабор по талону НЕ списывается заново - деньги берутся один раз, за саму задачу. Если незавершённая задача висит больше 90 минут, инструмент честно скажет, что она зависла, - тогда имеет смысл перезапустить вопрос или сузить его. Возвращает: текст ответа плюс список источников. Если источники не вернулись, в ответе будет предупреждение - такой вывод не считается проверенным. Цена: 20 кредитов плюс 3 за каждую 1000 токенов ответа - самый дорогой вызов. Списывается один раз за задачу; повтор ТЕМЫ (новый query) - новая задача и новое списание, а дозабор по ticket бесплатен.

Runs multi-step research: forms its own queries, searches, reads sources and returns a finished answer with links to the pages it used.

Use when: the question needs several sources reconciled into a conclusion - "compare", "analyse", "what is known about". Do not use when: you need a single fact or a list of links - that is web_search, 20× cheaper and seconds fast. How it works: research takes a long time - measured from 13 seconds (a simple fact) to 42 minutes, usually 3-10 minutes, which is longer than a single connection lives. So the tool starts the job and waits 45 seconds. If the answer is ready by then, it returns it. If not, it returns a string marked [research_pending] with a ticket. Call this same tool again passing that ticket (you may omit query) to wait for the finished result; poll with a minute or two between calls until it arrives. Polling by ticket is NOT charged again - you pay once, for the job itself. If an unfinished job has been hanging for more than 90 minutes, the tool says so honestly - then restart the question or narrow it. Returns: the answer text plus a source list. If no sources came back the response says so - treat that output as unverified. Cost: 20 credits plus 3 per 1000 output tokens - the most expensive call. Charged once per job; repeating the TOPIC (a new query) is a new job and a new charge, while polling by ticket is free.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoВопрос или тема исследования. Обязателен для НОВОГО исследования; при дозаборе по ticket не нужен. / The question or research topic. Required to START research; omit it when polling by ticket.
ticketNoТалон незавершённой задачи из прошлого ответа `[research_pending]`. Передайте его, чтобы дождаться готового результата - бесплатно, без нового списания. / Ticket of an unfinished job from a previous `[research_pending]` response. Pass it to wait for the finished result - free, no new charge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / ticket / description
      Previous value: -"Талон незавершённой задачи из прошлого ответа `[research_pending]`. Передайте его, чтобы дождаться готового результата — бесплатно, без нового списания. / Ticket of an unfinished job from a previous `[research_pending]` response. Pass it to wait for the finished result — free, no new charge."New value: +"Талон незавершённой задачи из прошлого ответа `[research_pending]`. Передайте его, чтобы дождаться готового результата - бесплатно, без нового списания. / Ticket of an unfinished job from a previous `[research_pending]` response. Pass it to wait for the finished result - free, no new charge."
  2. Changed1 schema field changed
    • changedInput schema / properties / ticket / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "number"
      +]
  3. Changed4 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Вопрос или тема исследования / The question or research topic"New value: +"Вопрос или тема исследования. Обязателен для НОВОГО исследования; при дозаборе по ticket не нужен. / The question or research topic. Required to START research; omit it when polling by ticket."
    • removedInput schema / properties / query / minLength
      Removed value: -1
    • addedInput schema / properties / ticket
      Added value: +{
      +  "description": "Талон незавершённой задачи из прошлого ответа `[research_pending]`. Передайте его, чтобы дождаться готового результата — бесплатно, без нового списания. / Ticket of an unfinished job from a previous `[research_pending]` response. Pass it to wait for the finished result — free, no new charge.",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "query"
      -]
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond the annotations (which only say readOnly/non-destructive/openWorld). It discloses the async contract (45s wait, `[research_pending]` + ticket), the 90-minute hang behavior, the unverified-output warning when no sources return, and the full pricing model (20 credits + 3/1000 output tokens, charged once, free ticket polling). This is exactly the kind of behavioral context annotations cannot carry.

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?

Information-dense and front-loaded: purpose, then when/when-not, then mechanism, then returns, then cost. Each sentence earns its place, though the bilingual duplication roughly doubles the token footprint and some cost/polling points restate the schema descriptions.

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 an async, expensive, non-idempotent, open-world tool with no output schema, the description covers the return shape (answer text + source list), degraded-return warning, timing expectations, retry/polling protocol and cost — everything an agent needs to invoke and re-invoke it correctly.

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 description coverage is already 100%, so the baseline is 3. The description still adds workflow meaning: query is required only for a NEW topic, ticket retrieves an existing job and may be passed with query omitted, and the ticket path is not re-charged. Redundant with the schema's own text in places, hence not a 5.

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?

Opens with a concrete verb+resource chain ('runs multi-step research: forms its own queries, searches, reads sources, returns a finished answer with links'), which is far more specific than the name alone. It explicitly distinguishes itself from the sibling web_search as the cheap/fast alternative.

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?

Provides explicit 'Use when' (multi-source reconciliation, 'compare', 'analyse', 'what is known about') and 'Do not use when' (single fact or link list → web_search, 20× cheaper). It also gives operational guidance for the async path: poll by ticket with a 1-2 minute pause, and restart/narrow if the job hangs past 90 minutes.

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.