Skip to main content
Glama
Sign In
HireLayer MCP server

HireLayer MCP server

by HireLayer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Skills Normalizer

normalize_skills
Read-only

Map free-text skills to HireLayer taxonomy IDs, families, and domains in French or English, listing unmatched parts as unresolved.

Instructions

Map free-text skills (one skill, a compound string or a whole skills section) to skills of the HireLayer taxonomy, with their IDs, families and domains, named in French or English. Unmatched parts are listed in unresolved. Costs 1 HireLayer credit.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>"
    },
    "name": "normalize_skills"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesFree text containing one or more skills.
languageNoLanguage of the labels returned: fr (default) or en.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Adds real context beyond the annotations: unmatched fragments surface in an "unresolved" field and each call costs 1 HireLayer credit — billing/quota information the agent cannot get from readOnly/openWorld hints. The non-idempotent hint is not explained (no note that taxonomy mappings can change over time), which keeps it short of a 5.

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: purpose and output shape first, then the failure mode and the cost. No filler, and the cost caveat is placed where it is read before invocation.

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?

With only two simple parameters and no output schema, the description does the heavy lifting by naming the response fields and the unresolved bucket. Missing only a note on result ordering/volume limits for large inputs, which matters given the 5000-character cap.

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 coverage is 100%, so the baseline is 3, but the description goes slightly beyond it by clarifying that `text` tolerates a whole skills section as well as a single compound string, and by framing `language` as controlling the language of returned labels. It does not discuss the 5000-character limit or behavior when the text is very large.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Map free-text skills ... to skills of the HireLayer taxonomy") and enumerates the accepted input shapes (single skill, compound string, whole skills section) and the returned artifacts (IDs, families, domains, unresolved). This is clearly distinguishable from siblings like parse_resume or extract_job_criteria, which handle documents and criteria rather than taxonomy normalization.

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

Usage Guidelines4/5

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

The description scopes usage well by describing the input forms it accepts, implying it is the tool for any free-form skill text. It does not, however, name alternatives or state exclusions (e.g., whether to run parse_resume first, or what to do for non-skill text), so the agent must infer the boundary with siblings.

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