Skip to main content
Glama
srezai-team

srezai-mcp

Official
by srezai-team
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

srezai-mcp

MCP-сервер срезAI: веб-поиск, чтение страниц, скриншоты и извлечение данных по схеме как встроенные инструменты ИИ-агента.

MCP server for SrezAI — web search, page reading, screenshots and schema-based extraction as native agent tools.

Нужен ли вам этот пакет / Do you need this package

Скорее всего нет. Если ваш клиент умеет Streamable HTTP (Claude Desktop, современные IDE-агенты) — подключайтесь к серверу напрямую, без установки:

{
  "mcpServers": {
    "srezai": {
      "url": "https://srezai.ru/api/mcp",
      "headers": { "Authorization": "Bearer srz_live_ваш_ключ" }
    }
  }
}

Пакет нужен там, где клиент умеет только stdio и не поддерживает удалённые серверы по HTTP.

Related MCP server: tavily-mcp

Установка / Installation

{
  "mcpServers": {
    "srezai": {
      "command": "npx",
      "args": ["-y", "srezai-mcp"],
      "env": { "SREZAI_API_KEY": "srz_live_ваш_ключ" }
    }
  }
}

Ключ создаётся в личном кабинете. Нужен Node 18+.

Если Windows капризничает с переменными окружения, в некоторых клиентах помогает такая форма:

cmd /c "set SREZAI_API_KEY=srz_live_ваш_ключ && npx -y srezai-mcp"

Инструменты / Tools

Инструмент

Что делает

web_search

Поиск актуальной информации: заголовок, ссылка, фрагмент

image_search

Поиск картинок: прямые ссылки, источник, разрешение

read_url

Страница → чистый Markdown без навигации и рекламы

read_urls

То же, до 5 страниц за вызов

fetch_page

Скриншот и Markdown через реальный браузер

extract

Только запрошенные поля по вашей схеме, без выдуманных значений

deep_research

Агентное исследование по многим источникам, 10 с – 2 мин

get_usage

Баланс, квота и цены. Бесплатно, лимит не расходует

Описания, параметры и цены живут на сервере, а не в пакете: агент видит их через tools/list в момент подключения. Новый инструмент появляется у вас без обновления srezai-mcp.

Как это работает / How it works

Пакет — тонкий мост: читает JSON-RPC из stdin, пересылает на https://srezai.ru/api/mcp с вашим ключом, возвращает ответ в stdout. Собственной логики инструментов в нём нет — поэтому он не может разойтись с тем, что на самом деле умеет API.

Зависимостей во время работы — ноль: только встроенные модули Node.

Готовый mcp-remote здесь не подошёл: он начинает с OAuth-регистрации клиента и не умеет статический Bearer-ключ, на котором работает срезAI.

Настройка / Configuration

Переменная

Назначение

SREZAI_API_KEY

Ключ доступа. Нужен для вызова инструментов

SREZAI_MCP_ENDPOINT

Другой адрес сервера. По умолчанию https://srezai.ru/api/mcp

Без ключа мост всё равно запускается и отдаёт initialize и tools/list: список инструментов сервер публикует анонимно, так его читают каталоги MCP. Вызов любого инструмента в этом режиме вернёт ошибку с указанием задать SREZAI_API_KEY. / Without a key the bridge still starts and serves initialize and tools/list — the tool list is public, which is how MCP directories read it. Calling a tool returns an error asking you to set SREZAI_API_KEY.

Разработка / Development

npm ci && npm test && npm run build

Docker-образ (его собирают каталоги MCP, опрашивая сервер в песочнице) / Docker image, built by MCP directories to introspect the server in a sandbox:

docker build -t srezai-mcp . && docker run --rm -i -e SREZAI_API_KEY=srz_live_ваш_ключ srezai-mcp

Правки принимаются здесь, на GitHub: CONTRIBUTING.md объясняет, почему копия на GitVerse — зеркало и как прислать патч, если GitHub недоступен. Об уязвимости — SECURITY.md, не публичным issue. Правила общения — CODE_OF_CONDUCT.md.

Changes go to GitHub: CONTRIBUTING.md explains why the GitVerse copy is a mirror and how to send a patch if GitHub is unavailable to you. For vulnerabilities see SECURITY.md rather than a public issue. Ground rules: CODE_OF_CONDUCT.md.

Лицензия / License

MIT

Available Tools

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

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

Когда: вопрос требует сопоставления нескольких источников и вывода — «сравни», «разберись», «что известно о». Когда не: нужен один факт или список ссылок — это 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
NameRequiredDescriptionDefault
queryYesВопрос или тема исследования / The question or research topic

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds substantial behavioral detail: time range (10s–2min), cost model, non-idempotence (repeating a topic produces a new result and is billed again), and the caveat that missing sources means the output is unverified. 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 with clear sections (When, Returns, Time, Cost) and front-loaded with the core purpose. However, the content is duplicated in Russian and English, which lengthens it without adding new information, so it barely misses a 5.

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 single-parameter tool with no output schema, the description fully covers behavior, return format, failure mode, time expectations, and cost. Nothing essential is missing for an agent to select and invoke this 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?

