Skip to main content
Glama

срезAI — Search API for AI agents

by ru.srezai
OverviewDiscussionsAdmin

Server Details

Web search, page reading and structured extraction for AI agents, with strong RU coverage

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.1% over 43 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 12 tools

Disambiguation4/5

Each tool documents an explicit niche with 'when to use / when not' cross-references, and the read-side tools (read_url, read_urls, crawl, fetch_page, extract) and synthesis tools (answer_search, deep_research, verify_claim) are deliberately separated by cost and output. However, the search-plus-synthesis family still forms a spectrum where an agent could plausibly misselect (e.g. answer_search vs deep_research vs web_search with excerpts).

Naming Consistency3/5

All names are snake_case with no case mixing, which helps, but three different conventions coexist: verb_noun (read_url, verify_claim, get_usage, fetch_page), noun_search (web_search, image_search, answer_search), and bare verbs/nouns (crawl, extract, map). The result is readable but not a single predictable pattern.

Tool Count5/5

Twelve tools sit comfortably in the 3–15 well-scoped range and each maps to a distinct capability—search, URL discovery, single/batch/crawl reading, structured extraction, screenshot, verification, deep research, and usage/billing. No obvious filler or redundant entry.

Completeness4/5

The surface covers the full retrieval lifecycle: discovery (web_search, image_search, map), reading (read_url, read_urls, crawl, fetch_page), extraction (extract), synthesis (answer_search, deep_research), verification (verify_claim), and account monitoring (get_usage). Minor gaps remain—no dedicated news/scholarly search, no PDF/document extraction outside page text, and no batch verify.

Available Tools

12 tools
crawlОбойти сайт / Crawl a siteA
Read-onlyIdempotent
Inspect

Читает разделы сайта и читает найденные страницы: сначала карта адресов (как в map), затем текст страниц. Один вызов вместо «нашёл ссылку — прочитал — нашёл следующую»: так собирают всё содержимое раздела, а не отдельные страницы.

Когда: нужно содержимое нескольких страниц одного сайта — «собери все события с этого агрегатора», «прочитай раздел документации», «что в этом каталоге». Когда не: нужен только список адресов — map (дешевле, страницы не читаются); нужна одна страница — read_url. Фильтр search у crawl сравнивается с ТЕКСТОМ прочитанных страниц (не с адресом), а selectPaths/excludePaths отбирают САМИ адреса. Порядок такой: сначала map (увидеть разделы и адреса), затем crawl с selectPaths по нужному разделу и, если надо, с search по тексту. Возвращает: pages (адрес, заголовок, текст до 20 000 символов на страницу) и skipped — адреса, которые не прочитались, с причиной. Недоступные страницы не роняют чтение: остальные отдаются, а причина названа. Цена: карта (1 кредит за 10 возвращённых адресов, минимум 1) плюс 1 кредит за каждую прочитанную страницу. Не прочиталась — не считается.

Crawls a site and reads the pages it finds: first the URL map (as in map), then the page text. One call instead of "found a link — read it — found the next one": this is how you collect a whole section rather than single pages.

Use when: you need the content of several pages of one site — "collect every event from this aggregator", "read this docs section". Do not use when: you only need the list of URLs — map (cheaper, no page reads); you need one page — read_url. The search filter here matches the TEXT of the pages read (not the URL): search: "conference" keeps pages that mention it. So the order is: map with a URL filter first (to see the structure), then crawl with a text filter. Returns: pages (URL, title, up to 20 000 chars of text each) and skipped — URLs that could not be read, with the reason. Unreachable pages do not break the crawl: the rest are returned and the reason is stated. Cost: the map (1 credit per 10 URLs returned, minimum 1) plus 1 credit per page read. A page that failed to read is not counted.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesСайт или страница (http/https) / Site or page URL
limitNoСколько страниц прочитать (1–20, по умолчанию 5). / How many pages to read (1–20, default 5).
searchNoОставить страницы, в тексте или заголовке которых есть эти слова (фильтр по СОДЕРЖИМОМУ прочитанного). / Keep pages whose text or title contains these words (a filter over the CONTENT read).
selectPathsNoЧитать только страницы, адрес которых содержит любую из этих подстрок — это и есть прицельное чтение раздела. Без него crawl читает первые адреса карты, а у агрегаторов это служебные страницы, а не события. / Read only pages whose URL contains any of these substrings — this is how you target a section. Without it crawl reads the first URLs of the map, which on aggregators are service pages, not events.
excludePathsNoНе читать страницы, чей адрес содержит любую из этих подстрок. / Do not read pages whose URL contains any of these substrings.
includeSubdomainsNoСчитать своими и поддомены. / Treat subdomains as own.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, but the description adds substantial context they cannot: a precise cost model (1 credit per 10 returned URLs, 1 credit per page read, failed reads not charged), graceful degradation ('unreachable pages do not break the crawl'), a 20 000-char per-page cap, and a skipped-with-reason list. This is exactly the beyond-annotation disclosure expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is well front-loaded (purpose, when/when-not, filters, returns, cost), but every sentence is duplicated in Russian and English, roughly doubling the length for no informational gain. The Russian block also adds a subtle semantic nuance about search vs selectPaths/URL filtering not fully mirrored in English, so the redundancy is not purely wasteful but still heavy.

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 a 6-parameter open-world reader with no output schema, the description supplies everything an agent needs: return shape (pages URL/title/text plus skipped with reasons), failure behavior, cost, and the interaction between the text filter and URL filters. Nothing material is left unstated.

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 earns more by clarifying semantics the schema only partially conveys: search matches page TEXT/title rather than URL, selectPaths/excludePaths match URL substrings, and the warning that omitting selectPaths makes crawl read the map's first (often service) URLs. That is meaningful disambiguation beyond the field descriptions.

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 opening states a specific verb and resource — crawl reads a site's URL map then the page text — and frames it as one call replacing the manual find-link/read loop. It explicitly distinguishes itself from siblings map and read_url, so an agent can select it without opening any 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?

