Skip to main content
Glama
ati-hh-mcp

ati-hh-mcp

by timur-ai

Suggest Skill Set

suggest_skill_set

Suggest key skills by name prefix and return their IDs for use with dict_skills, so agents can resolve skill names to valid IDs.

Instructions

Suggest key skills by name prefix with their ids; skill ids are accepted by dict_skills.

Input Schema

NameRequiredDescriptionDefault
textYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses the return shape (skill names plus ids) and the matching rule (name prefix), but says nothing about result caps, ranking, empty-result behavior, or whether matching is case- or locale-sensitive.

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?

One compact sentence that front-loads the primary behavior and appends the interop note. The semicolon-joined clause is slightly compressed but nothing is wasted.

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?

For a one-parameter suggestion tool with no output schema and no annotations, the description covers what is returned and how input is interpreted, which is most of what an agent needs. The remaining gap is practical calling detail such as result limits and matching rules.

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% for the single 'text' parameter, so the description must compensate, and it does specify that the value is a name prefix rather than a free-text query. That is useful but thin: no guidance on minimum length, capitalization, or whether multiple words are allowed.

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: it suggests key skills by name prefix and returns them with ids. It implicitly distinguishes itself from the dictionary lookup siblings by noting the ids it returns are consumed by dict_skills, so an agent can tell it is the autocomplete half of the pair.

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?

The mention that returned ids are 'accepted by dict_skills' sketches the intended lookup-then-detail workflow, which is genuine usage guidance. It stops short of saying when to prefer this over dict_skills directly or what prefix length/format is expected.

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