Skip to main content
Glama

ru_research

Research-пакет: кириллический поиск + top-страницы в Markdown одним платежом. $0.02 USDC

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsYes
extraYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

C2.7/5.0
Behavior3/5

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 the payment cost ($0.02 USDC) and the outputs (Markdown top pages), but does not clarify side effects, authentication needs, failure handling, or whether the operation is read-only. This is minimal but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is a single sentence, very concise, and front-loaded with the key value proposition (Cyrillic search + top pages in Markdown) and cost. It earns its place, though it is perhaps too terse and omits essential usage details.

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

Completeness2/5

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

Given the generic schema, no output schema, and lack of parameter docs, the description is insufficient for an agent to correctly invoke the tool. It provides a high-level idea but omits how to structure inputs and what to expect in return, making it incomplete for a 2-parameter tool.

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

Parameters1/5

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

The schema has generic 'args' and 'extra' objects with no property definitions and 0% description coverage. The description does not explain what arguments are expected, such as search term, number of pages, or output format details. It fails to compensate for the complete lack of schema documentation.

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

Purpose4/5

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

The description states the tool provides a research package combining Cyrillic search and top pages in Markdown format, with a clear payment amount. It is specific about the resources and actions, but does not explicitly differentiate from sibling tools like ru_search or ru_page beyond implying a bundled operation.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus its siblings. It does not mention scenarios, exclusions, or alternatives. The phrase 'with one payment' hints at a batch use case, but there is no explicit 'use this when...' or 'do not use for single lookups' type of guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.9/5.0
Disambiguation4/5

The server splits cleanly into INN, Pochta, and RU research domains, and most tools have a distinct purpose. The main confusion risk is pochta_delivery_time vs pochta_tariff, since tariff also includes delivery time, and pochta_offices vs pochta_zip when both are used for index lookup.

Naming Consistency4/5

Names are consistently lowercase snake_case with clear domain prefixes: inn_, pochta_, ru_. However, the naming is not perfectly uniform because some names are verbs like lookup/track/search, while others are nouns like offices/tariff/zip.

Tool Count4/5

11 tools is a reasonable scope for three covered areas: Russian company lookup, postal services, and Cyrillic search/research. The count is not excessive, but there is enough similarity between a few tools that the set could be slightly trimmed without losing capability.

Completeness4/5

The Pochta domain is well covered: address normalization, tariffs, delivery times, offices, and tracking are all present. For a read-only RU data API, no critical dead ends are obvious, though the broad 'RU data' scope could plausibly include more data sources beyond INN, postal, and web search.

Resources