There are dedicated 'Use when' and 'Do not use when' sections naming concrete triggers ('collect every event from this aggregator', 'read this docs section') and the alternatives that win in the excluded cases (map for URL lists, read_url for one page). It even prescribes the recommended call order (map first, then crawl with selectPaths/search).

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

deep_researchГлубокое исследование / Deep researchA
Read-only
Inspect

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

Когда: вопрос требует сопоставления нескольких источников и вывода — «сравни», «разберись», «что известно о». Когда не: нужен один факт или список ссылок — это web_search, он в 20 раз дешевле и отвечает за секунды. Как это работает: исследование идёт 10–40 секунд. Инструмент сам запускает конвейер — переформулировка вопроса, параллельный поиск, семантическое ранжирование, чтение источников и синтез — и возвращает готовый ответ в том же вызове. Ждать и дозабирать результат по талону больше не нужно. Если набор источников оказался неполным (сработал предел по времени), в ответе будет честная пометка об этом — такой вывод стоит перепроверить через verify_claim. Запасной путь: если конвейер недоступен, инструмент переходит на прежний воркфлоу (3–40 минут) и возвращает строку с пометкой [research_pending] и талоном (ticket) — тогда вызовите инструмент ещё раз с этим ticket (query можно не повторять), чтобы забрать результат. Дозабор по талону НЕ списывается заново — деньги берутся один раз, за саму задачу. Возвращает: текст ответа плюс список источников. Если источники не вернулись, в ответе будет предупреждение — такой вывод не считается проверенным. Цена: 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 10–40 seconds. The tool runs the pipeline itself — query rewriting, parallel search, semantic reranking, source reading, synthesis — and returns the finished answer in the same call. No hour-long waits and no ticket polling. If the source set turned out incomplete (the wall-clock limit hit), the response says so honestly — verify such output with verify_claim. Fallback: if the pipeline is unavailable the tool switches to the previous workflow (3–40 minutes) and returns a string marked [research_pending] with a ticket — call the tool again with that ticket (you may omit query) to collect the result. Polling by ticket is NOT charged again — you pay once, for the job itself. 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.

ParametersJSON 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.

TDQS

A4.5/5.0
Behavior4/5

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

Exceptionally rich: pipeline stages, 10–40 s runtime, honest 'incomplete sources' warning plus verify_claim escalation, a documented fallback path when the pipeline is down (3–40 min, `[research_pending]` string with a ticket), and a full pricing model. Annotations already cover readOnly/openWorld, but the description adds far more than they carry. Only gap: no explicit statement of what happens on mid-flight failure of the primary pipeline beyond the fallback.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded well (purpose, when/when-not, mechanics), but it is bloated: the entire content is duplicated in Russian and English, and the 'ticket polling is not recharged' rule is stated three separate times. The complexity justifies length, but the duplication and repetition are avoidable.

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?

No output schema exists, yet the description fully specifies the return shape (answer text plus source list, with an explicit unverified-warning case), all three execution paths, latency expectations, and cost. Nothing an agent needs to call and interpret this tool is missing.

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 already 100%, so the baseline is 3, but the prose adds real invocation semantics: query is required only for a NEW job and may be omitted when polling, and repeating the topic with a new query is a brand-new charge while a ticket poll is free. This shapes how the agent should sequence calls rather than just restating field types.

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 precise verb chain and resource: it formulates queries, searches, reads sources, and returns a synthesized answer with page links. It is immediately distinguishable from web_search (single fact / link list) and verify_claim (re-checking shaky output), which it names explicitly.

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?

Gives an explicit 'When' trigger (questions needing several sources reconciled — 'compare', 'analyse', 'what is known about') and an explicit 'When not' with the alternative named (web_search, 20× cheaper, seconds fast). Routing is unambiguous.

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

extractИзвлечь данные по схеме / Extract data by schemaA
Read-onlyIdempotent
Inspect

Читает страницу и возвращает JSON строго по вашей схеме: только запрошенные поля, без текста страницы. Чего на странице нет — приходит null, значения не домысливаются.

Когда: нужны 2–5 конкретных значений — цена, характеристики, автор и дата, список вакансий. Экономит контекст: вместо всей страницы придут только поля. Когда не: нужен связный текст или вы не знаете заранее, что искать, — read_url (и в 4 раза дешевле). Схема: принимается и сокращённая форма — {"title":"string","price":"number?"}, где «?» делает поле необязательным, а «[]» — массивом; полный JSON Schema тоже работает. Описания полей заметно повышают точность разбора. Возвращает: объект по схеме на каждую ссылку. Можно передать до 5 ссылок разом — одна схема применится ко всем. Цена: 2 кредита за каждую ссылку (чтение плюс разбор моделью).

Reads a page and returns JSON strictly following your schema: only the requested fields, no page text. Anything absent from the page comes back as null — values are never invented.