The input schema already covers the sole parameter 'query' at 100% with a clear description. The tool description adds little beyond calling it a question/research topic, so the baseline of 3 for high schema coverage 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 it 'runs multi-step research, forms its own queries, searches, reads sources and returns a finished answer with links' – a specific verb+resource that distinguishes it from siblings, especially naming web_search as the alternative for simpler needs.

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' guidance, naming web_search as the cheaper/faster alternative for single facts or link lists. This is exactly the kind of clear contextual differentiation expected.

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

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

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

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context: missing fields return null, values are never invented, it returns one object per link (up to 5), and cost per link. This goes beyond annotations and provides genuine behavioral insight without contradiction.

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 section headings (When, Schema, Returns, Cost) and is front-loaded with the core action. However, it repeats the full content in both Russian and English, doubling its length. This is acceptable for bilingual coverage but slightly verbose.

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 absence of an output schema, the description fully explains return values, batching (up to 5 links), alternatives, and cost. It covers both behavioral and semantic aspects required to use the tool correctly, making it complete for its complexity.

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 provides 100% parameter descriptions, including the shorthand and full JSON Schema formats. The description's schema section largely duplicates the schema text, adding no new parameter-specific meaning beyond what's already structured. Thus, the baseline 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 the tool reads a page and returns JSON strictly following the provided schema, with only the requested fields and no page text. It distinguishes itself from siblings by explicitly contrasting with read_url, making its purpose unmistakable.

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 gives explicit 'use when' and 'do not use when' guidance, names the alternative read_url, and even compares cost (4× cheaper). This is exemplary usage guidance that helps an agent decide between 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 structureA
Read-onlyIdempotent

Открывает страницу полноценным браузером и возвращает скриншот картинкой прямо в ответе, ссылку на полноразмерный файл и текст страницы в 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
NameRequiredDescriptionDefault
urlYesПолный URL страницы (http/https) / Full page URL (http/https)
maxCharsNoСколько символов текста вернуть (200–50000, по умолчанию 4000). Поднимите, если нужен полный текст страницы, а не только начало. / How many characters of text to return (200–50000, default 4000). Raise it if you need the whole page text, not just the beginning.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses cost (3 credits), output format (inline image + file link + markdown), and context consumption ('The image consumes a lot of context, which makes this tool overkill for reading'). No contradictions 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.

Conciseness5/5

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

The description is structured with clear markers ('When:', 'Do not use when:', 'Returns:', 'Cost:') and each sentence carries distinct information. Bilingual repetition is acceptable for internationalization but does not add bloat.

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?

Covers purpose, alternatives, cost, return types, context consumption, and use cases. No output schema is present, but the description adequately explains what the tool returns. Complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents url and maxChars with meanings. The description does not add parameter-specific details beyond what the schema provides, hence baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: '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.' This clearly distinguishes it from read_url and extract by emphasizing the visual output (screenshot) and full-page text.

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' and 'when not to use' guidance, naming alternatives: 'Do not use when: you only need text — read_url (1 credit vs 3, and faster); you need specific values — extract.' This is ideal usage guidance.

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 limitsA
Read-onlyIdempotent

Показывает остаток на счёте, расход суточной квоты, время сброса окна и цены всех инструментов в кредитах. Параметров не требует.

