A
licenseA
qualityB
maintenanceEnables AI agents to run RU-first web searches through the Yandex index and extract web pages into clean reader-mode Markdown, bypassing anti-bot blocks.
3
1,390
MIT
срезAI — Search API for AI agents
by ru.srezai
Server Details
Web search, page reading and structured extraction for AI agents, with strong RU coverage
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
TDQS
A4.7/5.0
Disambiguation4/5
Each tool targets a distinct operation, and the descriptions explicitly contrast read_url vs read_urls vs extract vs fetch_page. The only possible confusion is between answer_search and deep_research—both synthesize sourced answers—but their scope (single RAG pass vs multi-step long-running research) and cost/behavior are clearly differentiated.
Naming Consistency5/5
All ten names follow the same lowercase snake_case pattern and mostly use a verb_noun shape (read_url, fetch_page, verify_claim, get_usage). The compound search names (web_search, image_search, answer_search, deep_research) are still predictable and form a recognizable family.
Tool Count5/5
Ten tools is a well-scoped size for a search/retrieval API: search, image search, page reading (single/batch), structured extraction, visual capture, synthesized answers, deep research, claim verification, and usage/billing. No tool feels redundant or missing.
Completeness5/5
The surface covers the full research workflow: discover (web_search, image_search), retrieve (read_url, read_urls, fetch_page), structure (extract), synthesize (answer_search, deep_research), verify (verify_claim), and monitor costs (get_usage). There are no obvious dead ends—even long pages have a defined continuation mechanism.
Available Tools
10 toolsanswer_searchAnswer Search — RAG с семантическим ранжированиемARead-onlyInspect
Полный RAG-цикл: поиск источников, семантическое ранжирование через BGE-reranker-v2-m3, чтение релевантных страниц и синтез финального ответа. Возвращает готовый ответ с указанием релевантности каждого источника (0–1).
Когда: нужен итоговый ответ на вопрос, а не список ссылок. Лучше web_search + read_url, когда требуется интерпретация и синтез по нескольким источникам. Конвейер: переформулировка запроса → параллельный поиск → BGE-reranker отбирает топ → чтение страниц → синтез ответа. Возвращает: текст ответа + sources (каждый с relevance, chars_read, read_success). Источники всегда отсортированы по убыванию relevance. Цена зависит от depth: fast — 50 кредитов, balanced — 100 кредитов, deep — 200 кредитов.
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 — 50 credits, balanced — 100 credits, deep — 200 credits.
ParametersJSON Schema
| 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 |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and non-destructive behavior, and the description adds valuable context beyond those hints: the pipeline steps, source sorting by descending relevance, per-source fields like chars_read and read_success, and credit cost dependence on depth. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labeled sections: when to use, pipeline, returns, and cost. It is front-loaded with the purpose, but the full bilingual repetition in both Russian and English adds length; still, each section earns its place and remains scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description fully explains return values: answer text plus sources with relevance, chars_read, and read_success, and the guarantee of descending relevance order. It also covers depth semantics and cost, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds extra meaning by explaining the cost implications of depth (50/100/200 credits) and framing query as a question to be synthesized. This supplements rather than merely repeats the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: a full RAG cycle performing search, semantic reranking via BGE-reranker-v2-m3, page reading, and answer synthesis. It clearly distinguishes itself from siblings by emphasizing that it returns a ready answer rather than a list of links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use-when guidance is present: 'нужен итоговый ответ на вопрос, а не список ссылок' and explicitly names web_search + read_url as the alternative when synthesis across multiple sources is not needed. This gives the agent actionable routing criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deep_researchГлубокое исследование / Deep researchARead-onlyInspect
Проводит многошаговое исследование: сам формулирует запросы, ищет, читает источники и возвращает готовый связный ответ со ссылками на использованные страницы.
Когда: вопрос требует сопоставления нескольких источников и вывода — «сравни», «разберись», «что известно о». Когда не: нужен один факт или список ссылок — это web_search, он в 20 раз дешевле и отвечает за секунды.
Как это работает: исследование идёт 1–15 минут — дольше, чем живёт одно соединение. Поэтому инструмент запускает задачу и ждёт до ~90 секунд. Если за это время ответ готов — возвращает его сразу. Если нет — возвращает строку с пометкой [research_pending] и талоном (ticket). Тогда вызовите этот же инструмент ещё раз, передав ticket (query можно не повторять), чтобы дождаться готового результата; повторяйте, пока не придёт ответ. Такой дозабор по талону НЕ списывается заново — деньги берутся один раз, за саму задачу.
Возвращает: текст ответа плюс список источников. Если источники не вернулись, в ответе будет предупреждение — такой вывод не считается проверенным.
Цена: 20 кредитов плюс 3 за каждую 1000 токенов ответа — самый дорогой вызов. Списывается один раз за задачу; повтор ТЕМЫ (новый query) — новая задача и новое списание, а дозабор по ticket бесплатен.
Runs multi-step research: forms its own queries, searches, reads sources and returns a finished answer with links to the pages it used.
Use when: the question needs several sources reconciled into a conclusion — "compare", "analyse", "what is known about". Do not use when: you need a single fact or a list of links — that is web_search, 20× cheaper and seconds fast.
How it works: research takes 1–15 minutes — longer than a single connection lives. So the tool starts the job and waits up to ~90 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; repeat until it arrives. Polling by ticket is NOT charged again — you pay once, for the job itself.
Returns: the answer text plus a source list. If no sources came back the response says so — treat that output as unverified.
Cost: 20 credits plus 3 per 1000 output tokens — the most expensive call. Charged once per job; repeating the TOPIC (a new query) is a new job and a new charge, while polling by ticket is free.
ParametersJSON Schema
| 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. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint, openWorldHint, etc.), but the description goes far beyond them. It reveals the 1–15 minute runtime, the 90-second synchronous wait, the [research_pending] ticket mechanism, free polling, one-time billing, and the unverified-source warning. It also explains that repeating a topic costs again. This is rich behavioral disclosure without any contradiction to annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite its length, the description is exceptionally well-structured: it opens with the purpose, then has clear 'when/not' and 'how it works' sections, followed by return format and cost. Every sentence carries information — no filler. The front-loaded purpose immediately answers 'what does this do?' and the cost/billing details are essential for an agent deciding whether to invoke.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex async tool with no output schema, the description covers everything an agent needs: the workflow, the polling protocol, the return structure (answer + sources), the source-missing warning, and the cost model. It anticipates the pain points of async execution and billing. No critical details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both query and ticket are already documented in the schema with clear explanations of when each is required. The description adds context about the ticket being free and the query being repeatable, but these are behavioral rather than parameter-semantic additions. The schema already does the heavy lifting, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('runs multi-step research'), the resource (web sources), and the output (finished answer with links). It explicitly names the sibling web_search as the alternative for simpler queries, making differentiation unambiguous. The purpose is concrete and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (multi-source comparison, analysis) and when-not-to-use (single fact or link list, pointing to web_search as 20x cheaper and faster). Also explains the async polling workflow (start with query, poll with ticket) and that polling is free — no hidden costs. This is a complete usage guide for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extractИзвлечь данные по схеме / Extract data by schemaARead-onlyIdempotentInspect
Читает страницу и возвращает JSON строго по вашей схеме: только запрошенные поля, без текста страницы. Чего на странице нет — приходит null, значения не домысливаются.
Когда: нужны 2–5 конкретных значений — цена, характеристики, автор и дата, список вакансий. Экономит контекст: вместо всей страницы придут только поля. Когда не: нужен связный текст или вы не знаете заранее, что искать, — read_url (и в 4 раза дешевле). Схема: принимается и сокращённая форма — {"title":"string","price":"number?"}, где «?» делает поле необязательным, а «[]» — массивом; полный JSON Schema тоже работает. Описания полей заметно повышают точность разбора. Возвращает: объект по схеме на каждую ссылку. Можно передать до 5 ссылок разом — одна схема применится ко всем. Цена: 4 кредита за каждую ссылку (чтение плюс разбор моделью).
Reads a page and returns JSON strictly following your schema: only the requested fields, no page text. Anything absent from the page comes back as null — values are never invented.
Use when: you need a handful of specific values — price, specs, author and date, a list of job openings. It saves context: you get the fields, not the page. Do not use when: you need prose, or you do not know in advance what to look for — read_url (and 4× cheaper). Schema: a shorthand form is accepted — {"title":"string","price":"number?"}, where "?" marks a field optional and "[]" an array; full JSON Schema works too. Field descriptions noticeably improve extraction accuracy. Returns: one object per link, shaped by your schema. Up to 5 links per call, one schema applied to all. Cost: 4 credits per link (page read plus model parsing).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL страницы (http/https) / Page URL (http/https) | |
| urls | No | Список URL (1–5) вместо url — одна схема на все страницы. Каждая страница тарифицируется отдельно. / A list of URLs (1–5) instead of url — one schema for all pages. 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». |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond the annotations: absent fields become null, values are never invented, cost is 4 credits per link, up to 5 links per call, and field descriptions improve accuracy. This adds meaningful context while remaining consistent with the readOnlyHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (When, Schema, Returns, Cost) and is front-loaded with the core function. It is bilingual, which adds length but serves the audience. Every sentence provides useful information, though some repetition exists between languages.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fully explains return shape ('one object per link, shaped by your schema'), link limits, cost, and schema format variants. It covers all essential operational details for correct invocation and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100% with rich parameter descriptions. The description adds value by explaining shorthand schema syntax ('{"title":"string","price":"number?"}'), the difference between url and urls, and how instruction disambiguates parsing. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Reads a page and returns JSON strictly following your schema: only the requested fields, no page text.' It uses a specific verb (reads/extracts) and resource (page), and differentiates from siblings like read_url by emphasizing structured extraction over raw content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided with 'Use when' (specific values like price, specs, job listings) and 'Do not use when' (prose or unknown targets), including a direct alternative: 'read_url (and 4× cheaper)'. This clearly separates it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_pageСкриншот и структура страницы / Page screenshot and structureARead-onlyIdempotentInspect
Открывает страницу полноценным браузером и возвращает скриншот картинкой прямо в ответе, ссылку на полноразмерный файл и текст страницы в markdown.
Когда: нужно УВИДЕТЬ страницу — раскладку, цвета, типографику, визуальную иерархию: «повтори дизайн как здесь», «что не так с вёрсткой». Когда не: нужен только текст — read_url (1 кредит против 3, и быстрее); нужны отдельные значения — extract. Возвращает: изображение плюс текст. Картинка занимает много контекста, поэтому для чтения этот инструмент избыточен. Цена: 3 кредита.
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. Cost: 3 credits.
ParametersJSON Schema
| 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. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses that the tool uses a full browser, returns an inline image plus a link and markdown text, consumes significant context, and costs 3 credits. This adds valuable behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (when to use, when not, returns, cost) and front-loaded with the core purpose. The bilingual format doubles the length but does not add fluff; it remains efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description fully explains the return values (inline image, file link, markdown text) and also covers cost and context implications. For a simple two-parameter tool with solid annotations, this is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with detailed descriptions (url format, maxChars range and default). The description does not add extra parameter-level semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: opens a page in a full browser and returns a screenshot, a link to the full-size file, and page text in markdown. It distinguishes itself from siblings by explicitly contrasting with read_url and extract, and by emphasizing the visual need case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use conditions, naming alternatives (read_url for text-only, extract for specific values) and even comparing costs (1 credit vs 3). This is exemplary guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageБаланс и лимиты / Balance and limitsARead-onlyIdempotentInspect
Показывает остаток на счёте, расход суточной квоты, время сброса окна и цены всех инструментов в кредитах. Параметров не требует.
Когда: вызов упал с [rate_limited] и надо понять, ждать секунды или до следующих суток; пользователь спрашивает про баланс и расходы; планируется большой батч и надо убедиться, что кредитов хватит. Возвращает: баланс, использованную квоту, момент сброса и прайс-лист. Цена: бесплатно, квоту и лимит запросов этот вызов не расходует — его можно звать без опасений.
Shows the remaining balance, daily quota usage, when the window resets, and the price of every tool in credits. Takes no parameters.
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 are about to run a large batch and want to confirm you have the credits. Returns: balance, quota used, reset time and the price list. Cost: free — this call consumes neither quota nor rate limit, so call it freely.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds that the call is free, consumes neither quota nor rate limit, and can be called freely. It also discloses exactly what is returned (balance, quota, reset time, price list). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with labeled sections (Shows/When/Returns/Cost) and front-loaded with the main purpose. However, it repeats the exact same content in Russian and English, doubling the length without adding informational value for monolingual readers. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is complete: it explains the return values, usage scenarios, and cost implications. There is no missing information needed for an agent to decide when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description explicitly states 'takes no parameters' in both languages. Since there are no parameters to document, the description appropriately confirms this; the baseline of 4 for zero-parameter tools is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows remaining balance, daily quota usage, reset time, and tool prices in credits. The verb 'shows' is specific and the resource is unambiguous. It distinguishes itself from sibling tools (search, fetch, extract) by focusing on account/usage information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'when to use' scenarios are provided: after a rate_limited failure, when the user asks about balance/spending, or before a large batch to check credit sufficiency. It also notes the call is free and does not consume quota, giving clear guidance on safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image_searchПоиск изображений / Image searchARead-onlyInspect
Ищет изображения по текстовому запросу и возвращает прямые ссылки на файлы, страницу-источник и разрешение.
Когда: нужны картинки, фотографии, логотипы, схемы. Когда не: нужен текст или факты — 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.
ParametersJSON Schema
| 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 |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it states that files are never downloaded or embedded, and it discloses the cost (1 credit per call) and the context-size impact of large num values. This goes beyond the annotations, though it doesn't detail response structure or pagination, which is minor given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (When, When not, Returns, Cost) and is front-loaded with the core purpose. Every sentence serves a purpose, and the bilingual format is consistent. It's concise yet comprehensive, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with full schema coverage and no output schema, the description covers all essential aspects: purpose, usage conditions, behavioral constraints, cost, and parameter guidance. The agent has everything needed to call the tool correctly and interpret results, given the annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the practical implications of num (context cost) and reinforcing the default and maximum, which helps the agent make better parameter choices. It doesn't add new syntax details but enhances the semantic understanding of num's impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching for images by text query and returning direct file links, source page, and resolution. It explicitly distinguishes itself from siblings like web_search and fetch_page, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance, naming alternatives (web_search for text/facts, fetch_page for page appearance). It also gives practical usage tips like setting num to 1-3 for a single image, which is actionable and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_urlПрочитать страницу / Read a pageARead-onlyIdempotentInspect
Открывает одну страницу по известному адресу и возвращает её текст чистым markdown — без навигации, рекламы, скриптов и HTML. JavaScript выполняется на нашей стороне, поэтому SPA тоже читаются.
Когда: адрес известен и нужен текст — статья, документация, карточка товара. Когда не: адреса нет — сначала web_search; страниц несколько — read_urls (один вызов вместо пяти); нужны 2–5 конкретных полей — extract (в контекст придут только они); нужно увидеть вёрстку — fetch_page. Возвращает: заголовок и текст, по умолчанию первые 4000 символов. Длинная страница приходит по частям: в конце ответа указано значение offset, с которым надо вызвать тул повторно, чтобы получить продолжение. Так документ любого объёма читается окнами под ваш контекст, без повторной оплаты уже прочитанного. Цена: 1 кредит, самый дешёвый способ получить содержимое страницы (fetch_page — 3).
Opens a single page by a known URL and returns its text as clean markdown — no navigation, ads, scripts or HTML. JavaScript is executed on our side, so SPAs read fine too.
Use when: you have the URL and need the text — an article, documentation, a product page. Do not use when: you have no URL — start with web_search; you have several pages — read_urls (one call instead of five); you need a handful of specific fields — extract (only those reach your context); you need to see the layout — fetch_page. Returns: title and text, the first 4000 characters by default. A long page arrives in windows: the end of the response states the offset to call the tool with again to get the continuation. That way a document of any size is read in windows sized to your context, without paying twice for what you already read. Cost: 1 credit — the cheapest way to get page content (fetch_page costs 3).
ParametersJSON Schema
| 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. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses practical behaviors: JavaScript execution server-side (SPA support), pagination via offset with continuation, default 4000-character return, cost of 1 credit, and caching/refresh behavior via the 'fresh' parameter. These details add substantial value and do not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual (RU/EN), making it longer, but each section (description, usage, returns, cost) is purpose-driven and clearly structured. It is front-loaded with the core purpose. The length is justified by the density of actionable guidance, though a single-language version could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by explaining the return shape (title, text, offset), pagination windows, and default truncation. It also covers cost implications and engine behavior, providing a complete understanding of how the tool behaves in various scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with parameter descriptions, so the baseline is 3, but the description adds essential operational nuances: offset must be taken from the previous response rather than computed manually, and engine modes are clarified with examples. This goes beyond the schema's basic definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Opens a single page by a known URL and returns its text as clean markdown' — a specific verb, resource, and output format. It also distinguishes itself from sibling tools like read_urls (multiple pages), extract (specific fields), and fetch_page (layout).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' and 'Do not use when' conditions, naming alternatives: web_search when no URL, read_urls for multiple pages, extract for specific fields, and fetch_page for layout. Also notes cost comparison with fetch_page, giving clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_urlsПрочитать несколько страниц / Read several pagesARead-onlyIdempotentInspect
Читает пачку страниц (до 5 за вызов) параллельно и возвращает текст каждой чистым markdown. То же, что read_url, но одним вызовом вместо нескольких — заметно быстрее по общему времени.
Когда: на руках список ссылок, например топ выдачи web_search. Когда не: страница одна — read_url; нужны отдельные поля, а не текст, — extract (он тоже принимает список). Возвращает: текст по каждой странице. Частичный успех — норма: упавшие ссылки не рвут вызов, а перечисляются отдельным блоком «Не прочитано» с кодом ошибки. Дубликаты и ссылки сверх лимита отбрасываются, их число указано в ответе. Длинные страницы обрезаются по maxChars; дочитывать их удобнее по одной через read_url с offset — в батче offset один на все ссылки. Цена: 1 кредит за каждую ссылку — пять страниц стоят пять кредитов. Не отправляйте ссылки «на всякий случай».
Reads a batch of pages (up to 5 per call) in parallel and returns each one's text as clean markdown. Same as read_url but in a single call — markedly faster in total wall-clock.
Use when: you have a list of links, e.g. the top web_search results. Do not use when: there is only one page — read_url; you need specific fields rather than text — extract (it also accepts a list). Returns: text per page. Partial success is normal: failed links do not fail the call, they are listed in a separate "not read" block with an error code. Duplicates and links beyond the limit are dropped and the count is reported. Long pages are cut at maxChars; finish reading them one at a time via read_url with offset — in a batch the offset applies to every link at once. Cost: 1 credit per link — five pages cost five credits. Do not pad the list.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Список URL (1–5). Дубликаты отбрасываются. / A list of URLs (1–5). Duplicates are dropped. | |
| 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. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive; the description adds important behavioral facts: partial success with a 'Не прочитано' block and error codes, duplicate/over-limit dropping with reported counts, maxChars truncation, batch-wide offset semantics, and per-link credit cost. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with purpose, then usage, returns, and cost. However, the full RU and EN duplication makes it longer than necessary, even though each section is information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and no output schema, the description covers return shape (text per page), failure behavior, truncation, duplicates, cost, and usage boundaries. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 applies. The description mostly restates schema info (duplicates, maxChars batch caveat) and adds tool-level behavioral details (cost, offset) rather than new parameter semantics, so it doesn't elevate the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Читает пачку страниц... возвращает текст каждой чистым markdown'), identifies the batching capability, and explicitly distinguishes itself from read_url and extract. This is a clear verb+resource+scope statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use ('когда на руках список ссылок') and when-not-to-use alternatives (read_url for a single page, extract for structured fields). It also adds practical cost guidance ('не отправляйте ссылки на всякий случай').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_claimПроверить утверждение по источникам / Verify a claim against sourcesARead-onlyIdempotentInspect
Проверяет утверждение: ищет источники, читает несколько независимых страниц и возвращает вердикт с дословными цитатами. Каждая цитата сверена с текстом страницы — не найденная в тексте отбрасывается вместе со своим доводом.
Когда: факт, который нельзя брать на веру — цифра, дата, «X поддерживает Y», утверждение из ответа пользователя или из вашей же памяти. Особенно если ваш контекст не вмещает 4–5 страниц целиком: вся черновая работа делается на нашей стороне, к вам приходят только вердикт и цитаты. Когда не: нужен обзор темы — deep_research; нужен текст конкретной страницы — read_url. Вердикт: supported — источники подтверждают; refuted — опровергают; mixed — расходятся между собой; unverified — подтверждения не нашлось. Последние два — нормальный результат, а не ошибка: значит, утверждение нельзя считать проверенным. Считает в независимых доменах: три цитаты с одного сайта — один голос. Смотрите agreeing/disagreeing и confidence, а не только вердикт. Возвращает: вердикт, уверенность, цитаты со ссылками и оговорки. Источников — 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. Returns: verdict, confidence, quotes with links and caveats. Sources: 2–5. Time: 15–60 с / 15–60 s. Cost: 8 credits (search, source reading and model work).
ParametersJSON Schema
| 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. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
При наличии аннотаций readOnly/idempotent открытое описание идёт значительно дальше: раскрывает внутреннюю логику — проверка цитат против текста страницы, один голос с одного домена при трёх цитатах, смысл значений вердикта (mixed/unverified — норма, а не ошибка), поля agreeing/disagreeing/confidence, а также ресурсные ограничения (15–60 с, 8 кредитов). Указано, что цитата, не найденная в тексте страницы, отбрасывается вместе со своим доводом. Противоречий с аннотациями нет.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Описание длинное, но не рыхлое: структура из блоков «Когда/Когда не/Вердикт/Считает/Возвращает/Время/Цена» легко сканируется, каждый блок несёт уникальную пользу. Минус за неизбежный дубль EN/RU, который удваивает объём, но при этом делает описание доступным для обеих языковых групп — справедливый компромисс.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
При отсутствии output schema описание закрывает все смысловые пробелы: перечисляет значения вердикта с пояснением, называет поля ответа (вердикт, confidence, цитаты со ссылками, оговорки), диапазон источников (2–5) и метрики (время, стоимость). Для полной завершённости не хватает лишь формальной JSON-схемы ответа и сценария, когда источников не нашлось вовсе, но в контексте задачи это не критично.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Схема покрывает 100% параметров, каждый описан с примерами и оговорками (claim — с примером формулировки и противопоставлением «не вопрос и не тема», timeRange — про устаревающие данные, maxSources — с описанием trade-off и значения по умолчанию). Это выше базового уровня «покрытия» благодаря наглядным формулировкам и возможности влиять на качество проверки.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Специфический глагол «проверяет» + ресурс «утверждение по источникам» с детальным описанием механики (ищет, читает, возвращает вердикт с цитатами). Прямо называет альтернативы (deep_research, read_url) и отличает себя от них по сценарию использования, а не только по имени.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Явные блоки «Когда:» и «Когда не:» задают чёткие условия (факты/числа/даты, «X поддерживает Y»), приводят критерий вместимости контекста (4–5 страниц) и прямо указывают, какой инструмент использовать вместо (deep_research для обзора темы, read_url для конкретной страницы). Никаких догадок — всё сформулировано явно.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchВеб-поиск / Web searchARead-onlyInspect
Ищет страницы в живом вебе по текстовому запросу и возвращает ранжированный список: заголовок, ссылка, фрагмент. Сильное покрытие русскоязычного веба.
Когда: нужны свежие факты, ссылки или данные новее вашей отсечки знаний. Когда не: адрес страницы уже известен — это read_url; нужны 2–5 конкретных значений — extract; нужен готовый разбор темы со сносками — deep_research. Возвращает: до 30 результатов текстом, без содержимого страниц. С excerpts: true добавляет реальный текст топ-страниц (+2–4 с), это часто экономит последующий вызов read_url. Цена: 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. With excerpts: true it also pulls the actual text of the top pages (+2–4 s), which often saves a follow-up read_url. Cost: 1 credit per call regardless of num. Results are live, so repeating the same query returns different results and is billed again.
ParametersJSON Schema
| 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 | Забрать реальный текст топ-страниц под запрос (медленнее на пару секунд, но даёт готовый контент для ответа без доп. переходов). По умолчанию выкл. / 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. | |
| language | No | Язык / Language: auto, ru, en | |
| timeRange | No | Свежесть / Recency: all, day, week, month, year | |
| 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. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and openWorldHint=true, and the description adds complementary context: results are live so repeats return different results, each call costs 1 credit regardless of num, and excerpts: true pulls page text and can save a follow-up read_url. This goes beyond the structured annotations and matches idempotentHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core behavior and uses clear labeled sections (When/When not, Returns, Cost). It is longer than minimal and bilingual, which adds redundancy, but every substantive point earns its place and the structure makes it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return shape ('up to 30 results as text... title, link, snippet') and its limits ('without page content'). Parameter coverage is complete via the schema, and the description covers cost, liveness, and routing, so an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining the cost behavior of num ('1 credit per call regardless of num') and the practical trade-off of excerpts: true ('often saves a follow-up read_url'), which helps the agent choose parameters more intelligently than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Searches the live web by a text query and returns ranked results: title, link, snippet.' Also differentiates from siblings by being the general web-search entry point, and the phrase 'Strong coverage of the Russian-language web' adds a distinguishing scope cue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('fresh facts, links or data past your knowledge cutoff') and when not to, naming three alternatives with their conditions: read_url for known URLs, extract for 2–5 concrete values, deep_research for a synthesized answer across sources. This is exemplary routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
answer_search6 fields changed- added
Input schema / properties / depth / defaultAdded value: +"balanced" - changed
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." - added
Input schema / properties / language / defaultAdded value: +"auto" - changed
Input schema / properties / language / descriptionPrevious value: -"Язык поиска / Search language (default: auto)"New value: +"Язык поиска и ответа / Search and answer language: auto, ru, en" - changed
Input schema / properties / query / descriptionPrevious value: -"Вопрос или задача / Question or search task"New value: +"Вопрос или поисковый запрос / Question or search query" - changed
Input schema / properties / query / maxLengthPrevious value: -500New value: +2000
1 tool update
- Added
answer_search
1 tool update
- Removed
answer_search
1 tool update
- Added
answer_search
1 tool update
- Changed
deep_research1 field changed- changed
Input schema / properties / ticket / typePrevious value: -"string"New value: +[ + "string", + "number" +]
1 tool update
- Changed
deep_research4 fields changed- changed
Input schema / properties / query / descriptionPrevious value: -"Вопрос или тема исследования / The question or research topic"New value: +"Вопрос или тема исследования. Обязателен для НОВОГО исследования; при дозаборе по ticket не нужен. / The question or research topic. Required to START research; omit it when polling by ticket." - removed
Input schema / properties / query / minLengthRemoved value: -1 - added
Input schema / properties / ticketAdded value: +{ + "description": "Талон незавершённой задачи из прошлого ответа `[research_pending]`. Передайте его, чтобы дождаться готового результата — бесплатно, без нового списания. / Ticket of an unfinished job from a previous `[research_pending]` response. Pass it to wait for the finished result — free, no new charge.", + "type": "string" +} - removed
Input schema / requiredRemoved value: -[ - "query" -]
3 tool updates
- Changed
image_search1 field changed- changed
Input schema / properties / timeRange / descriptionPrevious value: -"Свежесть / Recency: '', day, week, month, year"New value: +"Свежесть / Recency: all, day, week, month, year"
- Changed
verify_claim1 field changed- changed
Input schema / properties / timeRange / descriptionPrevious value: -"Свежесть источников — для утверждений, которые могли устареть (цены, версии, должности): '', day, week, month, year. / Source recency — for claims that may have gone stale (prices, versions, job titles): '', day, week, month, year."New value: +"Свежесть источников — для утверждений, которые могли устареть (цены, версии, должности): all, day, week, month, year. / Source recency — for claims that may have gone stale (prices, versions, job titles): all, day, week, month, year."
- Changed
web_search1 field changed- changed
Input schema / properties / timeRange / descriptionPrevious value: -"Свежесть / Recency: '', day, week, month, year"New value: +"Свежесть / Recency: all, day, week, month, year"
3 tool updates
- Changed
image_search1 field changed- changed
Input schema / properties / timeRange / enumPrevious value: -[ - "", - "day", - "week", - "month", - "year" -]New value: +[ + "all", + "day", + "week", + "month", + "year" +]
- Changed
verify_claim1 field changed- changed
Input schema / properties / timeRange / enumPrevious value: -[ - "", - "day", - "week", - "month", - "year" -]New value: +[ + "all", + "day", + "week", + "month", + "year" +]
- Changed
web_search1 field changed- changed
Input schema / properties / timeRange / enumPrevious value: -[ - "", - "day", - "week", - "month", - "year" -]New value: +[ + "all", + "day", + "week", + "month", + "year" +]
3 tool updates
- Changed
read_url2 fields changed- added
Input schema / properties / freshAdded value: +{ + "description": "Прочитать страницу заново, не беря недавно прочитанный текст. Нужно, когда страница только что изменилась. На цену не влияет: кредит списывается в любом случае. / 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.", + "type": "boolean" +} - added
Input schema / properties / offsetAdded value: +{ + "description": "С какого символа продолжить чтение. Берите значение из предыдущего ответа этого тула («продолжить: 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.", + "minimum": 0, + "type": "integer" +}
- Changed
read_urls1 field changed- added
Input schema / properties / freshAdded value: +{ + "description": "Читать все страницы батча заново, не беря недавно прочитанный текст. На цену не влияет. / Read every page in the batch anew instead of using recently read text. Does not affect the price.", + "type": "boolean" +}
- Added
verify_claim
8 tool updates
- First observed
deep_research - First observed
extract - First observed
fetch_page - First observed
get_usage - First observed
image_search - First observed
read_url - First observed
read_urls - First observed
web_search
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
1168The best web search for your AI Agent
Structured web research tool for AI agents: search, fetch and shape web data into the JSON schema…
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
Related MCP Servers
Anakinofficial
AlicenseNot gradedqualityBmaintenanceWeb data for AI agents: scrape, crawl, search, deep research, site monitoring, browser automation823Apache 2.0- AlicenseNot gradedqualityBmaintenanceProvides web search and content extraction for AI agents.MIT
- AlicenseNot gradedqualityCmaintenanceWeb search, clean page reading & one-call research dossiers for AI agents. No API key — your agent does the synthesis.93MIT