Use when: you need a handful of specific values — price, specs, author and date, a list of job openings. It saves context: you get the fields, not the page. Do not use when: you need prose, or you do not know in advance what to look for — read_url (and 4× cheaper). Schema: a shorthand form is accepted — {"title":"string","price":"number?"}, where "?" marks a field optional and "[]" an array; full JSON Schema works too. Field descriptions noticeably improve extraction accuracy. Returns: one object per link, shaped by your schema. Up to 5 links per call, one schema applied to all. Cost: 2 credits per link (page read plus model parsing).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoURL страницы (http/https) / Page URL (http/https)
urlsNoСписок URL (1–5) вместо url — одна схема на все страницы. Каждая страница тарифицируется отдельно. / A list of URLs (1–5) instead of url — one schema for all pages. Each page is billed separately.
engineNoКак забирать страницу: auto (по умолчанию), fast, dynamic, stealth. / How to fetch the page: auto (default), fast, dynamic, stealth.
schemaNoСхема результата. Проще всего — сокращённая форма: {"title":"string","price":"number?","tags":"string[]"}, где «?» помечает поле необязательным, а «[]» — массивом. Полный JSON Schema тоже принимается: {"type":"object","properties":{"price":{"type":"number","description":"цена в рублях"}},"required":["price"]}. Типы: string, number, integer, boolean, array, object. Описания полей заметно повышают точность. / The result schema. The simplest form is shorthand: {"title":"string","price":"number?","tags":"string[]"}, where «?» marks the field optional and «[]» marks an array. Full JSON Schema is accepted too. Types: string, number, integer, boolean, array, object. Field descriptions noticeably improve accuracy.
instructionNoУточнение для разбора, если из схемы неочевидно: «бери цену со скидкой», «только вакансии удалённо». / A parsing hint when the schema alone is ambiguous: «use the discounted price», «remote positions only».

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations covering read-only, open-world, idempotent, and non-destructive behavior, the description discloses important traits: absent fields return null, values are never invented, up to 5 links can be processed with one schema, each link is billed separately at 2 credits, and field descriptions improve accuracy. It also explains the output shape per link. No annotation contradiction is present.

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 content is front-loaded with clear sections for purpose, usage, schema, returns, and cost. However, the full Russian and English versions duplicate each other, which adds length without new meaning for a single-language agent. Structure is strong but conciseness is slightly reduced by bilingual duplication.

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?

The tool has no output schema, but the description explains the return shape clearly: one object per link shaped by the user's schema. Annotations cover the safety profile, schema coverage is 100%, and the description supplies usage guidance, cost, limits, and behavioral details. It is complete enough for correct invocation.

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 schema already documents all five parameters, including url, urls, engine, schema, and instruction. The description repeats the schema shorthand guidance but adds little parameter-level meaning beyond what the schema provides. This meets the baseline 3 for high schema coverage.

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: reads a page and returns JSON strictly following a user-provided schema, with only requested fields and no page text. It explicitly distinguishes itself from read_url by recommending read_url for prose and noting that read_url is 4x cheaper. An agent can select this tool without opening the 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?

It gives explicit when-to-use guidance (2–5 concrete values such as price, specs, author/date, job list) and when-not-to-use guidance (need prose or do not know what to look for). It names the alternative read_url and even states the cost trade-off. No inference is required.

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

fetch_pageСкриншот и структура страницы / Page screenshot and structureA
Read-onlyIdempotent
Inspect

Открывает страницу полноценным браузером и возвращает скриншот картинкой прямо в ответе, ссылку на полноразмерный файл и текст страницы в markdown.

Когда: нужно УВИДЕТЬ страницу — раскладку, цвета, типографику, визуальную иерархию: «повтори дизайн как здесь», «что не так с вёрсткой». Когда не: нужен только текст — read_url (1 кредит против 3, и быстрее); нужны отдельные значения — extract. Возвращает: изображение плюс текст. Картинка занимает много контекста, поэтому для чтения этот инструмент избыточен. Если браузер не успел отрендерить страницу, вернём её текст (то же, что даёт read_url), скажем об этом прямо и спишем 1 кредит вместо 3. Цена: 3 кредита (1, если скриншот не получился).

Opens the page in a full browser and returns a screenshot as an inline image, a link to the full-size file, and the page text in markdown.

Use when: you need to SEE the page — layout, colours, typography, visual hierarchy: "match this design", "what looks broken here". Do not use when: you only need text — read_url (1 credit vs 3, and faster); you need specific values — extract. Returns: an image plus text. The image consumes a lot of context, which makes this tool overkill for reading. If the browser fails to render the page, its text is returned instead (the same as read_url), the reply says so, and 1 credit is charged instead of 3. Cost: 3 credits (1 if the screenshot could not be captured).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesПолный URL страницы (http/https) / Full page URL (http/https)
maxCharsNoСколько символов текста вернуть (200–50000, по умолчанию 4000). Поднимите, если нужен полный текст страницы, а не только начало. / How many characters of text to return (200–50000, default 4000). Raise it if you need the whole page text, not just the beginning.

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so the bar is lower. The description adds genuinely useful non-annotation context: the image consumes significant context budget, and the render-failure fallback returns text with a reduced charge. However, it does not describe the return payload shape beyond categories.

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?

Content is front-loaded (outputs, then when/when-not, then fallback, then cost) with zero filler. The only inefficiency is the full bilingual duplication, which doubles length for no additional semantic content per reader.

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?

Despite having no output schema, the description fully explains what is returned (image + text), the context cost, the degraded-mode behavior, and the credit pricing. Everything an agent needs to call it correctly and reason about cost is present.

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 schema fully documents url and maxChars (range, default, purpose). The description adds no parameter syntax or format detail beyond 'Full page URL' already in the schema, so 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?

States a specific verb + resource (opens a page in a full browser) and precisely enumerates outputs: inline screenshot, full-size file link, and markdown text. It distinguishes itself from siblings read_url and extract by naming what those return instead.

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?

Explicit 'Use when' (need to SEE layout, colours, typography) and 'Do not use when' (only need text -> read_url at 1 credit vs 3; need specific values -> extract). Names the alternatives and the selection condition with cost rationale, leaving nothing to inference.

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

get_usageБаланс, расход и лимиты / Balance, spending and limitsA
Read-onlyIdempotent
Inspect

Баланс, остаток суточной квоты, время сброса окна, burst-лимит и расход за последние сутки и неделю — по услугам, в кредитах. Ответ — компактный JSON (машиночитаемые поля первыми). verbose: true — тот же отчёт человеческим текстом вместе с полным прайс-листом.

