Skip to main content
Glama
rzhunemogu-mcp

rzhunemogu-mcp

Поиск анекдотов

search_jokes

Search Russian-language jokes by keywords, with Russian morphology matching word forms and relevance-ranked results.

Instructions

Полнотекстовый поиск записей по ключевым словам на русском языке (например, «врач», «Штирлиц», «тёща», «теща»). Использует морфологию русского языка PostgreSQL: word-формы приводятся к основе, поэтому «врач» найдёт и «врачи», «врачом» и т.п. Результаты отсортированы по релевантности (ts_rank). query обязателен; поиск без него вернёт пустой результат. Только чтение, без побочных эффектов. limit до 50 (по умолчанию 15), offset для пагинации.

Input Schema

NameRequiredDescriptionDefault
limitNoКоличество результатов (1-50). По умолчанию 15.
queryYesПоисковый запрос (одно или несколько слов, поддерживается русская морфология). Пример: «про врача».
offsetNoСмещение для пагинации. По умолчанию 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.0
    • changedInput schema / properties / limit / description
      Previous value: -"Сколько записей (по умолчанию 15)"New value: +"Количество результатов (1-50). По умолчанию 15."
    • changedInput schema / properties / offset / description
      Previous value: -"Смещение для пагинации"New value: +"Смещение для пагинации. По умолчанию 0."
    • changedInput schema / properties / query / description
      Previous value: -"Поисковый запрос"New value: +"Поисковый запрос (одно или несколько слов, поддерживается русская морфология). Пример: «про врача»."
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses read-only/no-side-effects, relevance ordering via ts_rank, stemming behavior, and the empty-result consequence of a missing query. What it omits is the shape of returned records, but that is a modest gap 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.

Conciseness4/5

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

Front-loads what the tool is and the stemming example, then constraints, then pagination. Mostly efficient, though the limit default/ceiling restatement duplicates the schema and could be trimmed.

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

Completeness4/5

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

For a three-parameter read-only search with no output schema, the description covers ranking, language/morphology, required query, and pagination. Only the returned record shape is unaddressed, which is a minor omission.

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

Parameters3/5

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

Schema coverage is 100%, so limit/offset defaults and bounds are already documented and the description largely repeats them. The one genuine addition is the morphology explanation showing that 'врач' matches 'врачи'/'врачом', which clarifies query semantics beyond the schema.

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?

States a specific verb+resource: full-text keyword search over joke records, with Russian-language scope and ranking. It is clear what the tool does, but it never names how it differs from siblings such as get_jokes_by_category or random_joke, leaving that inference to the agent.

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

Usage Guidelines3/5

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

Usage is only implied: 'query обязателен; поиск без него вернёт пустой результат' tells the agent the parameter is mandatory but not when to prefer search over category browsing or random retrieval. No explicit when-to-use or when-not-to-use guidance appears.

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