Когда: вызов упал с [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
NameRequiredDescriptionDefault

No parameters

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare read-only and non-destructive behavior, but the description adds crucial context: 'Cost: free — this call consumes neither quota nor rate limit, so call it freely.' It also discloses return values ('Returns: balance, quota used, reset time and the price list') since there is no output schema. 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.

Conciseness5/5

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

The English description is efficiently structured with a purpose statement, 'Use when' scenarios, returns, and cost. Every sentence earns its place, and the information is front-loaded. Though duplicated in Russian, the English portion is concise and well-organized.

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 simple parameter-less tool, the description covers all necessary context: what it does, when to use it, what it returns, and that it's free. It is fully self-contained even without an output schema, making it complete for an agent to select and invoke 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?

The tool has zero parameters, so baseline is 4. The description explicitly confirms this: 'Takes no parameters.' This removes any ambiguity and adds value beyond the empty input schema, warranting a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Shows the remaining balance, daily quota usage, when the window resets, and the price of every tool in credits.' This is a specific verb+resource combination that directly distinguishes it from sibling tools, none of which handle usage or balance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides usage scenarios: 'Use when: a call failed with [rate_limited]...; the user asks about balance or spending; you are about to run a large batch...' This gives clear guidance on when to invoke this tool versus alternatives, fulfilling the dimension completely.

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

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

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

Когда: адрес известен и нужен текст — статья, документация, карточка товара. Когда не: адреса нет — сначала web_search; страниц несколько — read_urls (один вызов вместо пяти); нужны 2–5 конкретных полей — extract (в контекст придут только они); нужно увидеть вёрстку — fetch_page. Возвращает: заголовок и текст, по умолчанию первые 4000 символов. Если нужен весь текст, а не начало, поднимите maxChars — иначе документ придёт обрезанным. Цена: 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. Raise maxChars when you need the whole document, otherwise it arrives truncated. Cost: 1 credit — the cheapest way to get page content (fetch_page costs 3).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesПолный URL страницы (http/https) / Full page URL
engineNoКак забирать страницу: auto (по умолчанию — начинает с быстрого способа и сам поднимается, если текста не оказалось), fast (быстро, для статики и документации), dynamic (ждёт отрисовки JS — для SPA), stealth (медленно, максимально браузерное поведение). Указывайте явно только если знаете сайт. / How to fetch the page: auto (default — starts with the fast path and escalates on its own if no text came back), fast (static sites and docs), dynamic (waits for JS rendering — for SPAs), stealth (slow, most browser-like). Set it explicitly only if you know the site.
maxCharsNoСколько символов текста вернуть (200–50000, по умолчанию 4000). Поднимите, если нужен полный текст, а не только начало. / How many characters of text to return (200–50000, default 4000). Raise it if you need the whole text, not just the beginning.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses meaningful behavioral traits: JavaScript execution for SPAs, default truncation at 4000 characters, cost of 1 credit, and engine escalation behavior. These are not available in structured data and greatly inform the agent.

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 and front-loaded purpose. The bilingual duplication doubles length, but each language version is concise and information-dense. Still slightly longer than necessary for an English-only model.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the absence of an output schema, the description fully covers what the tool returns (title and text), default limits, cost, and alternatives. It is complete for an agent to decide when and how to use 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?

Schema already covers all parameters with clear descriptions (100% coverage). The description additionally clarifies default behavior (auto engine escalates, maxChars default 4000) and cost implications, which adds value beyond 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 clearly states it opens a single page by known URL and returns clean markdown text, distinguishing it from siblings like fetch_page (layout), read_urls (multiple pages), and extract (specific fields). The verb 'opens' and resource 'page' are specific.

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' guidance with named alternatives (web_search, read_urls, extract, fetch_page). This is exactly what a good usage guideline should do.

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

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

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

Когда: на руках список ссылок, например топ выдачи web_search. Когда не: страница одна — read_url; нужны отдельные поля, а не текст, — extract (он тоже принимает список). Возвращает: текст по каждой странице. Частичный успех — норма: упавшие ссылки не рвут вызов, а перечисляются отдельным блоком «Не прочитано» с кодом ошибки. Дубликаты и ссылки сверх лимита отбрасываются, их число указано в ответе. Цена: 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. Cost: 1 credit per link — five pages cost five credits. Do not pad the list.

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

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description builds on this by disclosing partial success behavior (failed links do not fail the call, listed separately with error codes), duplicate/limit dropping with count, parallel fetching, and cost per link. No contradiction; this is rich behavioral context beyond the annotation hints.

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 detailed yet well-structured: what, when/when-not, returns, and cost. Every sentence adds value, and the bilingual format is purposeful. It avoids fluff while covering all necessary aspects in a compact, front-loaded layout.

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 sufficiently explains return values (text per page, 'not read' block with error codes) and handles edge cases (partial success, duplicates, over-limit). Combined with the annotations and thorough schema, the description makes the tool fully usable without additional inference.

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 has 100% description coverage with detailed explanations for all three parameters (urls, engine, maxChars), including defaults and constraints. The description does not add parameter-specific semantics beyond the schema; it mentions cost and general usage, which are not parameter semantics. 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 the tool reads a batch of pages (up to 5) in parallel and returns each page's text as clean markdown. It explicitly distinguishes from read_url by noting it's the same operation but in a single call, and differentiates from extract which returns specific fields. This satisfies the specific verb+resource criterion and sibling differentiation.

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 gives explicit when/when-not guidance: 'Use when: you have a list of links, e.g. the top web_search results.' It names alternatives: read_url for single pages, extract for specific fields, and notes extract also accepts a list. This is a clear, actionable usage policy.

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. 8 tool updatesv0.1.3
    • First observeddeep_research
    • First observedextract
    • First observedfetch_page
    • First observedget_usage
    • First observedimage_search
    • First observedread_url
    • First observedread_urls
    • First observedweb_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Scored across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: deep_research for synthesized multi-source answers, web_search for ranked results, image_search for images, read_url for single-page text, read_urls for batch reading, fetch_page for visual screenshots, extract for structured data, and get_usage for account info. No two tools overlap in a way that would confuse an agent.

Naming Consistency4/5

Most tools follow a verb_noun snake_case pattern (web_search, read_url, read_urls, fetch_page, get_usage), but 'deep_research' is an adjective_noun compound and 'extract' is a bare verb. This is a minor deviation from an otherwise consistent and predictable convention.

Tool Count5/5

With 8 tools, the server is well-scoped for its stated purpose of web research and data extraction. Each tool earns its place, covering search, reading, extraction, and account management without any redundant or bloated additions.

Completeness5/5

The tool surface covers the full research workflow: discovering sources (web_search, image_search), deep investigation (deep_research), reading content (read_url, read_urls, fetch_page), structured extraction (extract), and operational monitoring (get_usage). There are no obvious gaps within the domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/srezai-team/srezai-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server