Когда: вызов упал с [rate_limited] и надо понять, ждать секунды или до следующих суток; пользователь спрашивает про баланс и расходы; надо сверить свой лог вызовов с нашими списаниями; планируется большой батч. Возвращает: balance_credits, план, quota (used/limit/remaining/reset_min), burst, last24h (calls/credits/free и разбивка by_service) и week_credits. Без verbose прайс-листа в ответе нет — цены каждой услуги описаны у самой услуги, а здесь только то, что меняется от вызова к вызову. Тарификация: платите только за результат — ошибка и вызов, не принёсший ничего (пустая выдача, проверка без прочитанных источников), не списываются. Квота считает ВЫЗОВЫ, а не кредиты: 10 за 10 с и 200 в сутки на ключ. Цена: бесплатно, квоту и лимит запросов этот вызов не расходует — его можно звать без опасений.

Balance, remaining daily quota, window reset time, burst limit and spending for the last 24 hours and the last week, per service, in credits. The answer is compact JSON (machine-readable fields first). verbose: true gives the same report as human-readable text together with the full price list.

Use when: a call failed with [rate_limited] and you need to know whether to wait seconds or until tomorrow; the user asks about balance or spending; you need to reconcile your own call log with our charges; you are about to run a large batch. Returns: balance_credits, plan, quota (used/limit/remaining/reset_min), burst, last24h (calls/credits/free plus a by_service breakdown) and week_credits. Without verbose there is no price list: each service's price is described with that service, and this answer carries only what changes between calls. Billing: you pay for results only — an error, or a call that returned nothing (empty search results, a verification that read no sources), is not charged. The quota counts CALLS, not credits: 10 per 10 s and 200 per day per key. Cost: free — this call consumes neither quota nor rate limit, so call it freely.

ParametersJSON Schema
NameRequiredDescriptionDefault
verboseNotrue — полный человекочитаемый отчёт с прайс-листом всех инструментов. По умолчанию компактный JSON без прайс-листа. / true — the full human-readable report with the price list of every tool. Default is compact JSON without the price list.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: the call is free, consumes no quota or rate limit, and can be called freely. It also discloses billing semantics (only successful results are charged, quota counts calls not credits) and the response structure (compact JSON first, verbose for human-readable text). This goes well beyond the annotations.

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 longer than average but every section earns its place: purpose, when-to-use, return fields, billing semantics, and cost. It is front-loaded with the core purpose and uses clear section labels (Когда/Use when, Возвращает/Returns, Тарификация/Billing, Цена/Cost). The bilingual repetition adds length but serves a multilingual audience; still, it could be trimmed slightly without losing meaning.

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 a read-only usage-reporting tool with one optional parameter and no output schema, the description is complete. It covers what the tool returns, when to use it, how billing works, and that it is free and non-consuming. The absence of an output schema is compensated by the explicit list of returned fields. Nothing an agent needs to call it correctly is missing.

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 100%, so the schema already documents the verbose parameter. The description adds meaning by explaining what verbose: true does (full human-readable report with price list) and what the default is (compact JSON without price list). It also clarifies the response fields, which helps the agent understand the parameter's effect. A small gap: it doesn't explicitly state that verbose is optional, but the schema already marks it as not required.

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: it reports balance, remaining daily quota, window reset time, burst limit, and spending over the last 24 hours and week, per service, in credits. It clearly distinguishes itself from sibling tools like web_search or extract by focusing on account usage and billing data. The bilingual title and description reinforce the purpose without ambiguity.

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?

The description explicitly lists when to use the tool: after a rate_limited error, when the user asks about balance/spending, to reconcile call logs, or before a large batch. It also implies when not to use it by stating that prices are described with each service and that this tool only returns what changes between calls. This is strong contextual routing guidance.

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

mapКарта сайта / Map a siteA
Read-onlyIdempotent
Inspect

Собирает адреса страниц сайта: robots.txt → Sitemap:, затем /sitemap.xml и /sitemap_index.xml (включая вложенные карты), а если карт нет — ссылки со стартовой страницы. Возвращает найденные адреса, их общее число и разбивку по разделам: по ней видно, где на сайте что лежит.

Когда: известен сайт, а не страница — «собрать все события с агрегатора», «какие разделы есть на сайте», «дай мне список страниц для чтения». Когда не: нужен текст страниц — crawl (он читает найденное); нужен ответ по теме без привязки к сайту — web_search. Фильтр search сравнивает подстроку с АДРЕСОМ (страницы мы не читаем), поэтому для русских сайтов указывайте часть латинского пути: search: "organizers" вместо «организаторы». Один вызов читает до 8 карт сайта: если сайт отдаёт больше, в ответе это сказано, а разделы показывают, куда идти дальше. Возвращает: pages (до limit адресов), total (сколько нашлось всего), sections (разделы с числом адресов), source (sitemap или links) и outcome: ok, blocked (сайт отвечает 403 — это не «страниц нет»), unreachable, empty. Цена: 1 кредит за каждые 10 возвращённых адресов, минимум 1 (200 адресов — 20 кредитов). Сайт, который нас не пустил, не тарифицируется: результата нет.

Collects a site's page URLs: robots.txt → Sitemap:, then /sitemap.xml and /sitemap_index.xml (including nested maps), and the start page's links when there are no maps. Returns the URLs, the total count, and a breakdown by section, which shows what lives where.

