MCP for Russian new-builds on the client's EISZHS contract. Method spec is closed; no invented API.
All 6 tools have identical, vague Russian descriptions that provide no actionable guidance for LLM selection. Descriptions like 'Карточка застройщика: ключ ЕИСЖС клиента или честный отказ' (22-24 chars) fall far below the 50-200 char baseline for A+ tools and fail to explain WHAT the tool does, WHEN to use it, or what it returns. Input schemas are present with basic type definitions and descriptions, but parameter descriptions are minimal (e.g., 'ИНН или ОГРН застройщика (юрлица)' lacks format/constraint guidance). No output schemas are documented. Error handling is absent from tool definitions. Tool names follow verb_noun convention (check_*, get_*, list_) but descriptions do not compensate for their brevity. The server relies on external documentation (closed EISZHS contract spec) rather than self-documenting tool interfaces.
Разрешение на строительство: ключ ЕИСЖС клиента или честный отказ. Описание методов закрыто.
Карточка застройщика: ключ ЕИСЖС клиента или честный отказ. Описание методов закрыто — запрос не выдумываем.
Эскроу: ключ ЕИСЖС клиента или честный отказ. Описание методов закрыто.
Сводка риска: ключ ЕИСЖС клиента или честный отказ. Описание методов закрыто.
Проектная декларация: ключ ЕИСЖС клиента или честный отказ. Описание методов закрыто.
Каталог объектов: ключ ЕИСЖС клиента или честный отказ. Описание методов закрыто.
All tool descriptions are under 25 characters and provide no actionable context. These fail to answer WHAT the tool does, WHEN to use it, or what it returns, forcing LLMs to guess.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
Parameter descriptions lack format guidance, constraints, and examples. E.g., 'ИНН или ОГРН застройщика' does not specify format (10 vs 12 digits), valid ranges, or when to use each.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | <=2025-11-25 | v2 |
No error handling guidance in tool definitions. Server code shows honest refusals (not_configured, spec_closed, invalid_credentials) but these are not documented in tool descriptions. LLMs cannot plan recovery without knowing what errors are possible and what to do next.
list_new_buildings accepts nullable filter parameters (region, developer_inn, stage, escrow) but does not document mutual exclusivity, required combinations, or filtering semantics. LLMs will pass arbitrary combinations without guidance.