Russian-language web search for agents: hybrid retrieval, product prices, full page text
Return pages matching a watched query that were indexed since the last check, then advance the cursor. Call with no id to check all of your watches at once.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Watch id; omit to check all. | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: calling this tool advances the cursor, meaning results are consumed and a repeat call will not return the same pages. This adds real value beyond the readOnlyHint=false annotation, which only signals mutation without specifying what state changes occur.
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?
Two sentences, zero filler. The core behavior and side effect are front-loaded, and the no-id variant is appended as a useful operational note. Every clause 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?
For a 2-parameter tool with no output schema, the description covers the action, the side effect, and the primary call variant. The notable gap is the undocumented limit parameter, and the return value is only vaguely implied as 'pages.' Still, the essentials for a correct call are present.
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 50% — the id parameter is already documented in the schema ('omit to check all'), and the description mostly echoes that. The limit parameter has no schema description and no mention in the tool description, so its semantics (limiting how many pages are returned) are left entirely to inference. The description partially compensates but does not fully cover the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Return pages matching a watched query') with a precise scope ('indexed since the last check'). The cursor-advance side effect cleanly separates it from siblings like watch_query (creation) and list_watches (listing). This goes well beyond the vague title 'What is new for a tracked query.'
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 gives clear context on when to use the tool ('indexed since the last check' implies a polling/checking cadence) and provides explicit parameter-level guidance ('Call with no id to check all of your watches at once'). It does not name alternative tools or state when not to use it, but the context is strong enough for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a watch. Pass its id (from list_watches) or the exact query text. Watches accumulated with no way to remove them; this closes that.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Watch id from list_watches. | |
| query | No | Exact watched query, as an alternative to id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, covering mutation and repeated-call safety. The description adds background context about watches being previously unremovable but does not disclose additional behavior such as what happens on missing ids or whether both parameters can be supplied.
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 only three short sentences, with the purpose front-loaded, parameter guidance second, and historical context last. Every sentence adds value and there is no redundant wording.
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 delete operation with idempotent annotation and a fully documented schema, the description covers identification of the target and the source workflow. It does not explain behavior when both or neither parameter is supplied, but that is a minor gap given the tool's simplicity.
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% and both parameters already have descriptive schema text. The description largely restates the schema by saying 'Pass its id (from list_watches) or the exact query text,' so it adds little meaning beyond what the schema provides.
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 opens with the specific verb and resource, 'Remove a watch,' and the title 'Stop tracking a query' reinforces the action. Mentioning the id comes from list_watches distinguishes this from sibling tools like watch_query or check_watch without ambiguity.
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 clearly states how to invoke the tool: either with an id from list_watches or with exact query text. It provides workflow context but does not explicitly list when-not-to-use or name alternative tools, so it stops short of a full when/when-not explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full extracted text of a page already in the index. This serves stored content and does not hit the live site, so it is fast and cannot be blocked. Use it after search to read a result.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of an indexed page. | |
| maxChars | No | Truncate the body to this many characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds meaningful behavioral details: it is fast, cannot be blocked, and serves stored content rather than hitting the live site. The word 'full' is slightly at odds with maxChars truncation, but the schema clarifies that behavior.
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?
Three tight sentences: first states the core function, second gives the key behavioral trait, third gives the usage context. No filler or redundant restating of the schema.
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 two-parameter tool with readOnlyHint, the description covers the main usage, the stored-content behavior, and the workflow position. It does not describe error behavior for missing pages or explicitly mention truncation, but the schema covers maxChars and the description provides enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both url and maxChars are already clearly documented in the schema. The description restates that the url must be an indexed page, but adds little meaning beyond the existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return'), resource ('full extracted text of a page already in the index'), and scope. The distinction from live-site fetching and the mention of serving stored content set it apart from fetch_pages and search.
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 it after search to read a result, giving a clear workflow context. It also clarifies that it serves stored content and does not hit the live site, though it does not name alternative tools for cases such as needing fresh data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Like fetch_page but for up to 20 URLs in one call — the bulk-read counterpart to search_batch, so reading a page of results is one round trip instead of ten. Each page comes back with its cleaned text from the index; URLs not in the index are marked, not fatal.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs of indexed pages. | |
| maxChars | No | Truncate each body to this many characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral detail: each page returns cleaned text from the index, and missing URLs are marked rather than causing failure. This goes beyond the schema and helps an agent set expectations.
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 compact and front-loaded: it names the primary behavior, the relationship to fetch_page, the batching benefit, and the non-fatal missing-URL behavior in just two sentences. No filler or 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?
For a read-only bulk tool with two well-described parameters and no output schema, the description sufficiently covers purpose, usage context, return content, and an important edge case. Minor missing details like response ordering or error handling for invalid URLs are not critical given the annotations and schema coverage.
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 baseline is 3. The description reinforces the 'up to 20 URLs' limit and mentions cleaned text, but it does not add meaningful semantic detail beyond what the input schema already provides for urls and maxChars.
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 several indexed pages at once, specifies a limit of 20 URLs, and explicitly contrasts it with fetch_page for single-URL reads. This makes it immediately distinguishable from its closest sibling.
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 provides clear context for when to use this tool: when you need multiple indexed pages in one round trip, framed as the bulk-read counterpart to search_batch. It implies fetch_page is for single URLs and search_batch is for searches, but it does not explicitly state exclusions or edge cases like 'use fetch_page for one URL'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the specific passages that answer a question, each with the URL and title it came from. Use this when you intend to cite or summarise rather than browse: it skips the step of fetching pages and hunting for the relevant paragraph, and the attribution is exact.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of passages. | |
| query | Yes | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety. The description adds meaningful behavioral detail: it returns passages with exact attribution and avoids the intermediate page-fetching step. This tells an agent more about the tool's operation beyond the annotation.
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, front-loads the core behavior, and then adds a concise usage rationale. Every sentence contributes value with no 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 description adequately explains what is returned (passages with URL and title) but does not address the optional 'category' parameter, result limits, or behavior when no passages match. Given there is no output schema, more detail on the return structure would make it 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 description coverage is only 33%, so the description should compensate, but it does not explain the 'category' parameter at all and gives only vague context for 'query' and 'limit'. The schema's 'limit' description ('Number of passages') is minimal, and 'query' is only implicitly tied to 'a question'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('the specific passages that answer a question') and clarifies that each passage includes the source URL and title. The title ('not just links') and the contrast with browsing distinguish this tool from sibling search tools, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool when intending to cite or summarise rather than browse, and explains the benefit: it skips fetching pages and hunting for the paragraph. It gives a clear use case but does not name alternative tools or state explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given an indexed URL, return other indexed pages with similar content, compared by meaning rather than shared keywords.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of an indexed page. | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context: the input must be an indexed URL, and matching is semantic rather than lexical. It does not describe error behavior for non-indexed URLs, result ordering, or output format, but with the read-only annotation the bar is lower and the added context earns a mid-range score.
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 a single efficient sentence that front-loads the core behavior and then adds a useful semantic distinction. It earns its place without redundancy. It is slightly lean, but not to the point of harming clarity.
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 two-parameter read-only tool, the description covers the core purpose and the key input constraint. However, it does not explain the 'limit' parameter, the return shape, or behavior when the given URL is not indexed. Since there is no output schema and sibling tools like fetch_page and find_passages exist, a little more detail would make the description fully self-sufficient.
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 50%: the 'url' parameter is described in the schema, but 'limit' is not. The description reinforces the meaning of 'url' by requiring it to be an indexed page, but it adds nothing about the 'limit' parameter or its default/maximum. Since the schema leaves half the parameters undocumented and the description does not compensate, this is a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('return') and resource ('other indexed pages with similar content'), and adds a clear distinguishing mechanism: comparing 'by meaning rather than shared keywords.' This effectively separates it from keyword-based sibling tools like search and search_batch. The title is also informative and matches the description.
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 implies when to use the tool: when you want semantic similarity between indexed pages rather than keyword matches. However, it does not explicitly name alternative tools or state exclusions, such as 'use search for keyword-based retrieval.' The guidance is present but left to inference rather than being directly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Size and freshness of the corpus: sites, pages, passages, languages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds useful context about what dimensions are included. However, it does not disclose how freshness is computed, whether counts are approximate, or what the response structure looks like. This is a mild gap rather than a contradiction.
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?
A single sentence with a colon-separated list conveys the core value immediately and enumerates the four covered dimensions without any wasted words. It is appropriately concise and well structured.
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 parameterless, read-only stats tool, the description covers the essential purpose and content dimensions. Since there is no output schema, it leaves some ambiguity about the exact return format, such as whether results are per-site counts, global totals, or timestamps, but this is unlikely to prevent a correct call.
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 schema already fully documents invocation needs. The description provides context about what the statistics measure, which is sufficient given no parameters exist.
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 identifies what the tool reports: corpus size and freshness across sites, pages, passages, and languages. It is specific enough to distinguish it from the search, fetch, and watch siblings, though it lacks an explicit action verb and does not directly contrast with related list/source 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?
No guidance is given on when to use index_stats versus alternatives like list_sites, source_profile, or search. The usage context is only implied by the name and description, with no explicit conditions, exclusions, or recommended alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which sites the index covers, with page counts. Use this to understand coverage before concluding that something is missing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search | No | Filter by substring of the host. | |
| status | No | active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description adds that the tool reports coverage and page counts. However, it does not disclose behavioral details such as default status filtering, pagination limits, or the overall response structure.
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?
Two concise sentences front-load the purpose and then give a practical use case. There is no redundant wording or filler.
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 read-only list with optional parameters, the description conveys the core idea and enough to attempt a basic call. But with no output schema, it omits useful context like the exact fields returned, whether status defaults to active, and how limit and search shape the results.
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 only 33%, and the description does not compensate by explaining 'limit', 'search', or 'status'. The schema provides defaults and one field description, but the tool description adds no parameter-level meaning of its own.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Show'), a resource ('sites the index covers'), and an output detail ('page counts'). It clearly conveys the tool's purpose, though it does not explicitly contrast it with siblings like list_watches or index_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete use case: 'Use this to understand coverage before concluding that something is missing.' This is useful context, but it does not mention exclusions or when an alternative tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the queries you are watching and when each was last checked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds behavioral value by specifying that the response includes the watched queries and their last-checked times, which is not evident from annotations alone.
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 a single concise sentence that front-loads the core purpose and then adds the key piece of returned context. Every word earns its place, with no filler or redundant restatement of the title.
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 parameterless read-only list tool, the description provides enough understanding of what the tool does and what the output contains. It could be slightly more explicit about the exact fields or empty-state behavior, but given the tool's simplicity, this is largely 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?
There are zero parameters, so the schema imposes no burden. The description appropriately focuses on what the tool returns rather than parameter details, and the baseline of 4 applies since no parameter documentation is needed.
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 'Show' and the resource 'queries you are watching', which is exactly what the tool name and title indicate. It also adds useful detail about showing when each was last checked, distinguishing it from sibling tools like check_watch or delete_watch.
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 usage context is implied: an agent would call this when it needs to see current watches. However, there is no explicit guidance about when to choose this over check_watch, watch_query, or delete_watch, nor any mention of when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Webdex index of crawled websites. Combines keyword (BM25) and semantic (vector) retrieval. Supports "quoted phrases" for exact matches and -term to exclude a term. Works across languages: a query in one language can retrieve pages written in another.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Restrict to a two-letter language code, e.g. "ru". | |
| mode | No | hybrid = both arms fused (best general choice); keyword = exact terms only, for names, codes and error strings; semantic = meaning-based, for vague or descriptive questions. | hybrid |
| site | No | Restrict to one host, e.g. "example.com". | |
| limit | No | Maximum number of results. | |
| query | Yes | The search query. | |
| expand | No | Widen the query with synonyms and acronym expansions (грм → газораспределительный механизм, НДФЛ → налог на доходы). On by default; set false for an exact-terms search. The terms actually added come back in expandedWith. | |
| offset | No | Skip this many results — for a second page. | |
| category | No | Restrict to a task category, e.g. "news", "legal", "forum-it". See list_sites. | |
| sinceDays | No | Only pages published within this many days. Use for anything time-sensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it reveals hybrid retrieval, exact-match operators, exclusion syntax, and cross-lingual behavior. It does not describe result structure or pagination, but the added context is substantial.
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 compact: three sentences, each earning its place. The first states the resource, the second the retrieval mechanics, and the third adds query-language capabilities. No redundant or filler content is present.
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 nine parameters, no output schema, and many sibling search tools, the description is adequate but not complete. It covers the core behavior well but omits guidance on when to prefer this over search_batch or search_products, and does not address return-value expectations. The schema compensates for parameter details, but the selection context is incomplete.
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 documents all parameters thoroughly. The description adds general search-behavior information but does not meaningfully enhance understanding of individual parameters beyond what the schema provides. A baseline of 3 is appropriate.
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 identifies a specific verb and resource: 'Search the Webdex index of crawled websites.' It also explains the combined retrieval approach (BM25 + semantic), making the core purpose concrete. However, it does not differentiate this tool from closely related siblings like search_batch or search_products, so it falls short of a 5.
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 gives useful operational details like quoted phrases, term exclusion, and cross-language search, but it does not state when to use this tool versus alternatives such as search_batch or search_products. There is no explicit when-to-use, when-not-to-use, or alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute up to 10 queries in one call. Answering a real question usually takes several related searches, and doing them one at a time spends a round trip on each; this runs them together and returns the results grouped by query.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| limit | No | Results per query. | |
| queries | Yes | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already report readOnlyHint=true, so no safety contradiction exists. The description adds useful behavioral context by saying up to 10 queries can be executed and that results are returned grouped by query. It does not disclose failure behavior, rate limits, or what happens when one query in the batch fails, but the read-only annotation lowers the disclosure burden.
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: a direct functional statement followed by a concise rationale for batching. It is front-loaded, contains no filler, and every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core invocation is adequately described: up to 10 queries, grouped results, and a clear use case. However, there is no output schema, so the description should carry more weight, and it still leaves `lang`, `category`, and per-batch failure behavior unexplained. This is sufficient for basic use but not complete for all plausible calls.
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 only 25%, so the description must compensate for unroun documented parameters. It indirectly describes `queries` via 'up to 10 queries' and 'grouped by query', but it does nothing to explain `lang` or `category` or how they affect results. The required parameter is partially covered, but two optional parameters remain semantically opaque.
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 uses a specific verb plus resource: 'Execute up to 10 queries in one call' and 'returns the results grouped by query.' It clearly differentiates this batch tool from a single search tool by emphasizing batching multiple queries in one round trip.
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 states when to use it: when answering a real question typically requires several related searches. It also explains the cost of doing searches one at a time. It does not explicitly name the alternative tool or state when not to use it, so it is clear but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search shop catalogues by name and specification, filter by price and availability, and sort by price. Use this rather than search whenever the question is what something costs or where to buy it: search returns pages that mention a product, this returns the offer itself — price, stock, specifications and a link straight to the product page. Specifications are searchable, so a query like "ноутбук 16 гб 512 ссд" or "холодильник samsung no frost" matches on capacity and features, not just the model name. Coverage is whatever has been crawled: an exact model, colour and size that no indexed shop stocks returns nothing rather than the wrong colour — an empty result means not indexed, not nonexistent.
| Name | Required | Description | Default |
|---|---|---|---|
| shop | No | Restrict to one shop by host, e.g. citilink.ru. | |
| sort | No | relevance | |
| limit | No | ||
| query | Yes | What to find, in words a shopper would use. | |
| vendor | No | Manufacturer, exact match. | |
| in_stock | No | Only offers the shop states are in stock. Off by default: many shops never say. | |
| max_price | No | Upper bound. | |
| min_price | No | Lower bound, in the shop's currency. | |
| best_per_product | No | Collapse the same product across shops to its cheapest offer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so well: it explains that the return is the offer itself (price, stock, specifications, product link), that specification matching works beyond model names, and that an empty result means 'not indexed, not nonexistent'. It stops short of describing response shape or sort edge cases, but for a search tool this is strong behavioral context.
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 four sentences, each earning its place: core action, usage distinction, specification-search behavior, and coverage caveat. The most important scoping information is front-loaded, and the text is dense without being bloated.
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 output schema and nine parameters, the description covers the essential context: what it searches, how it differs from the sibling, what results contain, and how to interpret empty results. Minor gaps remain, such as an explicit statement of pagination/limit behavior and currency of prices, but those are partially covered by the schema and do not severely hinder correct use.
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 78%, so the schema already documents most parameters. The description adds real value beyond that for the `query` parameter: it clarifies that specifications are searchable and that queries like 'ноутбук 16 гб 512 ссд' match on capacity and features. It also adds coverage semantics relevant to interpreting results, which no parameter description captures.
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 opens with a specific verb and resource — 'Search shop catalogues' — and adds the key dimensions: name/specification querying, price/availability filtering, and price sorting. It also explicitly contrasts itself with the sibling tool `search`: 'search returns pages that mention a product, this returns the offer itself'. An agent can unambiguously tell what this tool does and how it differs from its sibling.
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 gives an explicit routing rule: 'Use this rather than `search` whenever the question is what something costs or where to buy it' and explains the distinction between offer-level and page-level results. This tells the agent both when to use this tool and when the alternative is appropriate. No further inference is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe a site in the index: what type of source it is (official, media, reference, forum, shop), how much of it we hold, how trusted it is by the link graph, and how fresh the copy is.
Use this before relying on a result. A ministry's own page and a forum post repeating it are both 'a URL', and the difference decides how much weight the claim deserves.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Domain, e.g. cbr.ru |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds meaningful behavioral context by specifying what the profile reports: source category, holdings extent, link-graph trust, and copy freshness. It does not contradict annotations and provides useful detail beyond a generic 'get info' statement.
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?
Two short paragraphs with no filler: the first defines the tool's output dimensions, the second gives the decision-use context. The most important action ('Describe a site in the index') is front-loaded, and every sentence contributes information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, a 100%-described schema, and readOnlyHint annotation, the tool is simple. There is no output schema, so the description appropriately carries the burden of explaining what the agent will receive: source type, holdings, trust, freshness. It also explains why this matters for evaluating claims. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema describes host as 'Domain, e.g. cbr.ru' with an example. The description does not add substantial parameter-level meaning beyond calling it a site, but it does not need to because the schema already documents the only parameter clearly. Baseline 3 is appropriate.
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 opens with a specific verb and resource: 'Describe a site in the index.' It then enumerates exactly what the profile contains (source type, holdings, link-graph trust, freshness), making its purpose unmistakable. This differentiates it from sibling search/fetch/list tools, which operate on URLs or results rather than profiling site trustworthiness.
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 the agent when to use the tool: 'Use this before relying on a result.' It reinforces the decision with a concrete contrast between a ministry page and a forum post. It does not name alternative tools or exclusion cases, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a query and later ask what has appeared since you last checked. Pull-based: nothing is pushed to you, you call check_watch when you want to know — which fits an agent that runs on its own schedule.
Use for monitoring: a topic, a competitor, a regulation, a product.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| label | No | ||
| query | Yes | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it is pull-based, nothing is pushed, and the agent must call check_watch later. It also implies persistent state (saving a query for later comparison). The idempotentHint and readOnlyHint=false are consistent with this framing.
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 compact and every sentence serves a purpose: the first explains the mechanism, the second contrasts with push-based alternatives, and the third lists concrete use cases. No filler or 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 description captures the core behavior and usage context well, but it leaves important gaps: parameter semantics for three of four fields are unspecified, and with no output schema, the agent gets no guidance on what check_watch returns or how results are delivered. Adequate for a simple tool, but not 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 description coverage is 0%, so the description should compensate, but it only meaningfully clarifies the 'query' parameter via examples (topic, competitor, regulation, product). It does not explain 'lang', 'label', or 'category', leaving the agent to guess their roles and valid values.
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 a specific action ('Save a query') and its purpose ('later ask what has appeared since you last checked'). It also distinguishes itself from the related check_watch sibling by explicitly describing the pull-based model.
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 gives concrete use cases: monitoring a topic, competitor, regulation, or product. It also explains when this tool fits — an agent that runs on its own schedule — and points to check_watch as the companion call. It does not explicitly list exclusions or alternatives like search, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
check_watchdelete_watchfetch_pagefetch_pagesfind_passagesfind_similarindex_statslist_siteslist_watchessearchsearch_batchsearch_productssource_profilewatch_queryClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Web search, page reading and structured extraction for AI agents, with strong RU coverage
Paid web, news, company, product, and geographic search plus clean page reading for agents.
Wayback Machine for agents: closest archived copy of a URL with its text, and full capture history
Verified doc corpora for agents: grep-first retrieval, hashed pages, Merkle+RFC-3161 receipts
Add one secure layer between your agents and this server.
Each tool targets a distinct operation: core search, batch search, product search, passage-level retrieval, similarity lookup, page fetching, watch management, and index introspection. The potentially overlapping tools are explicitly differentiated, such as search_products versus search, and the batch variants are clearly scoped.
Most tools follow a clear verb_noun snake_case pattern like fetch_page, delete_watch, list_sites, and watch_query. The pattern is slightly weakened by noun-phrase names like index_stats and source_profile, but the naming remains predictable overall.
Fourteen tools is within the ideal range for a search-focused server, and each tool covers a distinct feature: search, batch retrieval, product search, passage extraction, similarity, full-text fetching, watch lifecycle, and corpus introspection. No tool feels redundant or extraneous.
The toolset covers the full agent workflow for web search: querying, reading indexed pages, extracting citable passages, finding related content, monitoring with watches, and understanding corpus coverage and source trustworthiness. Minor conveniences like updating a watch are absent, but the lifecycle is otherwise complete.