Skip to main content
Glama
AndreyTepaykin

hh-mcp

by AndreyTepaykin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_resume

Retrieve a candidate's full resume details: experience, education, skills, contacts. For resumes received through applications, pass topic_id and vacancy_id to avoid paid database views.

Instructions

Get full resume details: experience, education, skills, contacts. If the resume came through an отклик, always pass topic_id (+vacancy_id): the unscoped read hits the resume database, consumes a paid view and is the call hh.ru captcha-gates. When HH_REQUIRE_TOPIC is on, unscoped reads require allow_unscoped:true. Requires an EMPLOYER OAuth token + paid resume-database access.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawNoReturn the full raw hh.ru JSON instead of the compact summary.
no_cacheNoSkip disk cache and force a fresh read.
topic_idNoNegotiation (отклик) topic id the resume came through. Supplying it reads the resume in the context of your own response instead of the resume database.
resume_idYesResume ID
vacancy_idNoVacancy id the negotiation belongs to. Used together with topic_id.
allow_unscopedNoConfirm a paid resume-database view when topic_id is omitted. Required when HH_REQUIRE_TOPIC is on.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.1.0
    • addedInput schema / properties / allow_unscoped
      Added value: +{
+  "description": "Confirm a paid resume-database view when topic_id is omitted. Required when HH_REQUIRE_TOPIC is on.",
+  "type": "boolean"
+}
  2. Changed3 schema fields changedv2.2.4
    • addedInput schema / properties / no_cache
      Added value: +{
+  "default": false,
+  "description": "Skip disk cache and force a fresh read.",
+  "type": "boolean"
+}
    • addedInput schema / properties / topic_id
      Added value: +{
+  "description": "Negotiation (отклик) topic id the resume came through. Supplying it reads the resume in the context of your own response instead of the resume database.",
+  "pattern": "^\\d+$",
+  "type": "string"
+}
    • addedInput schema / properties / vacancy_id
      Added value: +{
+  "description": "Vacancy id the negotiation belongs to. Used together with topic_id.",
+  "pattern": "^\\d+$",
+  "type": "string"
+}
  3. First observedv2.2.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: unscoped reads consume a paid view, are captcha-gated by hh.ru, require an EMPLOYER OAuth token, and require paid resume-database access. These are consequential behaviors an agent could not infer from the schema alone.

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 the purpose, then layers the conditional parameter guidance and prerequisites in descending priority. Dense but each sentence carries a distinct consequence; the captcha/paid-view clause is slightly packed but informative rather than filler.

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

Completeness5/5

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

For a 6-parameter tool with no output schema, the description covers purpose, return content at a high level, auth requirements, environment-dependent gating, and the cost of the wrong call. Nothing essential for correct invocation is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3; the description adds value by explaining the *consequence* of the topic_id/allow_unscoped choice (paid views, captcha) rather than restating schema text. It stops short of clarifying raw/no_cache semantics, which the schema covers anyway.

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 full resume details') and enumerates the content returned (experience, education, skills, contacts), which distinguishes it from search/list siblings by scope. However, it never names a sibling tool to route the agent, so it falls short of a 5 on the sibling-differentiation criterion.

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

Usage Guidelines5/5

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

Gives explicit conditional guidance: 'If the resume came through an отклик, always pass topic_id (+vacancy_id)' and the consequence of not doing so. It also documents the HH_REQUIRE_TOPIC condition under which allow_unscoped:true is required. When-to-use and when-not-to-use are both spelled out.

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

Deploy Server

Other Tools