Anakinofficial
A
license-
qualityB
maintenanceWeb data for AI agents: scrape, crawl, search, deep research, site monitoring, browser automation
253
3
Apache 2.0
срез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
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.7/5 across 8 of 8 tools scored.
Server CoherenceA
Disambiguation5/5
Every tool has a clearly distinct purpose: web search returns links, image search returns image metadata, read_url/read_urls fetch page text, extract pulls structured fields, fetch_page provides visual screenshots, deep_research synthesizes multiple sources, and get_usage reports billing. The descriptions explicitly cross-reference alternatives, eliminating ambiguity in tool selection.
Naming Consistency3/5
Tool names are readable but follow mixed conventions: bare verb (extract), verb+noun (fetch_page, get_usage, read_url, read_urls), noun+verb (web_search, image_search), and adjective+noun (deep_research). While not chaotic, the set lacks a single predictable naming pattern.
Tool Count5/5
With 8 tools, the count is well-scoped for a search/reading API. Each tool covers a distinct operation without redundancy, and the size feels neither sparse nor bloated relative to the server's purpose.
Completeness5/5
The surface covers the full research workflow: searching the web and images, reading single or multiple pages, structured extraction, deep-research synthesis, and account/quota management. No obvious gaps exist for the stated domain of providing search and page content to AI agents.
Available Tools
9 toolsdeep_researchГлубокое исследование / Deep researchARead-onlyInspect
Проводит многошаговое исследование: сам формулирует запросы, ищет, читает источники и возвращает готовый связный ответ со ссылками на использованные страницы.
Когда: вопрос требует сопоставления нескольких источников и вывода — «сравни», «разберись», «что известно о». Когда не: нужен один факт или список ссылок — это web_search, он в 20 раз дешевле и отвечает за секунды. Возвращает: текст ответа плюс список источников. Если источники не вернулись, в ответе будет предупреждение — такой вывод не считается проверенным. Время: 10 с – 2 мин, это самый медленный инструмент. Держите соединение открытым. Цена: 20 кредитов плюс 3 за каждую 1000 токенов ответа — самый дорогой вызов. Повтор темы даёт новый результат и списывается заново.
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. Returns: the answer text plus a source list. If no sources came back the response says so — treat that output as unverified. Time: 10 s – 2 min, the slowest tool here. Keep the connection open. Cost: 20 credits plus 3 per 1000 output tokens — the most expensive call. Repeating a topic produces a new result and is billed again.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Вопрос или тема исследования / The question or research topic |
Tool Definition Quality
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld and non-destructive, but the description adds substantial behavioral context: expected time range (10s–2min), cost structure, warnings about unverified outputs when sources missing, and the fact that repeating a topic yields a new billed result. This goes well beyond the annotations and is highly actionable.
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 (What, When, Returns, Time, Cost) and front-loaded details. It is somewhat longer due to bilingual content, but every section earns its place by conveying unique operational information.
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, slow, expensive research tool with no output schema, the description covers purpose, use cases, alternatives, return format, error condition (no sources), time expectations, and cost. It fully equips an agent to decide when to invoke and what to expect from the result.
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?
With 100% schema coverage and a single 'query' parameter described as 'question or research topic', the description adds little beyond the schema. It does contextualize the query as a multi-source research question, but no syntax or format details are added, so 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 states a specific verb and resource: 'conducts multi-step research', explicitly mentioning forming queries, searching, reading sources, and returning a finished answer with links. It clearly distinguishes itself from web_search by contrasting use cases, making the 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 ('requires several sources reconciled into a conclusion') and when-not-to-use ('single fact or list of links'), naming web_search as the cheaper, faster alternative. This is textbook usage guidance.
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». |
Tool Definition Quality
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. |
Tool Definition Quality
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 | |||
Tool Definition Quality
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: '', day, week, month, year |
Tool Definition Quality
A4.6/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 description adds value by clarifying that files are never downloaded or embedded, and by mentioning the credit cost. This goes beyond the annotations without contradicting them.
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, Returns, Cost) and is front-loaded with purpose. It is bilingual, which doubles length, but each section earns its place and avoids redundant 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?
No output schema exists, so the description compensates by explaining return content (links and metadata only). It also covers limits, cost, and safe search behavior, making it complete for a search tool with multiple operational nuances.
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 covers 100% of parameters, so baseline is 3. The description adds meaningful guidance on num (use 1-3 for single image, default 12, max 48, context cost) and notes safe search is on by default, which are useful beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for images by text query and returns direct file links, source page, and resolution. It distinguishes from siblings by explicitly contrasting with web_search (text/facts) and fetch_page (page appearance).
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 (pictures, photos, logos, diagrams) and when-not-to-use, naming web_search and fetch_page as alternatives. This gives 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_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. |
Tool Definition Quality
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. |
Tool Definition Quality
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 | Свежесть источников — для утверждений, которые могли устареть (цены, версии, должности): '', day, week, month, year. / Source recency — for claims that may have gone stale (prices, versions, job titles): '', 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. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral detail beyond annotations: quote verification against page text, dropping unverified quotes, counting independent domains, verdict semantics (mixed/unverified are normal), time and cost, and source count bounds. No contradictions.
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 long but every section earns its place: purpose, verdicts, counting logic, return value, time/cost, usage boundaries. Labeled sections ('Use when', 'Verdict', etc.) improve scannability. No filler or redundant restating of tool name.
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 compensates by enumerating the return payload (verdict, confidence, quotes with links, caveats), verdict explanations, independence counting, typical source count, and expected latency/cost. It handles edge cases (mixed/unverified as normal outcomes) and provides enough operational detail for an agent to use the tool 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% with detailed per-parameter explanations (e.g., claim phrasing, query fallback, language, timeRange, maxSources). The description adds extra semantics for maxSources ('Fewer is faster, more is sturdier. Does not affect the price') and clarifies claim formulation requirements. This is a solid contribution above the schema baseline.
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 opens with a specific verb+resource: 'Проверяет утверждение: ищет источники, читает несколько независимых страниц и возвращает вердикт с дословными цитатами.' It clearly states what the tool does and distinguishes itself from siblings by naming alternatives (deep_research, read_url). Purpose is unambiguous 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?
Explicit 'Use when' and 'Do not use when' sections provide concrete triggers (e.g., 'a fact you should not take on trust — a number, a date') and exclusions with named alternatives ('deep_research for an overview, read_url for a single page'). This gives the agent clear decision rules for tool selection.
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: '', 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. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses live result variability ('repeating the same query returns different results and is billed again'), cost per call, result count limits, and the excerpts behavior that can save a follow-up read_url. 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 clear sections (When/When not, Returns, Cost) and front-loaded. It is longer due to bilingual duplication, but every sentence in each language carries useful information, so it remains appropriately sized.
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 9 parameters and no output schema, the description covers all essential operational aspects: live results, result count, content limitations, excerpt option, cost, and recency behavior. Combined with the rich schema descriptions, this gives an agent everything it needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds decision-oriented meaning: 'Cost: 1 credit per call regardless of num', 'up to 30 results as text', and that excerpts 'often saves a follow-up read_url'. This connects parameters like num and excerpts to real usage trade-offs.
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 opens with 'Searches the live web by a text query and returns ranked results: title, link, snippet', which is a specific verb+resource+scope. It also explicitly contrasts with sibling tools in the usage guidance, clarifying its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use ('need fresh facts, links or data past your knowledge cutoff') and when-not-to-use with named alternatives ('read_url', 'extract', 'deep_research'). This clearly differentiates the tool from its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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 Servers
- Alicense-qualityBmaintenanceProvides web search and content extraction for AI agents.MIT
- Alicense-qualityCmaintenanceWeb search, clean page reading & one-call research dossiers for AI agents. No API key — your agent does the synthesis.97MIT
- Flicense-qualityCmaintenanceEnables AI agents to perform web searches, extract webpage content, and conduct end-to-end search-and-extract operations using multiple search providers and content extraction methods.