Use when: you know the site, not the page — "collect every event from this aggregator", "what sections does this site have", "give me the URLs to walk". Do not use when: you need the page text — crawl (it reads what map found); you need an answer about a topic — web_search. The search filter matches against the URL (map does not read pages), so for Russian sites pass part of the Latin path: search: "organizers". One call reads up to 8 sitemaps: if the site offers more, the answer says so, and sections show where to go next. Returns: pages (up to limit URLs), total (all found), sections (sections with URL counts), source (sitemap or links) and outcome: ok, blocked (the site answers 403 — that is not "no pages"), unreachable, empty. Cost: 1 credit per 10 URLs returned, minimum 1 (200 URLs — 20 credits). A site that blocks us is not charged: there is no result.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesСайт или страница (http/https) / Site or page URL
limitNoСколько адресов вернуть (1–200, по умолчанию 50). total показывает, сколько нашлось всего. / How many URLs to return (1–200, default 50). total shows how many were found.
searchNoОставить адреса, содержащие эту подстроку (регистр и «ё» не важны; слова через пробел ищутся по отдельности). Фильтр по адресу, не по тексту страницы. / Keep URLs containing this substring (case- and ё-insensitive; space-separated words are matched individually). It filters URLs, not page text.
selectPathsNoОставить только адреса, содержащие любую из этих подстрок (по одной на элемент). Так целятся в раздел: selectPaths: ["organizers"] на агрегаторе событий оставит 3565 адресов организаторов вместо служебных страниц. / Keep only URLs containing any of these substrings (one per item). This is how you aim at a section.
excludePathsNoВыбросить адреса, содержащие любую из этих подстрок: архивы, теги, служебные разделы. / Drop URLs containing any of these substrings: archives, tags, service sections.
includeSubdomainsNoСчитать своими и поддомены (по умолчанию только тот же хост). / Treat subdomains as own (by default only the same host).

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), it discloses the 8-sitemap-per-call cap, the outcome vocabulary (ok, blocked, unreachable, empty), that blocked sites are not charged, and the credit cost model (1 credit per 10 URLs, min 1). These are behavioral traits the annotations cannot convey.

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?

Well front-loaded and organized (what → when/when-not → filter caveat → returns → cost), but the fully duplicated Russian/English text roughly doubles the length, which is dilution even if intentional for the audience.

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?

No output schema, so the description carries return values (pages, total, sections, source, outcome) and does so completely, including the blocked-site edge case and the pricing rule. Nothing needed to invoke it correctly is missing.

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. The description adds practical value the schema lacks: the warning that search matches the URL, not page text, and the concrete tip to use Latin path fragments ('organizers') for Russian sites. The remaining param explanation largely restates the schema.

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 concrete verb and resource: collects a site's page URLs via robots.txt/Sitemap, sitemap.xml, sitemap_index.xml, or start-page links. It names sibling tools (crawl, web_search) and makes the site-vs-page distinction explicit, so an agent can separate it from crawl without opening either 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?

Has dedicated 'Use when' and 'Do not use when' sections with concrete example prompts, and explicitly routes page-text needs to crawl and topic needs to web_search. Nothing is left to inference.

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

read_urlПрочитать страницу / Read a pageA
Read-onlyIdempotent
Inspect

Открывает одну страницу по известному адресу и возвращает её текст чистым markdown — без навигации, рекламы, скриптов и HTML. JavaScript выполняется на нашей стороне, поэтому SPA тоже читаются.

Когда: адрес известен и нужен текст — статья, документация, карточка товара. Когда не: адреса нет — сначала web_search; страниц несколько — read_urls (один вызов вместо пяти); нужны 2–5 конкретных полей — extract (в контекст придут только они); нужно увидеть вёрстку — fetch_page. Возвращает: заголовок и текст, по умолчанию первые 4000 символов. Длинная страница приходит по частям: в конце ответа указано значение offset, с которым надо вызвать тул повторно, чтобы получить продолжение. Так документ любого объёма читается окнами под ваш контекст, без повторной оплаты уже прочитанного. Цена: 1 кредит, самый дешёвый способ получить содержимое страницы (fetch_page — 3).

Opens a single page by a known URL and returns its text as clean markdown — no navigation, ads, scripts or HTML. JavaScript is executed on our side, so SPAs read fine too.

Use when: you have the URL and need the text — an article, documentation, a product page. Do not use when: you have no URL — start with web_search; you have several pages — read_urls (one call instead of five); you need a handful of specific fields — extract (only those reach your context); you need to see the layout — fetch_page. Returns: title and text, the first 4000 characters by default. A long page arrives in windows: the end of the response states the offset to call the tool with again to get the continuation. That way a document of any size is read in windows sized to your context, without paying twice for what you already read. Cost: 1 credit — the cheapest way to get page content (fetch_page costs 3).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesПолный URL страницы (http/https) / Full page URL
freshNoПрочитать страницу заново, не беря недавно прочитанный текст. Нужно, когда страница только что изменилась. На цену не влияет: кредит списывается в любом случае. / Read the page anew instead of using recently read text. Use it when the page has just changed. Does not affect the price: the credit is charged either way.
engineNoКак забирать страницу: auto (по умолчанию — начинает с быстрого способа и сам поднимается, если текста не оказалось), fast (быстро, для статики и документации), dynamic (ждёт отрисовки JS — для SPA), stealth (медленно, максимально браузерное поведение). Указывайте явно только если знаете сайт. / How to fetch the page: auto (default — starts with the fast path and escalates on its own if no text came back), fast (static sites and docs), dynamic (waits for JS rendering — for SPAs), stealth (slow, most browser-like). Set it explicitly only if you know the site.
offsetNoС какого символа продолжить чтение. Берите значение из предыдущего ответа этого тула («продолжить: offset N»), не считайте сами. Пусто — с начала страницы. / Where to resume reading. Take the value from this tool's previous response ("continue: offset N"), do not compute it yourself. Empty — from the start of the page.
maxCharsNoСколько символов текста вернуть (200–50000, по умолчанию 4000). Поднимите, если нужен полный текст, а не только начало. / How many characters of text to return (200–50000, default 4000). Raise it if you need the whole text, not just the beginning.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses practical behaviors: JavaScript execution server-side (SPA support), pagination via offset with continuation, default 4000-character return, cost of 1 credit, and caching/refresh behavior via the 'fresh' parameter. These details add substantial value and do not contradict annotations.

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 bilingual (RU/EN), making it longer, but each section (description, usage, returns, cost) is purpose-driven and clearly structured. It is front-loaded with the core purpose. The length is justified by the density of actionable guidance, though a single-language version could be more concise.

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 no output schema, the description compensates by explaining the return shape (title, text, offset), pagination windows, and default truncation. It also covers cost implications and engine behavior, providing a complete understanding of how the tool behaves in various scenarios.

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 has 100% coverage with parameter descriptions, so the baseline is 3, but the description adds essential operational nuances: offset must be taken from the previous response rather than computed manually, and engine modes are clarified with examples. This goes beyond the schema's basic definitions.

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 explicitly states 'Opens a single page by a known URL and returns its text as clean markdown' — a specific verb, resource, and output format. It also distinguishes itself from sibling tools like read_urls (multiple pages), extract (specific fields), and fetch_page (layout).

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' and 'Do not use when' conditions, naming alternatives: web_search when no URL, read_urls for multiple pages, extract for specific fields, and fetch_page for layout. Also notes cost comparison with fetch_page, giving clear decision guidance.

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

