Найти MCP-сервер в каталоге mcp-catalog.ru по формулировке задачи (например: «ЕГРЮЛ», «postgres», «курсы ЦБ»). Возвращает только реальные совпадения. Если ничего не нашлось — found=false, без подмены похожими.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| category | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It adds a clear contract: only real matches are returned, no similar substitutes are made, and an empty result is communicated via found=false. This is valuable, though it does not detail how limit or category influence matching.
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, with the purpose and examples front-loaded and the no-match behavior stated separately. Every sentence adds useful information with no filler 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?
The output schema exists, so explaining return values is unnecessary, and the description adequately covers the core search behavior and the no-match contract. However, the optional parameters limit and category are not explained, and there is no mention of using list_categories to discover valid category values, leaving a gap for fully correct advanced usage.
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 must compensate. It gives helpful examples for the query parameter but says nothing about limit or category, leaving their meanings to be inferred solely from property names and defaults.
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 action — find an MCP server in the mcp-catalog.ru catalog — and explains the search method: by task wording, with examples such as «ЕГРЮЛ», «postgres», and «курсы ЦБ». This distinguishes it from siblings like get_server, list_atomno_servers, and list_categories as a query-based search tool.
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 clearly implies when to use it: when the agent has a natural-language formulation of a task to search for. However, it does not explicitly name alternatives or say when not to use it, such as when a specific server ID is already known or when listing the whole catalog is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are mostly distinct: get_server is exact lookup by slug, search_servers is query-based discovery, list_categories returns categories, and list_atomno_servers returns a specific family subset. Some overlap exists between search_servers and list_atomno_servers as both return sets of servers, but descriptions clarify the intent well enough.
All tool names follow a consistent verb_noun lowercase snake_case pattern: get_server, list_atomno_servers, list_categories, search_servers. The naming is uniform and predictable.
Four tools is a reasonable, focused scope for a catalog lookup service. Each tool serves a distinct purpose—exact lookup, search, category listing, and a curated family listing—without unnecessary bloat.
The catalog covers lookup, search, and category counts, but lacks a way to browse all servers or list servers within a category, which is a notable gap for a catalog API. The Atomno-specific listing is also oddly narrow and does not compensate for the missing general browse capability.