срезAI — Search API for AI agents
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.
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.
Tool Definition Quality
Average 4.4/5 across 8 of 8 tools scored. Lowest: 3.9/5.
Each tool has a clearly distinct purpose: deep research, structured extraction, screenshot, usage info, image search, single page reading, batch reading, and web search. No overlaps.
All tools use snake_case, but patterns mix verb_noun (fetch_page, read_url) and noun_verb (image_search, web_search). Mostly consistent but not perfectly uniform.
8 tools is ideal for a search and web content API. Each tool addresses a specific need without bloat or missing essentials.
Covers search, reading, extraction, research, and account info. Minor gaps like no dedicated HTML retrieval or file download, but core workflows are covered.
Available Tools
8 toolsdeep_researchГлубокое исследование / Deep researchAInspect
Запускает агентное исследование по запросу: ищет в вебе, читает источники и возвращает связный ответ со ссылками. Занимает от 10 секунд до 2 минут — используй для сложных аналитических вопросов, а не для быстрых фактов. / Runs an agentic research task: searches the web, reads sources and returns a coherent answer with links. Takes 10 seconds to 2 minutes — use it for complex analytical questions, not for quick facts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Вопрос или тема исследования / The question or research topic |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the time range and that it searches and synthesizes, but does not mention rate limits, auth needs, error handling, or result structure. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences per language, totaling around 50 words. It is front-loaded with the core action and every sentence adds value. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (agentic, multi-step), yet the description lacks details about return format, timeout behavior, or limitations. It mentions 'coherent answer with links' but no structure. Adequate for a minimal viable description but could be richer given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for 'query'. The description reiterates the purpose ('The question or research topic') without adding new constraints or examples. Baseline 3 is appropriate since the schema already defines the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Runs an agentic research task: searches the web, reads sources and returns a coherent answer with links.' This distinguishes it from sibling tools like web_search (returns raw results) and read_url (reads single pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'use it for complex analytical questions, not for quick facts' and notes the time range (10 sec to 2 min). It implies when not to use but doesn't explicitly name alternative tools.
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 schemaAInspect
Читает страницу и возвращает структурированные данные строго по вашей схеме: только запрошенные поля, без текста страницы. Используй, когда нужны КОНКРЕТНЫЕ значения (цена, характеристики, автор и дата, список вакансий), а не содержание целиком — это экономит контекст по сравнению с read_url. Чего на странице нет, приходит как null: значения не выдумываются. Можно передать до 5 ссылок сразу — одна схема применится ко всем. / Reads the page and returns structured data strictly following your schema: only the requested fields, no page text. Use it when you need SPECIFIC values (price, specs, author and date, a list of job openings) rather than the whole content — it saves context compared to read_url. Anything absent from the page comes back as null: values are never invented. You can pass up to 5 links at once — one schema applies to all of them.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that only requested fields are returned, no page text, null for absent values, and that each URL is billed separately. It does not cover error handling or authentication, but the key behavioral traits are well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual (Russian and English), which appropriately serves the audience but adds length. It is front-loaded with the core purpose and use cases. Every sentence adds value, though some repetition exists between languages. Overall, it is well-structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is quite complete. It explains the schema parameter in detail, engine choices, and the optional instruction. It does not provide output examples, but that is acceptable without an output schema. The tool's behavior is sufficiently described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant meaning: it explains the shorthand and full JSON Schema format for the schema parameter, enumerates engine options, and provides examples for the instruction parameter. This goes beyond the schema's basic type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a page and returns structured data strictly following a user-defined schema. It specifies the action 'returns structured data' and the resource 'page content', and distinguishes itself from sibling read_url by noting context savings. The use cases (price, specs, job listings) make the purpose concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool when specific values are needed rather than full page content, and contrasts with read_url. It also notes that missing fields return null and that up to 5 URLs can be processed. However, it does not explicitly state when not to use it or mention prerequisites.
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 structureAInspect
Открывает страницу в реальном браузере и возвращает её скриншот (картинкой), ссылку на полноразмерный скриншот и текст страницы в markdown. Используй, когда нужно УВИДЕТЬ страницу — раскладку, цвета, типографику, визуальную иерархию (например «повтори дизайн как на этом сайте»), а не просто найти информацию. Стоит 3 кредита — если нужен только текст, дешевле read_url (1 кредит). / Opens the page in a real browser and returns its screenshot (as an image), a link to the full-size screenshot and the page text in markdown. Use it when you need to SEE the page — layout, colours, typography, visual hierarchy (e.g. «copy the design of this site») — not just find information. Costs 3 credits; if you only need the text, read_url is cheaper (1 credit).
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool costs 3 credits, uses a real browser, and returns a screenshot image, link, and markdown text. It does not mention potential limitations (e.g., JavaScript rendering issues, timeouts) but provides adequate transparency for most use cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences in each language front-loaded with key information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters, no output schema, and no nested objects. The description adequately explains the inputs and the return type (screenshot image, link, markdown text), making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds value by specifying the default and range for maxChars (200–50000, default 4000) and advising when to raise it. It also confirms that the url must be a full URL (http/https).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens a page in a real browser and returns a screenshot, link to full-size screenshot, and page text in markdown. It distinguishes itself from the sibling tool read_url by noting that read_url is cheaper if only text is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use (when you need to SEE the page visually) and when not to (if only text is needed, use read_url). It also mentions the cost difference (3 credits vs 1 credit).
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 limitsAInspect
Показывает остаток на счёте, расход суточной квоты и цены инструментов в кредитах. Вызывай, когда запрос упал по лимиту или квоте, когда пользователь спрашивает про баланс и расходы, или перед большим батчем запросов. Сам вызов бесплатный и лимит не расходует. / Shows the remaining balance, daily quota usage and tool prices in credits. Call it when a request failed on a limit or quota, when the user asks about balance and spending, or before a large batch of requests. This call is free and does not consume the limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the call is free, does not consume limit, and shows usage data. No side effects are expected. This is transparent for a simple read-only status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences (plus Russian translation). The first sentence states the core function, the second provides usage guidelines. No superfluous words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers what it returns (balance, quota, prices) and when to use it. However, it lacks detail on the output format (e.g., units, whether numbers are integers), but it is still sufficient for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully documents them. The description adds no parameter details beyond what the schema provides, which is acceptable. Baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'shows remaining balance, daily quota usage and tool prices in credits'. It specifies the verb 'shows' and the resource (balance, usage, prices). The tool is distinct from siblings, which are search and fetch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides three scenarios: when a request fails on a limit/quota, when the user asks about balance/spending, or before a large batch of requests. Also notes the call is free and does not consume the limit, which is crucial guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image_searchПоиск изображений / Image searchAInspect
Поиск изображений в интернете по текстовому запросу. Возвращает список картинок с прямыми ссылками, источником и разрешением. Сами картинки не скачивает и не показывает — только ссылки. / Searches the web for images by a text query. Returns a list of images with direct links, source page and resolution. It does not download or display the images — links only.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns only links (not downloading/displaying images) and provides resolution details. Additional behavioral traits like rate limits or auth needs are not mentioned, but for a simple read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences per language, front-loaded with the main purpose, and every sentence adds value. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple image search tool with 4 well-described parameters and no output schema, the description sufficiently covers what the tool does, what it returns, and what it does not do. The agent has enough to understand its behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds helpful usage guidance (e.g., for num: 'Need just one — ask for 1–3 and save context', safe: 'on by default', timeRange: 'Recency: ..., day, week, month, year'). This adds meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for images by text query and returns a list with direct links, source, and resolution. It distinguishes from sibling tools like web_search by focusing solely on image results and explicitly noting it does not download or display images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (searching for images). It does not explicitly mention when not to use it or alternatives, but the purpose is clear enough that an agent would infer usage for image retrieval.
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 pageAInspect
Открывает страницу и возвращает её текст в чистом markdown — без навигации, рекламы и HTML. Используй, когда нужно ПРОЧИТАТЬ конкретную страницу по известной ссылке: статью, документацию, карточку товара. Дешевле и быстрее fetch_page, потому что не делает скриншот; если нужно именно УВИДЕТЬ вёрстку и дизайн — бери fetch_page. / Opens a page and returns its text as clean markdown — no navigation, ads or HTML. Use it when you need to READ a specific page by a known link: an article, documentation, a product page. Cheaper and faster than fetch_page because it takes no screenshot; if you need to SEE the layout and design, use fetch_page instead.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Полный URL страницы (http/https) / Full page URL | |
| 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. | |
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool strips navigation, ads, HTML, and returns clean markdown, and that it does not take a screenshot. It could mention rate limits or failure modes, but the key behavioral traits are sufficiently covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual, doubling its length, but each sentence is purposeful. It front-loads the core function and usage. It is slightly verbose but remains focused and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations) and 7 siblings, the description provides complete context: it explains the output format (markdown), contrasts with fetch_page, and lists typical use cases. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add much parameter-specific meaning beyond what the schema already provides; it focuses on the overall purpose. The schema descriptions are comprehensive, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('reads a page') and resource (returns clean markdown). It distinguishes itself from the sibling fetch_page by mentioning it does not take a screenshot, and provides specific use cases like articles, documentation, product pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (when you need to read a specific page by a known link) and when to use an alternative (fetch_page for seeing layout/design). It also highlights that it is cheaper and faster, guiding the agent's decision.
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 pagesAInspect
Читает сразу несколько страниц (до 5) и возвращает текст каждой в чистом markdown. Используй, когда нужно прочитать пачку ссылок — например топ результатов поиска: это один вызов вместо пяти. Страницы читаются параллельно; если какая-то не открылась, остальные всё равно вернутся, а неудачные перечислены в конце ответа. Каждая страница тарифицируется как отдельное чтение. / Reads several pages at once (up to 5) and returns each one's text as clean markdown. Use it when you need a batch of links — the top search results, say: one call instead of five. Pages are read in parallel; if one fails the rest still come back, and the failures are listed at the end of the response. Each page is billed as a separate read.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Список URL (1–5). Дубликаты отбрасываются. / A list of URLs (1–5). Duplicates are dropped. | |
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses parallel reading, failure handling (rest still return, failures listed), and billing per page. Does not mention auth or rate limits, but appropriate for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Bilingual description is efficient, front-loading purpose then usage then behavior. Slightly redundant due to language repetition, but each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description hints at return (markdown text per page and failures list). Could be more specific about output format structure. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds extra context: duplicates dropped for urls, warning about context size for maxChars, and explanation of engine applying to all links. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (reads), resource (several pages up to 5), and outcome (returns text as clean markdown). It distinguishes from siblings like read_url (single page) and fetch_page by emphasizing batch nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for a batch of links like top search results, contrasting with five separate calls. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchВеб-поиск / Web searchAInspect
Поиск актуальной информации в интернете. Возвращает список результатов (заголовок, ссылка, фрагмент) из нескольких источников. Используй, когда нужны свежие данные, факты или ссылки по теме. Не читает страницы целиком — для этого read_url. / Searches the web for current information. Returns a list of results (title, link, snippet) from several engines. Use it when you need fresh data, facts or links on a topic. It does not read full pages — use read_url for that.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides some behavioral insight: returns results from multiple engines, distinguishes from read_url, and mentions excerpts parameter for pulling page text. However, it does not discuss rate limits, authentication, caching, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It first states the action and return type, then usage guidance, then a limitation. Every sentence is useful and adds value. Bilingual but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, return type, and differentiates from siblings. With no output schema, it adequately describes what the tool returns. For a tool with many parameters, it provides sufficient context to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully describes each parameter. The description adds context for depth (speed vs breadth) and excerpts (slower but gives ready content), but does not re-describe parameters. Baseline 3 with marginal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the web for current information and returns a list of results with title, link, and snippet. It distinguishes from sibling 'read_url' by explicitly stating it does not read full pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'Use it when you need fresh data, facts or links on a topic.' It also advises when not to use it: 'It does not read full pages — use read_url for that.' Additionally, the depth parameter is described with guidance on when to use flash vs auto.
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!