read_urlsПрочитать несколько страниц / Read several pagesA
Read-onlyIdempotent
Inspect

Читает пачку страниц (до 5 за вызов) параллельно и возвращает текст каждой чистым markdown. То же, что read_url, но одним вызовом вместо нескольких — заметно быстрее по общему времени.

Когда: на руках список ссылок, например топ выдачи web_search. Когда не: страница одна — read_url; нужны отдельные поля, а не текст, — extract (он тоже принимает список). Возвращает: текст по каждой странице. Частичный успех — норма: упавшие ссылки не рвут вызов, а перечисляются отдельным блоком «Не прочитано» с кодом ошибки. Дубликаты и ссылки сверх лимита отбрасываются, их число указано в ответе. Длинные страницы обрезаются по maxChars; дочитывать их удобнее по одной через read_url с offset — в батче offset один на все ссылки. Цена: 1 кредит за каждую ссылку — пять страниц стоят пять кредитов. Не отправляйте ссылки «на всякий случай».

Reads a batch of pages (up to 5 per call) in parallel and returns each one's text as clean markdown. Same as read_url but in a single call — markedly faster in total wall-clock.

Use when: you have a list of links, e.g. the top web_search results. Do not use when: there is only one page — read_url; you need specific fields rather than text — extract (it also accepts a list). Returns: text per page. Partial success is normal: failed links do not fail the call, they are listed in a separate "not read" block with an error code. Duplicates and links beyond the limit are dropped and the count is reported. Long pages are cut at maxChars; finish reading them one at a time via read_url with offset — in a batch the offset applies to every link at once. Cost: 1 credit per link — five pages cost five credits. Do not pad the list.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsYesСписок URL (1–5). Дубликаты отбрасываются. / A list of URLs (1–5). Duplicates are dropped.
freshNoЧитать все страницы батча заново, не беря недавно прочитанный текст. На цену не влияет. / Read every page in the batch anew instead of using recently read text. Does not affect the price.
engineNoКак забирать страницы: auto (по умолчанию), fast, dynamic, stealth. Применяется ко всем ссылкам батча. / How to fetch the pages: auto (default), fast, dynamic, stealth. Applies to every link in the batch.
maxCharsNoСколько символов текста вернуть с КАЖДОЙ страницы (200–50000, по умолчанию 4000). На батче ставьте скромнее: пять больших страниц вытеснят из контекста всё остальное. / How many characters to return from EACH page (200–50000, default 4000). Keep it modest on a batch: five large pages will crowd everything else out of your context.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive; the description adds important behavioral facts: partial success with a 'Не прочитано' block and error codes, duplicate/over-limit dropping with reported counts, maxChars truncation, batch-wide offset semantics, and per-link credit cost. No contradiction with annotations.

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 well-organized and front-loaded with purpose, then usage, returns, and cost. However, the full RU and EN duplication makes it longer than necessary, even though each section is information-dense.

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 the tool's complexity and no output schema, the description covers return shape (text per page), failure behavior, truncation, duplicates, cost, and usage boundaries. This is sufficient for an agent to select and invoke the tool correctly.

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 a baseline of 3 applies. The description mostly restates schema info (duplicates, maxChars batch caveat) and adds tool-level behavioral details (cost, offset) rather than new parameter semantics, so it doesn't elevate the score.

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 action ('Читает пачку страниц... возвращает текст каждой чистым markdown'), identifies the batching capability, and explicitly distinguishes itself from read_url and extract. This is a clear verb+resource+scope statement.

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?

It provides explicit when-to-use ('когда на руках список ссылок') and when-not-to-use alternatives (read_url for a single page, extract for structured fields). It also adds practical cost guidance ('не отправляйте ссылки на всякий случай').

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

verify_claimПроверить утверждение по источникам / Verify a claim against sourcesA
Read-onlyIdempotent
Inspect

Проверяет утверждение: ищет источники, читает несколько независимых страниц и возвращает вердикт с дословными цитатами. Каждая цитата сверена с текстом страницы — не найденная в тексте отбрасывается вместе со своим доводом.

Когда: факт, который нельзя брать на веру — цифра, дата, «X поддерживает Y», утверждение из ответа пользователя или из вашей же памяти. Особенно если ваш контекст не вмещает 4–5 страниц целиком: вся черновая работа делается на нашей стороне, к вам приходят только вердикт и цитаты. Когда не: нужен обзор темы — deep_research; нужен текст конкретной страницы — read_url. Вердикт: supported — источники подтверждают; refuted — опровергают; mixed — расходятся между собой; unverified — подтверждения не нашлось. Последние два — нормальный результат, а не ошибка: значит, утверждение нельзя считать проверенным. Считает в независимых доменах: три цитаты с одного сайта — один голос. Смотрите agreeing/disagreeing и confidence, а не только вердикт. Если сайт не открылся, слот не теряется: берём следующего кандидата из выдачи, поэтому прочитанных источников обычно ровно столько, сколько вы заказали. Когда проверка всё же вышла неполной, это сказано в вердикте и в caveats. Возвращает: вердикт, уверенность, цитаты со ссылками и оговорки. Источников — 2–5. Время: 15–60 с / 15–60 s. Цена: 8 кредитов (поиск, чтение источников и работа модели).

