Skip to main content
Glama
ati-hh-mcp

ati-hh-mcp

by timur-ai

Suggest Companies

suggest_companies

Resolve partial employer names by prefix and return matching registered company IDs and URLs for hh.ru data operations.

Instructions

Suggest registered employers (companies) by name prefix with their ids and urls.

Input Schema

NameRequiredDescriptionDefault
textYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses that matching is prefix-based and that the response contains ids and urls, but says nothing about result caps, ordering, case sensitivity, or empty-result behavior for a lookup endpoint.

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?

A single tight sentence with the resource, matching rule, and return payload front-loaded. Nothing is superfluous and there is no filler.

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

Completeness3/5

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

The tool is simple, and the description compensates for the absent output schema by naming the returned fields (ids and urls). However, with no annotations and no parameter documentation, it still leaves the agent guessing about result volume and matching edge cases.

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 description coverage is 0% and the single parameter "text" is undocumented, so the description must carry the meaning. Saying "by name prefix" does explain that text is a name prefix rather than a free-text query, but gives no guidance on minimum length, case, or URL-encoded input.

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 names a specific verb and resource ("Suggest registered employers (companies)") plus the matching mode ("by name prefix"), which cleanly separates it from dictionary siblings like dict_industries and from other suggest_* tools. It does not explicitly name an alternative lookup tool, but the resource is unambiguous.

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: an agent can infer this is for resolving a partial company name into ids and urls. There is no explicit statement of when to prefer it over dict_dictionaries or a search tool, and no note on prerequisites or when results will be empty.

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