Skip to main content
Glama
ati-hh-mcp

ati-hh-mcp

by timur-ai

Dict Area

dict_area

Fetch an hh.ru region by numeric ID, including nested child areas; optionally add its Russian prepositional-case name for localized lookups.

Instructions

Get one hh.ru region (area) by its numeric id, including nested children. Optional additional_case=prepositional adds a Russian prepositional-case name.

Input Schema

NameRequiredDescriptionDefault
area_idYes
additional_caseNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does usefully disclose that the response includes nested child regions and that an optional case variant can be requested. It omits auth requirements, behavior on an unknown id, and whether children nesting is recursive or one level deep.

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

Conciseness5/5

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

Two tight sentences, with the core lookup behavior front-loaded and the optional modifier second. No filler or restatement of the tool name.

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 simple two-parameter dictionary lookup with no annotations and no output schema, the description covers purpose, the key, the optional case variant, and the notable result trait (nested children). Missing only error behavior for invalid ids and what fields an area object carries.

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 0%, but the description does explain both parameters: area_id as a numeric region id and additional_case=prepositional as adding a Russian prepositional-case name. Gaps remain – only one value of additional_case is documented (the schema has no enum, so the agent cannot tell what other values exist) and 'numeric id' conflicts with the schema declaring area_id as a string.

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 and resource ('Get one hh.ru region (area)') plus the lookup key ('by its numeric id'), and the singular 'one' implicitly separates it from the list-style sibling dict_areas. It stops short of explicitly naming dict_areas or suggest_areas as the alternatives for listing or free-text lookup.

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 implied by 'by its numeric id' – call this when you already hold an area id – but there is no stated when-not, no mention of when to prefer dict_areas (listing) or suggest_areas (search by text), and no prerequisites such as where an id comes from.

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