Verifies a statement: searches for sources, reads several independent pages and returns a verdict with verbatim quotes. Every quote is checked against the page text — one that is not found there is dropped along with its argument.

Use when: a fact you should not take on trust — a number, a date, "X supports Y", a claim from the user or from your own memory. Especially when your context cannot hold 4–5 pages at once: the legwork happens on our side, you receive only the verdict and the quotes. Do not use when: you need an overview of a topic — deep_research; you need the text of one specific page — read_url. Verdict: supported — the sources confirm it; refuted — they contradict it; mixed — they disagree with each other; unverified — no confirmation was found. The last two are normal outcomes, not errors: they mean the claim cannot be treated as verified. Counted in independent domains: three quotes from one site are one voice. Read agreeing/disagreeing and confidence, not just the verdict. If a site does not open, the slot is not lost: the next candidate from the search results is read instead, so you usually get exactly the number of sources you asked for. When the check still came out incomplete, the verdict and the caveats say so. Returns: verdict, confidence, quotes with links and caveats. Sources: 2–5. Time: 15–60 с / 15–60 s. Cost: 8 credits (search, source reading and model work).

ParametersJSON Schema
NameRequiredDescriptionDefault
claimYesУтверждение одной фразой, как проверяемый факт: «Node.js 22 — LTS», «ставка НДС для IT-услуг в России 20%». Не вопрос и не тема: чем конкретнее формулировка, тем точнее проверка. / The statement as a single sentence, phrased as a checkable fact: "Node.js 22 is LTS". Not a question and not a topic: the more specific the wording, the sharper the check.
queryNoСвой поисковый запрос, если утверждение плохо ищется как есть (длинное, со сленгом). По умолчанию ищем по тексту утверждения. / A custom search query when the claim searches poorly as written (long, slangy). By default the claim text itself is the query.
languageNoЯзык поиска источников / Source search language: auto, ru, en
timeRangeNoСвежесть источников — для утверждений, которые могли устареть (цены, версии, должности): all, day, week, month, year. / Source recency — for claims that may have gone stale (prices, versions, job titles): all, day, week, month, year.
maxSourcesNoСколько независимых источников читать (2–5, по умолчанию 4). Меньше — быстрее, больше — надёжнее. На цену не влияет. / How many independent sources to read (2–5, default 4). Fewer is faster, more is sturdier. Does not affect the price.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, open-world, non-destructive, but the description adds substantial context beyond them: quote-against-page-text verification with dropped quotes, the four verdict values and their meaning, independent-domain counting, slot replacement when a site fails to open, incompleteness surfacing in caveats, source count, latency (15–60s) and cost (8 credits).

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?

Content is dense and well front-loaded with labeled blocks (verdict list, when/when-not, returns, time, cost), so scanning is easy. However, the entire text is duplicated in Russian and English, roughly doubling length without adding information for any single reader, which is the one structural inefficiency.

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 no output schema, the description carries the full burden of explaining returns and does so: verdict, confidence, quotes with links, agreeing/disagreeing, and caveats, plus the semantics of mixed and unverified outcomes. Nothing an agent needs to interpret the result is 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 every parameter (claim, query, language, timeRange, maxSources) is already documented in the schema with enums and default values. The description only restates the 2–5 source range consistent with maxSources and adds cost/latency context; per the high-coverage baseline this is a 3.

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: it verifies a claim by searching sources, reading several independent pages, and returning a verdict with verbatim quotes. It explicitly distinguishes itself from siblings by naming deep_research and read_url as the tools for adjacent needs. An agent can tell what this does without opening the 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?

