срезAI: веб-поиск, страницы и субтитры видео — 13 инструментов. Thirteen web tools for AI agents
Scored across 13 tools
Every tool carries an explicit 'when to use / when not to use' section that names the neighboring tools it could be confused with (web_search vs read_url vs extract vs deep_research vs answer_search, read_url vs read_urls vs crawl vs fetch_page). The answer-synthesis cluster (answer_search, deep_research, verify_claim) is the only place with real conceptual overlap, but the descriptions clearly separate single-pass RAG, multi-step research, and claim verification. An agent can reliably pick the right tool.
Names are uniformly snake_case (answer_search, read_url, read_urls, web_search, deep_research, verify_claim, fetch_page, get_usage, image_search, yt_srt), with only three bare single-word verbs (crawl, extract, map). The convention is consistent and readable throughout, with minor deviation only in the single-word names.
13 tools is well-scoped for a web research/search API: search, read, batch read, crawl, map, extract, screenshot, image search, video captions, verification, research, and usage. Each tool covers a distinct capability and none feels redundant padding.
The surface covers the full research lifecycle: discovery (web_search, image_search), navigation (map, crawl), reading (read_url, read_urls, extract, fetch_page), synthesis (answer_search, deep_research), verification (verify_claim), plus media (yt_srt) and account introspection (get_usage). As a read-only API, CRUD gaps are not applicable; minor gaps remain (e.g. no dedicated news/date-scoped endpoint, no playlist handling) but they are workable around.
Полный RAG-цикл: поиск источников, семантическое ранжирование через BGE-reranker-v2-m3, чтение релевантных страниц и синтез финального ответа. Возвращает готовый ответ с указанием релевантности каждого источника (0-1).
Когда: нужен итоговый ответ на вопрос, а не список ссылок. Лучше web_search + read_url, когда требуется интерпретация и синтез по нескольким источникам. Конвейер: переформулировка запроса → параллельный поиск → BGE-reranker отбирает топ → чтение страниц → синтез ответа. Возвращает: текст ответа + sources (каждый с relevance, chars_read, read_success). Источники всегда отсортированы по убыванию relevance. Цена зависит от depth: fast - 3 кредита, balanced - 5 кредитов, deep - 10 кредитов.
Full RAG cycle: search, semantic reranking via BGE-reranker-v2-m3, page reading, answer synthesis. Returns a ready answer with relevance scores (0-1) for each source.
Use when: you need a final answer, not a list of links. Better than web_search + read_url when interpretation and synthesis across sources is required. Pipeline: query rewriting → parallel search → BGE-reranker picks top results → page reading → answer synthesis. Returns: answer text + sources (each with relevance, chars_read, read_success). Sources are always sorted by descending relevance. Cost depends on depth: fast - 3 credits, balanced - 5 credits, deep - 10 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Глубина: fast (2 страницы), balanced (5 страниц, по умолчанию), deep (10 страниц). Больше страниц - выше качество, дольше время. / Depth: fast (2 pages), balanced (5 pages, default), deep (10 pages). More pages = higher quality, longer time. | balanced |
| query | Yes | Вопрос или поисковый запрос / Question or search query | |
| language | No | Язык поиска и ответа / Search and answer language: auto, ru, en | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent=false/destructive=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the five-stage pipeline, the fact that sources are always sorted by descending relevance, and a per-depth credit cost table. It does not mention latency, caching, or failure modes, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is well front-loaded into labeled sections (When, Pipeline, Returns, Cost), but the entire description is duplicated verbatim in Russian and English, roughly doubling the token footprint with zero added information for a given reader.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully carries the return-value burden, describing the answer text plus sources with relevance, chars_read, and read_success, and stating the sort order. Nothing an agent needs to call or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters and enum values, giving a baseline of 3. The description adds value by mapping each depth value to a credit cost (fast 3, balanced 5, deep 10), which is not in the schema and directly informs parameter choice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Полный RAG-цикл: поиск... синтез финального ответа') and explicitly names the sibling alternatives ('Лучше web_search + read_url'), so an agent can distinguish it from the link-returning tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit when clause ('нужен итоговый ответ на вопрос, а не список ссылок') plus the condition that selects the alternative ('когда требуется интерпретация и синтез по нескольким источникам'). Both the trigger and the exclusion are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Читает разделы сайта и читает найденные страницы: сначала карта адресов (как в 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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Сайт или страница (http/https) / Site or page URL | |
| limit | No | Сколько страниц прочитать (1-20, по умолчанию 5). / How many pages to read (1-20, default 5). | |
| intent | No | Задача клиента словами: «страницы организаторов конференций», «все события», "только вакансии". Адреса карты упорядочиваются по смыслу, и читаются первые `limit` - так прицельное чтение работает там, где у нужных страниц нет общего фрагмента пути и `selectPaths` не находит ничего (замер 03.10.2026: 0/4 у подстроки против 4/4 в первых строках у отбора по смыслу). Работает, только если на сервере включён JEV_INTENT. / Plain-language goal for the section. The URL list is ranked by meaning and the first `limit` pages are read - use it when selectPaths finds nothing because the wanted pages share no common path fragment. Ignored unless enabled server-side. | |
| search | No | Оставить страницы, в тексте или заголовке которых есть эти слова (фильтр по СОДЕРЖИМОМУ прочитанного). / Keep pages whose text or title contains these words (a filter over the CONTENT read). | |
| selectPaths | No | Читать только страницы, адрес которых содержит любую из этих подстрок - это и есть прицельное чтение раздела. Без него 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. | |
| excludePaths | No | Не читать страницы, чей адрес содержит любую из этих подстрок. / Do not read pages whose URL contains any of these substrings. | |
| includeSubdomains | No | Считать своими и поддомены. / Treat subdomains as own. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description still adds real operational context: partial failures do not abort the crawl (skipped URLs are returned with a reason), text is truncated at 20,000 chars per page, and a full credit model is disclosed. It stops short of describing pagination or map-vs-crawl duplication behavior, but the coverage is well above the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage, then parameter interplay, returns, and cost - a sensible order with no filler sentences. The one cost is that the entire text is duplicated in Russian and English, roughly doubling the token footprint for a single agent; the structure is otherwise tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description closes every gap: it defines the return shape (pages with URL/title/text, plus skipped with reasons), partial-failure behavior, truncation limits, the server-side flag gating intent, and the exact cost formula.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds genuine cross-parameter semantics the schema does not: search filters over page TEXT/title while selectPaths/excludePaths filter over URLs, and intent ranks the map by meaning and only works when JEV_INTENT is enabled server-side. This interaction guidance is exactly what the schema cannot express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific compound verb+resource: it builds the URL map then reads page text, returning whole sections rather than single pages. It explicitly names and contrasts the two nearest siblings (map for URLs only, read_url for one page), so an agent can disambiguate 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when ('collect every event from this aggregator', 'read this docs section') and when-not ('only need the list of URLs - map', 'need one page - read_url'), plus a recommended ordering: map first to see structure, then crawl with selectPaths, then search over text. 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.
Проводит многошаговое исследование: сам формулирует запросы, ищет, читает источники и возвращает готовый связный ответ со ссылками на использованные страницы.
Когда: вопрос требует сопоставления нескольких источников и вывода - «сравни», «разберись», «что известно о». Когда не: нужен один факт или список ссылок - это 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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Вопрос или тема исследования. Обязателен для НОВОГО исследования; при дозаборе по ticket не нужен. / The question or research topic. Required to START research; omit it when polling by ticket. | |
| ticket | No | Талон незавершённой задачи из прошлого ответа `[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. |
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.
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.
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.
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.
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.
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.
Читает страницу и возвращает JSON строго по вашей схеме: только запрошенные поля, без текста страницы. Чего на странице нет - приходит null, значения не домысливаются.
Когда: нужны 2-5 конкретных значений - цена, характеристики, автор и дата, список вакансий. Экономит контекст: вместо всей страницы придут только поля. Когда не: нужен связный текст или вы не знаете заранее, что искать, - read_url (и в 4 раза дешевле). Схема: принимается и сокращённая форма - {"title":"string","price":"number?"}, где «?» делает поле необязательным, а «[]» - массивом; полный JSON Schema тоже работает. Описания полей заметно повышают точность разбора. Возвращает: объект по схеме на каждую ссылку. Можно передать до 10 ссылок разом (на бесплатном тарифе до 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 10 links per call (5 on the free tier), one schema applied to all. Cost: 2 credits per link (page read plus model parsing).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL страницы (http/https) / Page URL (http/https) | |
| urls | No | Список URL (1-10) вместо url - одна схема на все страницы. Лишнее отбрасывается по тарифу: на бесплатном берём 5, на платном больше. Каждая страница тарифицируется отдельно. / A list of URLs (1-10) instead of url - one schema for all pages; the rest is cut by plan (5 on the free tier). Each page is billed separately. | |
| engine | No | Как забирать страницу: auto (по умолчанию), fast, dynamic, stealth. / How to fetch the page: auto (default), fast, dynamic, stealth. | |
| schema | No | Схема результата. Проще всего - сокращённая форма: {"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. | |
| instruction | No | Уточнение для разбора, если из схемы неочевидно: «бери цену со скидкой», «только вакансии удалённо». / A parsing hint when the schema alone is ambiguous: «use the discounted price», «remote positions only». |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, openWorld, non-destructive), and the description goes further with genuinely non-derivable behavior: absent fields return null rather than being invented, batching limits (10 links, 5 on free tier), and per-link billing of 2 credits. That is exactly the added context annotations cannot provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every block (purpose, when/when-not, schema, returns, cost) is front-loaded and earns its place, with no filler. The one cost is full bilingual duplication, which roughly doubles the text for the same information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return-value burden and does so ('one object per link, shaped by your schema'). Combined with the schema-grammar guidance, null semantics, batching cap and billing, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 earns an extra point by explaining the shorthand schema grammar ('?' for optional, '[]' for array), confirming full JSON Schema is accepted, and noting that field descriptions improve extraction accuracy, plus how `instruction` resolves schema ambiguity. It does duplicate some of what the schema already states, which keeps it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource pair: it reads a page and returns JSON constrained to the caller's schema, explicitly excluding page text. It also names the sibling it is not (read_url) and the trade-off between them, so an agent can distinguish it from fetch_page/read_url/crawl without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit "Use when" (2-5 concrete values: price, specs, author/date, job listings) and an explicit "Do not use when" (prose needed, or you don't know what to look for) with the alternative read_url named and a cost ratio given. 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.
Открывает страницу полноценным браузером и возвращает скриншот картинкой прямо в ответе, ссылку на полноразмерный файл и текст страницы в 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).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Полный URL страницы (http/https) / Full page URL (http/https) | |
| maxChars | No | Сколько символов текста вернуть (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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new operational context: the cost (3 credits), the fallback path when rendering fails (text returned, 1 credit instead of 3), and the warning that the inline image consumes significant context. This is exactly the behavioural disclosure 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Sentences are front-loaded and each carries distinct information (purpose, when/when-not, return shape, fallback, price). It is somewhat inflated by the full Russian/English duplication, which roughly doubles the length without adding information, but the content itself is waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully carries the return contract — image plus full-size link plus markdown text — and even explains the degraded return when rendering fails. An agent has everything needed to decide and to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both url and maxChars are already fully documented in the schema, including the 200-50000 range and default. The description adds nothing parameter-specific — it never mentions maxChars or text-length truncation — so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource — 'opens the page in a full browser' — and enumerates exactly what comes back: an inline screenshot image, a link to the full-size file, and page text in markdown. It is clearly distinguishable from read_url and extract 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit 'when' (visual inspection of layout, colours, typography) and an explicit 'when not', naming the two alternatives by name and the condition that selects each: read_url for text only, extract for specific values. It even quantifies the tradeoff in credits and speed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Баланс, остаток суточной квоты, время сброса окна, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | true - полный человекочитаемый отчёт с прайс-листом всех инструментов. По умолчанию компактный JSON без прайс-листа. / true - the full human-readable report with the price list of every tool. Default is compact JSON without the price list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses the billing model (pay-for-results, errors and empty calls not charged), that the quota counts CALLS not credits with concrete numbers (10/10s, 200/day), and that this call is free and consumes neither quota nor rate limit. That is exactly the kind of behavioral context an agent needs before deciding to poll it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place and the payload is front-loaded: what it returns, then when to use it, then the return shape, then billing and cost. The one deduction is for full duplication in Russian and English, which roughly doubles the token cost without adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully compensates by enumerating the returned fields (balance_credits, plan, quota with used/limit/remaining/reset_min, burst, last24h with by_service breakdown, week_credits). An agent knows exactly what it will get back and how verbose changes it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning beyond the schema: it explains that verbose swaps compact machine-readable JSON (fields first) for human-readable text bundled with the full price list, and explicitly notes the price list is absent without verbose. That clarifies the trade-off the parameter controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the exact resource (balance, remaining daily quota, window reset time, burst limit, spending per service in credits) and the output format. Nothing here overlaps with the sibling search/crawl/verify tools, so it is trivially distinguishable from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use when' block gives four concrete triggers: a call failing with [rate_limited], a user asking about balance/spending, reconciling a call log against charges, and planning a large batch. That is explicit when-to-use guidance with no ambiguity, and no alternative tool competes for these scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ищет изображения по текстовому запросу и возвращает прямые ссылки на файлы, страницу-источник и разрешение.
Когда: нужны картинки, фотографии, логотипы, схемы. Когда не: нужен текст или факты - web_search; нужно увидеть, как выглядит конкретная страница, - fetch_page. Возвращает: только ссылки и метаданные - файлы не скачиваются и в ответе не появляются. Ставьте num: 1-3, если картинка нужна одна: по умолчанию 12, максимум 48, и полный список занимает десятки килобайт контекста. Цена: 1 кредит за вызов, независимо от num.
Searches for images by a text query and returns direct file links, the source page and resolution.
Use when: you need pictures, photos, logos or diagrams. Do not use when: you need text or facts - web_search; you need to see what a specific page looks like - fetch_page. Returns: links and metadata only - files are never downloaded or embedded in the response. Pass num: 1-3 when you need a single image: the default is 12, the maximum 48, and a full list costs tens of kilobytes of context. Cost: 1 credit per call regardless of num.
| Name | Required | Description | Default |
|---|---|---|---|
| num | No | Сколько картинок вернуть (1-48, по умолчанию 12). Нужна одна картинка - просите 1-3, не тратьте контекст. / How many images to return (1-48, default 12). Need just one - ask for 1-3 and save context. | |
| safe | No | Безопасный поиск / Safe search (on by default) | |
| query | Yes | Что искать / What to search for | |
| timeRange | No | Свежесть / Recency: all, day, week, month, year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses that files are never downloaded or embedded, that the default is 12 results and the max 48, that a full list costs tens of kilobytes of context, and that each call costs 1 credit regardless of num. This is exactly the cost/behavioral context annotations 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each language version is tightly structured and front-loaded (purpose, when/when-not, returns, cost). However, the full description is duplicated verbatim in Russian and English, which doubles the token cost for no informational gain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description still explains the return payload (direct file links, source page, resolution) and what is deliberately absent (the files themselves). Combined with cost, default, and cap disclosures, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema, including the num 1-3 guidance for single-image requests. The description restates the num advice but adds nothing new about query, safe, or timeRange, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("searches for images by a text query") and explicitly names the two siblings that cover adjacent needs (web_search for text/facts, fetch_page for page rendering). An agent can distinguish this from all 11 siblings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit "When:" / "When not:" structure with concrete triggers (pictures, photos, logos, diagrams) and named alternatives for each non-trigger case. 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.
Собирает адреса страниц сайта: 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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Сайт или страница (http/https) / Site or page URL | |
| limit | No | Сколько адресов вернуть (1-200, по умолчанию 50). total показывает, сколько нашлось всего. / How many URLs to return (1-200, default 50). total shows how many were found. | |
| intent | No | Задача клиента словами: «страницы организаторов конференций», «все события», "только вакансии". Список адресов упорядочивается по смыслу под эту задачу, явный шум отсекается. Нужно там, где `selectPaths` бессилен: если у нужных страниц нет общего фрагмента пути, подстрока не найдёт ничего - на замере 03.10.2026 это 0/4, а упорядочивание по смыслу дало 4 нужных из 4 в первых строках. Работает, только если на сервере включён JEV_INTENT; иначе параметр игнорируется. / Plain-language goal for the section, e.g. "conference organizer pages". Ranks the URL list by meaning and drops obvious noise; use it when selectPaths cannot work because the wanted pages share no common path fragment. Ignored unless enabled server-side. | |
| search | No | Оставить адреса, содержащие эту подстроку (регистр и «ё» не важны; слова через пробел ищутся по отдельности). Фильтр по адресу, не по тексту страницы. / Keep URLs containing this substring (case- and ё-insensitive; space-separated words are matched individually). It filters URLs, not page text. | |
| selectPaths | No | Оставить только адреса, содержащие любую из этих подстрок (по одной на элемент). Так целятся в раздел: selectPaths: ["organizers"] на агрегаторе событий оставит 3565 адресов организаторов вместо служебных страниц. / Keep only URLs containing any of these substrings (one per item). This is how you aim at a section. | |
| excludePaths | No | Выбросить адреса, содержащие любую из этих подстрок: архивы, теги, служебные разделы. / Drop URLs containing any of these substrings: archives, tags, service sections. | |
| includeSubdomains | No | Считать своими и поддомены (по умолчанию только тот же хост). / Treat subdomains as own (by default only the same host). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds substantial context the annotations cannot: an 8-sitemap-per-call ceiling with disclosure in the response, and a cost model (1 credit per 10 URLs, min 1, blocked sites not charged). It also explains the 'blocked' outcome as distinct from 'empty', which prevents a false conclusion. It does not, however, describe ordering/pagination behavior in depth, so it is not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and well organized — purpose first, then when/when-not, then filter caveats, then return shape, then cost. Each sentence carries information. The only deduction is that the full Russian/English duplication roughly doubles the length, which is a deliberate but real verbosity cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, no-output-schema tool, the description supplies everything an agent needs: the return fields (pages, total, sections, source, outcome), every outcome value and its meaning, the credit cost, and the per-call sitemap limit. Nothing required 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, and the description genuinely goes beyond it: it warns that 'search' matches the URL path (not page text) and advises Russian-language callers to pass the Latin path ('organizers'), and it notes that 'intent' is silently ignored unless JEV_INTENT is enabled server-side. Those caveats materially change how the parameters get used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a precise verb and resource ('Collects a site's page URLs') and spells out the discovery mechanism (robots.txt → Sitemap:, /sitemap.xml, sitemap_index.xml, fallback to start-page links). It also names what it returns (URLs, total, sections), so an agent distinguishes it from crawl/web_search 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when: you know the site, not the page' with concrete example phrasings, plus 'Do not use when' routing to the two correct alternatives (crawl for page text, web_search for topic answers). The selection logic between siblings is fully stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Открывает одну страницу по известному адресу и возвращает её текст чистым markdown - без навигации, рекламы, скриптов и HTML. JavaScript выполняется на нашей стороне, поэтому SPA тоже читаются.
Когда: адрес известен и нужен текст - статья, документация, карточка товара. Когда не: адреса нет - сначала web_search; страниц несколько - read_urls (один вызов вместо пяти); нужны 2-5 конкретных полей - extract (в контекст придут только они); нужно увидеть вёрстку - fetch_page. Возвращает: заголовок и текст, по умолчанию первые 4000 символов. Длинная страница приходит по частям: в конце ответа указано значение offset, с которым надо вызвать тул повторно, чтобы получить продолжение. Так документ любого объёма читается окнами под ваш контекст, без повторной оплаты уже прочитанного. Читает и файлы, а не только страницы: PDF (включая сканы - распознаём текст), Word (docx), Excel (xlsx), PowerPoint (pptx), OpenDocument (odt/ods/odp/odg), RTF, EPUB и текстовые (txt/md/csv/json/xml). Адрес документа передавайте как есть: https://site.ru/otchet.docx. Старые двоичные .doc/.xls/.ppt не читаются - их отдаёт только LibreOffice, у нас его нет; нужен файл в новом формате. Цена: 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. Reads files too, not only pages: PDF (scans included - we recognise the text), Word (docx), Excel (xlsx), PowerPoint (pptx), OpenDocument (odt/ods/odp/odg), RTF, EPUB and text formats (txt/md/csv/json/xml). Pass the document URL as it is: https://site.ru/report.docx. Legacy binary .doc/.xls/.ppt are not readable - only LibreOffice can open them and we do not run it; re-save the file in a modern format. Cost: 1 credit - the cheapest way to get page content (fetch_page costs 3).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Полный URL страницы (http/https) / Full page URL | |
| fresh | No | Прочитать страницу заново, не беря недавно прочитанный текст. Нужно, когда страница только что изменилась. На цену не влияет: кредит списывается в любом случае. / 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. | |
| engine | No | Как забирать страницу: 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. | |
| offset | No | С какого символа продолжить чтение. Берите значение из предыдущего ответа этого тула («продолжить: 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. | |
| maxChars | No | Сколько символов текста вернуть (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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic safe-read profile; the description goes well beyond with server-side JS execution, ad/nav stripping, the offset-window pagination contract, credit pricing versus sibling cost, and concrete file-format support with an explicit unsupported set (.doc/.xls/.ppt) and the reason. That is exactly the extra 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core promise, then Use when / Do not use when, Returns, formats, cost — a clean hierarchy with no filler sentences. The only cost is the full Russian/English duplication, which roughly doubles token length for a single-language reader.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully covers return shape (title + text), default truncation at 4000 chars, and the continuation protocol, plus format coverage and pricing. An agent has everything needed to call it correctly on first attempt, including the multi-call pagination pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 workflow-level meaning to offset and maxChars by framing them as a windowed-read loop ('the end of the response states the offset... without paying twice'), which is more than the field docs alone convey. It does not restate engine/fresh semantics, so it is an enhancement rather than a full substitute.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Opens a single page by a known URL and returns its text as clean markdown" names a specific verb, resource, and output form, and immediately differentiates itself from read_urls, extract, fetch_page, and web_search by scope. The agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' / 'Do not use when' pair with four named alternatives and the exact condition selecting each (no URL → web_search; several pages → read_urls; a few fields → extract; layout → fetch_page). Nothing is left to inference, including a cost-based tiebreaker against fetch_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Читает пачку страниц (до 10 за вызов; на бесплатном тарифе до 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.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Список URL (1-10). Дубликаты отбрасываются, лишнее отбрасывается по тарифу: на бесплатном берём 5, на платном 10. / A list of URLs (1-10). Duplicates are dropped; the rest is cut by plan: 5 on the free tier, 10 on paid. | |
| fresh | No | Читать все страницы батча заново, не беря недавно прочитанный текст. На цену не влияет. / Read every page in the batch anew instead of using recently read text. Does not affect the price. | |
| engine | No | Как забирать страницы: auto (по умолчанию), fast, dynamic, stealth. Применяется ко всем ссылкам батча. / How to fetch the pages: auto (default), fast, dynamic, stealth. Applies to every link in the batch. | |
| maxChars | No | Сколько символов текста вернуть с КАЖДОЙ страницы (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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive, but the description goes well beyond them: partial-failure semantics (failed links are listed in a 'not read' block, they don't fail the call), duplicate and over-limit dropping with reported counts, truncation at maxChars, the batch-level offset limitation, and a per-link credit cost model. This is exactly the operational 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then usage, return behavior, and cost in a logical order; each section earns its place. It is long, however, because the Russian and English versions duplicate the same content, which roughly doubles the token footprint for a single-call read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and four parameters, the description fully carries the burden: it states the return format (markdown text per page), partial-success behavior, error reporting, and the credit cost. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: cost implications ('1 credit per link - five pages cost five credits'), that fresh does not affect price, that engine and offset apply to the whole batch, and practical guidance on keeping maxChars modest for batches. It stops short of full syntax detail but clearly exceeds the schema's own text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: 'Reads a batch of pages ... in parallel and returns each one's text as clean markdown'. It explicitly positions itself relative to siblings ('Same as read_url but in a single call'), so an agent can distinguish it from read_url and extract 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Unusually explicit: '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'. Names both alternatives and the exact condition that selects each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Проверяет утверждение: ищет источники, читает несколько независимых страниц и возвращает вердикт с дословными цитатами. Каждая цитата сверена с текстом страницы - не найденная в тексте отбрасывается вместе со своим доводом.
Когда: факт, который нельзя брать на веру - цифра, дата, «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).
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | Утверждение одной фразой, как проверяемый факт: «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. | |
| query | No | Свой поисковый запрос, если утверждение плохо ищется как есть (длинное, со сленгом). По умолчанию ищем по тексту утверждения. / A custom search query when the claim searches poorly as written (long, slangy). By default the claim text itself is the query. | |
| language | No | Язык поиска источников / Source search language: auto, ru, en | |
| timeRange | No | Свежесть источников - для утверждений, которые могли устареть (цены, версии, должности): all, day, week, month, year. / Source recency - for claims that may have gone stale (prices, versions, job titles): all, day, week, month, year. | |
| maxSources | No | Сколько независимых источников читать (2-5, по умолчанию 4). Меньше - быстрее, больше - надёжнее. На цену не влияет. / How many independent sources to read (2-5, default 4). Fewer is faster, more is sturdier. Does not affect the price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only/idempotent profile, but the description adds substantial behavior: quotes not found in page text are dropped along with their argument, sources are counted in independent domains ('three quotes from one site are one voice'), failed fetches are replaced so the requested source count is still delivered, and incomplete checks surface in the verdict and caveats. It also gives runtime (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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and well ordered: purpose, then when/when-not, then verdict semantics, then returns/time/cost. Every sentence carries information, but the full Russian/English duplication roughly doubles the payload for a reader who needs only one language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 return contract and does so fully: verdict values are enumerated with their meanings, plus confidence, quotes with links, and caveats, alongside source count, timing, and cost. The 'mixed/unverified are normal outcomes, not errors' note is exactly the kind of interpretation guidance an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning: the independent-domain counting rule explains how maxSources actually translates into evidence weight, and the failed-site replacement note clarifies that asking for N sources still yields N reads. It stops short of restating the claim/query/language/timeRange semantics, which the schema already covers well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a precise verb+resource+mechanism: 'Verifies a statement: searches for sources, reads several independent pages and returns a verdict with verbatim quotes.' It immediately differentiates itself from siblings by naming deep_research and read_url as the tools for the adjacent jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' / 'Do not use when' blocks with concrete triggers (numbers, dates, 'X supports Y', claims from the user or from the agent's own memory) and named alternatives for the exclusion cases. 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; нужны 2-5 конкретных значений - extract; нужен готовый разбор темы со сносками - deep_research. Возвращает: до 30 результатов текстом, без содержимого страниц. У каждого результата - домен, дата публикации (когда движок её отдаёт) и rel - лексическая релевантность запросу [0..1], по ней список и отсортирован. Дат нет у части выдачи: это ограничение движков, а не признак старой страницы. С excerpts: true добавляет реальный текст топ-страниц (+3-10 с), это часто экономит последующий вызов read_url. Если этого мало - chunksPerSource (0-5) читает страницу глубже (600 × N символов против 1200 у excerpt) и отдаёт несколько кусков на результат, а includeRawContent - полный текст страницы (до 20 000 символов, берите 1-3 результата). Всё читается в том же вызове и цены не меняет: дешевле, чем идти за текстом по одной ссылке. Свежесть: timeRange (day/week/month/year) или точные границы publishedAfter / publishedBefore - фильтр по дате публикации на нашей стороне; страницы без даты в окно не проходят, и в ответе сказано, сколько таких отброшено. Цена: 1 кредит за вызов, независимо от num. Выдача живая, поэтому повтор того же запроса даёт другой результат и списывается снова.
Searches the live web by a text query and returns ranked results: title, link, snippet. Strong coverage of the Russian-language web.
Use when: you need fresh facts, links or data past your knowledge cutoff. Do not use when: you already know the page URL - that is read_url; you need a handful of specific values - extract; you need a written answer across many sources - deep_research. Returns: up to 30 results as text, without page content. Each result carries its domain, its publication date when the engine provides one, and rel - lexical relevance to the query [0..1], which is what the list is sorted by. Part of the results have no date: that is an engine limitation, not a sign of an old page. With excerpts: true it also pulls the actual text of the top pages (+3-10 s), which often saves a follow-up read_url. If that is not enough, chunksPerSource (0-5) reads the page deeper (600 × N chars versus 1200 for excerpt) and returns several chunks per result, and includeRawContent returns the full page text (up to 20 000 chars - ask for 1-3 results). Everything is read inside the same call and does not change the price: cheaper than fetching each link. Freshness: timeRange (day/week/month/year) or exact bounds publishedAfter / publishedBefore - a publication-date filter on our side; pages without a date do not pass, and the answer states how many were dropped. Cost: 1 credit per call regardless of num. Results are live, so repeating the same query returns different results and is billed again.
| Name | Required | Description | Default |
|---|---|---|---|
| num | No | Сколько результатов (1-30) / How many results (1-30) | |
| depth | No | Глубина: auto (по умолчанию, больше движков и результатов) или flash (быстрее, узкая выдача - для одного факта). / Depth: auto (default, more engines and results) or flash (faster, narrow - for a single fact). | |
| query | Yes | Поисковый запрос / Search query | |
| category | No | Категория / Category: general, news, it, science | |
| excerpts | No | Забрать реальный текст топ-страниц под запрос (+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. | |
| language | No | Язык / Language: auto, ru, en | |
| timeRange | No | Свежесть по дате публикации: 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. | |
| excludeDomains | No | Исключить эти сайты и их поддомены: ["pinterest.com"]. До 10 доменов. / Exclude these sites and their subdomains. Up to 10 domains. | |
| includeDomains | No | Искать только на этих сайтах, вместе с поддоменами: ["habr.com", "vc.ru"]. До 10 доменов. / Search only these sites, including subdomains. Up to 10 domains. | |
| publishedAfter | No | Нижняя граница даты публикации, YYYY-MM-DD включительно. Сильнее timeRange, если заданы обе. / Publication date lower bound, YYYY-MM-DD inclusive. Overrides timeRange when both are given. | |
| chunksPerSource | No | Сколько кусков текста вернуть на каждый из топ-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. | |
| publishedBefore | No | Верхняя граница даты публикации, YYYY-MM-DD включительно. / Publication date upper bound, YYYY-MM-DD inclusive. | |
| includeRawContent | No | Вернуть полный текст страницы для топ-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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/non-idempotent, but the description goes well past them: cost of 1 credit per call regardless of num, the fact that live results mean re-running the same query is billed again, that results carry a lexical rel score, that missing dates are an engine limitation rather than a staleness signal, that the freshness filter is server-side and reports dropped pages, and the latency/token cost of excerpts and includeRawContent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Internally well structured and front-loaded (purpose, when/when-not, returns, options, freshness, cost). However every sentence is duplicated verbatim in Russian and English, roughly doubling the token cost of an already long description; the second language adds no new information for a typical agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter, no-output-schema search tool, the description covers what is missing elsewhere: return fields, result cap, cost model, freshness semantics, dropped-page reporting, and the expensive-content escape hatches. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 cross-parameter meaning the schema states only in isolation: excerpts often removes a follow-up read_url, chunksPerSource returns 600×N chars versus 1200 for an excerpt, includeRawContent is up to 20k chars and should be paired with small num, and publishedAfter overrides timeRange. These relationships materially change how an agent sets parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (searches), resource (the live web), input (text query) and output shape (ranked title/link/snippet list), plus a differentiator (strong Russian-language coverage). It names the sibling tools it is NOT (read_url, extract, deep_research), so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains an explicit 'Use when' / 'Do not use when' block: fresh facts past the knowledge cutoff on one side, and three named alternatives on the other with the condition that selects each (known URL -> read_url, few values -> extract, written synthesis -> deep_research). 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.
Забирает текстовую дорожку ролика YouTube - ручные субтитры или авто - по ссылке или 11-символьному id. Видео и звук не скачиваются: это дешёвый способ получить содержание ролика в контекст агента.
Когда: нужен текст видео - конспект, цитата, проверка сказанного, поиск по содержанию лекции; ролик уже известен или найден через web_search. Для поиска видео используйте web_search (например, site:youtube.com), а не этот тул. Когда не: нужен текст страницы - read_url; нужна картинка/вёрстка - fetch_page; не YouTube (VK, Rutube, Дзен) - не работает. Плейлист не разбирается, нужен ролик. Возвращает по каждому ролику: название, канал, длительность, дату, язык, вид дорожки (ручные/авто), текст и ссылки на ролик и канал. Если дорожки нет - статус и список доступных языков: повторите с существующим. Длинный текст приходит окном maxChars; в конце указано from, с которым надо вызвать тул, чтобы получить продолжение без повторной оплаты. Цена: 1 кредит за ролик, у которого субтитры получены; неудачи (нет дорожки, ограничение частоты, недоступный ролик) не списываются. До 5 роликов за вызов.
Fetches a YouTube video's text track - manual captions or auto - by URL or 11-char id. No video or audio is downloaded: this is the cheap way to bring video content into the agent's context.
Use when: you need the text of a video - a summary, a quote, checking what was said, searching a lecture; the video is known or was found via web_search. To find videos use web_search (e.g. site:youtube.com), not this tool. Do not use when: you need page text - read_url; you need layout or a screenshot - fetch_page; the video is not on YouTube. Playlists are not expanded, pass a video. Returns per video: title, channel, duration, date, language, track kind (manual/auto), the text and links to the video and channel. If no track exists - a status plus the list of available languages, so you can retry with a real one. Long text arrives in windows of maxChars; the end states the from value for the continuation call, already-read text is not charged again. Cost: 1 credit per video whose captions were fetched; failures (no track, rate limiting, unavailable video) are not charged. Up to 5 videos per call.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Конец окна в секундах. / Window end in seconds. | |
| from | No | Начало окна в секундах (для продолжения используйте next_from из ответа). / Window start in seconds (use next_from from the response for continuation). | |
| videos | Yes | Ссылки на ролики YouTube или их id (до 5 за вызов). Формы: watch?v=, youtu.be/, shorts, embed, live, голый 11-символьный id. / YouTube video URLs or ids (up to 5 per call). | |
| maxChars | No | Сколько символов текста вернуть на ролик (200-50000, по умолчанию 12000). / Characters of text per video (200-50000, default 12000). | |
| languages | No | Языки в порядке предпочтения, по умолчанию ["ru", "en"]. Ручная дорожка предпочтительнее авто. Если нужного языка нет - вернём доступные. / Languages in preference order, default ["ru", "en"]. Manual tracks are preferred over auto; if the requested one is missing, available ones are returned. | |
| timestamps | No | true - вернуть фрагменты с таймкодами вместо сплошного текста (дороже по контексту; для навигации по длинному ролику). / true - return timestamped fragments instead of continuous text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/open-world safety, and the description goes well beyond them: credit cost (1 credit only for videos whose captions were actually fetched), failure non-charging, the 5-video batch cap, the maxChars windowing plus from/next_from continuation that is not re-charged, and the no-track fallback that returns available languages. These are exactly the operational traits an agent needs before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each paragraph is front-loaded and purposeful (purpose, use/do-not-use, returns, cost), and every sentence carries distinct information. The main cost is that the entire text is duplicated in Russian and English, roughly doubling the payload for identical content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully carries the return-shape burden: per-video title, channel, duration, date, language, track kind, text and links, plus the no-track status path. Cost, batching and pagination semantics are all present, leaving nothing an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter (to, from, videos, maxChars, languages, timestamps) is already documented with ranges and defaults, so the baseline is 3. The description reinforces the maxChars window and continuation workflow but adds no syntax or format detail the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetches a YouTube video's text track - manual captions or auto - by URL or 11-char id') and immediately bounds the scope with 'No video or audio is downloaded'. An agent can distinguish it from read_url, fetch_page and web_search 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' / 'Do not use when' blocks with named alternatives: web_search for finding videos, read_url for page text, fetch_page for layout/screenshot, and a stated limitation (non-YouTube platforms, playlists not expanded). This is close to a routing table for the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
yt_srtextract2 fields changedInput schema / properties / urls / descriptionPrevious value: -"Список URL (1-5) вместо url - одна схема на все страницы. Каждая страница тарифицируется отдельно. / A list of URLs (1-5) instead of url - one schema for all pages. Each page is billed separately."New value: +"Список URL (1-10) вместо url - одна схема на все страницы. Лишнее отбрасывается по тарифу: на бесплатном берём 5, на платном больше. Каждая страница тарифицируется отдельно. / A list of URLs (1-10) instead of url - one schema for all pages; the rest is cut by plan (5 on the free tier). Each page is billed separately."Input schema / properties / urls / maxItemsPrevious value: -5New value: +10read_urls2 fields changedInput schema / properties / urls / descriptionPrevious value: -"Список URL (1-5). Дубликаты отбрасываются. / A list of URLs (1-5). Duplicates are dropped."New value: +"Список URL (1-10). Дубликаты отбрасываются, лишнее отбрасывается по тарифу: на бесплатном берём 5, на платном 10. / A list of URLs (1-10). Duplicates are dropped; the rest is cut by plan: 5 on the free tier, 10 on paid."Input schema / properties / urls / maxItemsPrevious value: -5New value: +10answer_search1 field changedInput schema / properties / depth / descriptionPrevious value: -"Глубина: fast (2 страницы), balanced (5 страниц, по умолчанию), deep (10 страниц). Больше страниц — выше качество, дольше время. / Depth: fast (2 pages), balanced (5 pages, default), deep (10 pages). More pages = higher quality, longer time."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."crawl3 fields changedInput schema / properties / intentAdded value: +{
+ "description": "Задача клиента словами: «страницы организаторов конференций», «все события», \"только вакансии\". Адреса карты упорядочиваются по смыслу, и читаются первые `limit` - так прицельное чтение работает там, где у нужных страниц нет общего фрагмента пути и `selectPaths` не находит ничего (замер 03.10.2026: 0/4 у подстроки против 4/4 в первых строках у отбора по смыслу). Работает, только если на сервере включён JEV_INTENT. / Plain-language goal for the section. The URL list is ranked by meaning and the first `limit` pages are read - use it when selectPaths finds nothing because the wanted pages share no common path fragment. Ignored unless enabled server-side.",
+ "maxLength": 300,
+ "type": "string"
+}Input schema / properties / limit / descriptionPrevious value: -"Сколько страниц прочитать (1–20, по умолчанию 5). / How many pages to read (1–20, default 5)."New value: +"Сколько страниц прочитать (1-20, по умолчанию 5). / How many pages to read (1-20, default 5)."Input schema / properties / selectPaths / descriptionPrevious 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."deep_research1 field changedInput schema / properties / ticket / descriptionPrevious 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."extract2 fields changedInput schema / properties / schema / descriptionPrevious value: -"Схема результата. Проще всего — сокращённая форма: {\"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."New value: +"Схема результата. Проще всего - сокращённая форма: {\"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."Input schema / properties / urls / descriptionPrevious value: -"Список URL (1–5) вместо url — одна схема на все страницы. Каждая страница тарифицируется отдельно. / A list of URLs (1–5) instead of url — one schema for all pages. Each page is billed separately."New value: +"Список URL (1-5) вместо url - одна схема на все страницы. Каждая страница тарифицируется отдельно. / A list of URLs (1-5) instead of url - one schema for all pages. Each page is billed separately."fetch_page1 field changedInput schema / properties / maxChars / descriptionPrevious value: -"Сколько символов текста вернуть (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."New value: +"Сколько символов текста вернуть (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."get_usage1 field changedInput schema / properties / verbose / descriptionPrevious value: -"true — полный человекочитаемый отчёт с прайс-листом всех инструментов. По умолчанию компактный JSON без прайс-листа. / true — the full human-readable report with the price list of every tool. Default is compact JSON without the price list."New value: +"true - полный человекочитаемый отчёт с прайс-листом всех инструментов. По умолчанию компактный JSON без прайс-листа. / true - the full human-readable report with the price list of every tool. Default is compact JSON without the price list."image_search1 field changedInput schema / properties / num / descriptionPrevious value: -"Сколько картинок вернуть (1–48, по умолчанию 12). Нужна одна картинка — просите 1–3, не тратьте контекст. / How many images to return (1–48, default 12). Need just one — ask for 1–3 and save context."New value: +"Сколько картинок вернуть (1-48, по умолчанию 12). Нужна одна картинка - просите 1-3, не тратьте контекст. / How many images to return (1-48, default 12). Need just one - ask for 1-3 and save context."map2 fields changedInput schema / properties / intentAdded value: +{
+ "description": "Задача клиента словами: «страницы организаторов конференций», «все события», \"только вакансии\". Список адресов упорядочивается по смыслу под эту задачу, явный шум отсекается. Нужно там, где `selectPaths` бессилен: если у нужных страниц нет общего фрагмента пути, подстрока не найдёт ничего - на замере 03.10.2026 это 0/4, а упорядочивание по смыслу дало 4 нужных из 4 в первых строках. Работает, только если на сервере включён JEV_INTENT; иначе параметр игнорируется. / Plain-language goal for the section, e.g. \"conference organizer pages\". Ranks the URL list by meaning and drops obvious noise; use it when selectPaths cannot work because the wanted pages share no common path fragment. Ignored unless enabled server-side.",
+ "maxLength": 300,
+ "type": "string"
+}Input schema / properties / limit / descriptionPrevious value: -"Сколько адресов вернуть (1–200, по умолчанию 50). total показывает, сколько нашлось всего. / How many URLs to return (1–200, default 50). total shows how many were found."New value: +"Сколько адресов вернуть (1-200, по умолчанию 50). total показывает, сколько нашлось всего. / How many URLs to return (1-200, default 50). total shows how many were found."read_url3 fields changedInput schema / properties / engine / descriptionPrevious value: -"Как забирать страницу: 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."New value: +"Как забирать страницу: 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."Input schema / properties / maxChars / descriptionPrevious value: -"Сколько символов текста вернуть (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."New value: +"Сколько символов текста вернуть (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."Input schema / properties / offset / descriptionPrevious value: -"С какого символа продолжить чтение. Берите значение из предыдущего ответа этого тула («продолжить: 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."New value: +"С какого символа продолжить чтение. Берите значение из предыдущего ответа этого тула («продолжить: 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."read_urls2 fields changedInput schema / properties / maxChars / descriptionPrevious value: -"Сколько символов текста вернуть с КАЖДОЙ страницы (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."New value: +"Сколько символов текста вернуть с КАЖДОЙ страницы (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."Input schema / properties / urls / descriptionPrevious value: -"Список URL (1–5). Дубликаты отбрасываются. / A list of URLs (1–5). Duplicates are dropped."New value: +"Список URL (1-5). Дубликаты отбрасываются. / A list of URLs (1-5). Duplicates are dropped."verify_claim3 fields changedInput schema / properties / claim / descriptionPrevious value: -"Утверждение одной фразой, как проверяемый факт: «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."New value: +"Утверждение одной фразой, как проверяемый факт: «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."Input schema / properties / maxSources / descriptionPrevious value: -"Сколько независимых источников читать (2–5, по умолчанию 4). Меньше — быстрее, больше — надёжнее. На цену не влияет. / How many independent sources to read (2–5, default 4). Fewer is faster, more is sturdier. Does not affect the price."New value: +"Сколько независимых источников читать (2-5, по умолчанию 4). Меньше - быстрее, больше - надёжнее. На цену не влияет. / How many independent sources to read (2-5, default 4). Fewer is faster, more is sturdier. Does not affect the price."Input schema / properties / timeRange / descriptionPrevious value: -"Свежесть источников — для утверждений, которые могли устареть (цены, версии, должности): all, day, week, month, year. / Source recency — for claims that may have gone stale (prices, versions, job titles): all, 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."web_search6 fields changedInput schema / properties / chunksPerSource / descriptionPrevious value: -"Сколько кусков текста вернуть на каждый из топ-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."New value: +"Сколько кусков текста вернуть на каждый из топ-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."Input schema / properties / depth / descriptionPrevious value: -"Глубина: auto (по умолчанию, больше движков и результатов) или flash (быстрее, узкая выдача — для одного факта). / Depth: auto (default, more engines and results) or flash (faster, narrow — for a single fact)."New value: +"Глубина: auto (по умолчанию, больше движков и результатов) или flash (быстрее, узкая выдача - для одного факта). / Depth: auto (default, more engines and results) or flash (faster, narrow - for a single fact)."Input schema / properties / excerpts / descriptionPrevious 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."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."Input schema / properties / includeRawContent / descriptionPrevious value: -"Вернуть полный текст страницы для топ-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."New value: +"Вернуть полный текст страницы для топ-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."Input schema / properties / num / descriptionPrevious value: -"Сколько результатов (1–30) / How many results (1–30)"New value: +"Сколько результатов (1-30) / How many results (1-30)"Input schema / properties / timeRange / descriptionPrevious 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."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."crawl1 field changedInput schema / properties / selectPaths / descriptionPrevious 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."crawlmapweb_search1 field changedInput schema / properties / excerpts / descriptionPrevious 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."web_search5 fields changedInput schema / properties / chunksPerSourceAdded 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"
+}Input schema / properties / includeRawContentAdded 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"
+}Input schema / properties / publishedAfterAdded 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"
+}Input schema / properties / publishedBeforeAdded value: +{
+ "description": "Верхняя граница даты публикации, YYYY-MM-DD включительно. / Publication date upper bound, YYYY-MM-DD inclusive.",
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}Input schema / properties / timeRange / descriptionPrevious 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."get_usage2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / verboseAdded 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"
+}answer_search6 fields changedInput schema / properties / depth / defaultAdded value: +"balanced"Input schema / properties / depth / descriptionPrevious 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."Input schema / properties / language / defaultAdded value: +"auto"Input schema / properties / language / descriptionPrevious value: -"Язык поиска / Search language (default: auto)"New value: +"Язык поиска и ответа / Search and answer language: auto, ru, en"Input schema / properties / query / descriptionPrevious value: -"Вопрос или задача / Question or search task"New value: +"Вопрос или поисковый запрос / Question or search query"Input schema / properties / query / maxLengthPrevious value: -500New value: +2000answer_search15 media & data tools for AI agents: search, transcribe, subtitles, voiceover, translate & more.
Web tools for AI agents: scrape pages to Markdown, audit SEO, detect tech stacks, check sitemaps
44 tools for AI agents: Trends, SERP, SEO audits, screenshots, weather, FX, whois, RSS.
Web data for agents: YouTube transcripts, screenshots, Google News, WHOIS, jobs, tech stack, more.
Add one secure layer between your agents and this server.