Has explicit 'Use when' (a fact that must not be taken on trust; context too small to hold 4–5 pages) and 'Do not use when' (topic overview → deep_research; single page text → read_url) sections. Sibling routing is unambiguous, which is exactly what is needed in a crowded toolset.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedcrawl1 field changed
      • changedInput schema / properties / selectPaths / description
        Previous value: -"Читать только страницы, адрес которых содержит любую из этих подстрок — это и есть прицельный обход раздела. Без него crawl читает первые адреса карты, а у агрегаторов это служебные страницы, а не события. / Read only pages whose URL contains any of these substrings — this is how you target a section. Without it crawl reads the first URLs of the map, which on aggregators are service pages, not events."New value: +"Читать только страницы, адрес которых содержит любую из этих подстрок — это и есть прицельное чтение раздела. Без него crawl читает первые адреса карты, а у агрегаторов это служебные страницы, а не события. / Read only pages whose URL contains any of these substrings — this is how you target a section. Without it crawl reads the first URLs of the map, which on aggregators are service pages, not events."
  2. 2 tool updates
    • Addedcrawl
    • Addedmap
  3. 1 tool update
    • Changedweb_search1 field changed
      • changedInput schema / properties / excerpts / description
        Previous value: -"Забрать реальный текст топ-страниц под запрос (медленнее на пару секунд, но даёт готовый контент для ответа без доп. переходов). По умолчанию выкл. / Pull the actual text of the top pages for this query (a couple of seconds slower, but gives ready content without extra calls). Off by default."New value: +"Забрать реальный текст топ-страниц под запрос (+3–10 с: страницы читаются параллельно, потолок — таймаут страницы). По умолчанию выкл. / Pull the actual text of the top pages for this query (+3–10 s: pages are read in parallel, per-page timeout caps it). Off by default."
  4. 1 tool update
    • Changedweb_search5 fields changed
      • addedInput schema / properties / chunksPerSource
        Added value: +{
+  "description": "Сколько кусков текста вернуть на каждый из топ-4 результатов (0–5, по умолчанию 0). Куски вырезаны из страницы по релевантности запросу и ранжированы: один вызов даёт контекст, за которым иначе пришлось бы идти read_url. Цена вызова не меняется. / How many text chunks to return per top-4 result (0–5, default 0). Chunks are cut from the page by query relevance and ranked, so one call carries the context you would otherwise fetch with read_url. The call price does not change.",
+  "maximum": 5,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / includeRawContent
        Added value: +{
+  "description": "Вернуть полный текст страницы для топ-4 результатов (до 20 000 символов на каждый) — замена отдельному чтению. По умолчанию выкл. Осторожно с num: это десятки тысяч токенов, берите 1–3 результата. / Return the full page text for the top-4 results (up to 20 000 chars each) instead of fetching pages separately. Off by default. Mind num: this is tens of thousands of tokens, ask for 1–3 results.",
+  "type": "boolean"
+}
      • addedInput schema / properties / publishedAfter
        Added value: +{
+  "description": "Нижняя граница даты публикации, YYYY-MM-DD включительно. Сильнее timeRange, если заданы обе. / Publication date lower bound, YYYY-MM-DD inclusive. Overrides timeRange when both are given.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}
      • addedInput schema / properties / publishedBefore
        Added value: +{
+  "description": "Верхняя граница даты публикации, YYYY-MM-DD включительно. / Publication date upper bound, YYYY-MM-DD inclusive.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}
      • changedInput schema / properties / timeRange / description
        Previous value: -"Свежесть / Recency: all, day, week, month, year"New value: +"Свежесть по дате публикации: day, week, month, year — окно от сегодняшнего дня (1/7/30/365 дней), all (по умолчанию) — без ограничения. Фильтр применяем мы, а не движок: страницы без даты публикации в окно не проходят, и в ответе написано, сколько таких отброшено. / Freshness by publication date: day, week, month, year — a window from today (1/7/30/365 days), all (default) means no limit. The filter is applied by us, not by the engine: pages without a publication date do not pass, and the answer states how many were dropped."
  5. 1 tool update
    • Changedget_usage2 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / verbose
        Added value: +{
+  "description": "true — полный человекочитаемый отчёт с прайс-листом всех инструментов. По умолчанию компактный JSON без прайс-листа. / true — the full human-readable report with the price list of every tool. Default is compact JSON without the price list.",
+  "type": "boolean"
+}
  6. 1 tool update
    • Changedanswer_search6 fields changed
      • addedInput schema / properties / depth / default
        Added value: +"balanced"
      • changedInput schema / properties / depth / description
        Previous value: -"Глубина поиска / Search depth: fast=2 pages, balanced=5, deep=10"New value: +"Глубина: fast (2 страницы), balanced (5 страниц, по умолчанию), deep (10 страниц). Больше страниц — выше качество, дольше время. / Depth: fast (2 pages), balanced (5 pages, default), deep (10 pages). More pages = higher quality, longer time."
      • addedInput schema / properties / language / default
        Added value: +"auto"
      • changedInput schema / properties / language / description
        Previous value: -"Язык поиска / Search language (default: auto)"New value: +"Язык поиска и ответа / Search and answer language: auto, ru, en"
      • changedInput schema / properties / query / description
        Previous value: -"Вопрос или задача / Question or search task"New value: +"Вопрос или поисковый запрос / Question or search query"
      • changedInput schema / properties / query / maxLength
        Previous value: -500New value: +2000
  7. 1 tool update
    • Addedanswer_search
  8. 1 tool update
    • Removedanswer_search
  9. 1 tool update
    • Addedanswer_search
  10. 1 tool update
    • Changeddeep_research1 field changed
      • changedInput schema / properties / ticket / type
        Previous value: -"string"New value: +[
+  "string",
+  "number"
+]
  11. 1 tool update
    • Changeddeep_research4 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"
-]
  12. 3 tool updates
    • Changedimage_search1 field changed
      • changedInput schema / properties / timeRange / description
        Previous value: -"Свежесть / Recency: '', day, week, month, year"New value: +"Свежесть / Recency: all, day, week, month, year"
    • Changedverify_claim1 field changed
      • changedInput schema / properties / timeRange / description
        Previous value: -"Свежесть источников — для утверждений, которые могли устареть (цены, версии, должности): '', day, week, month, year. / Source recency — for claims that may have gone stale (prices, versions, job titles): '', day, week, month, year."New value: +"Свежесть источников — для утверждений, которые могли устареть (цены, версии, должности): all, day, week, month, year. / Source recency — for claims that may have gone stale (prices, versions, job titles): all, day, week, month, year."
    • Changedweb_search1 field changed
      • changedInput schema / properties / timeRange / description
        Previous value: -"Свежесть / Recency: '', day, week, month, year"New value: +"Свежесть / Recency: all, day, week, month, year"
  13. 3 tool updates
    • Changedimage_search1 field changed
      • changedInput schema / properties / timeRange / enum
        Previous value: -[
-  "",
-  "day",
-  "week",
-  "month",
-  "year"
-]New value: +[
+  "all",
+  "day",
+  "week",
+  "month",
+  "year"
+]
    • Changedverify_claim1 field changed
      • changedInput schema / properties / timeRange / enum
        Previous value: -[
-  "",
-  "day",
-  "week",
-  "month",
-  "year"
-]New value: +[
+  "all",
+  "day",
+  "week",
+  "month",
+  "year"
+]
    • Changedweb_search1 field changed
      • changedInput schema / properties / timeRange / enum
        Previous value: -[
-  "",
-  "day",
-  "week",
-  "month",
-  "year"
-]New value: +[
+  "all",
+  "day",
+  "week",
+  "month",
+  "year"
+]

Related MCP Connectors

Related MCP Servers

Try in Browser
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources