Skip to main content
Glama

TalentHR MCP by usefulapi

Get the hires and leaves report

talenthr_get_hires_leaves_report
Read-only

Hires, terminations and attrition rate per month over a period.

Input Schema

NameRequiredDescriptionDefault
filterNoFilter: key=comma-separated ids, keys separated by ';', e.g. location=36;emp_state=1,2,3. Valid keys and ids come from talenthr_get_directory_filters.
periodNoReporting period: l12m (last 12 months) or a 4-digit year (the current or the previous calendar year). Alternatively pass start_date and end_date (max 36 months).
end_dateNoCustom range end, yyyy-mm-dd.
start_dateNoCustom range start, yyyy-mm-dd (use with end_date instead of period).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

The readOnlyHint annotation already covers the safety profile, so the description carries a lighter burden. It does add the useful grain detail 'per month over a period,' but says nothing about how attrition rate is computed, how the period interacts with the custom date range, or what the response looks like.

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?

A single short sentence with no filler, and the metric list is front-loaded. It reads as a fragment rather than a full statement of purpose, which slightly weakens the framing, 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?

No output schema exists, yet the description doesn't hint at the response shape or how metrics are broken down. For an analytics report with zero required parameters and four optional scoping params, the agent has enough to call it but not enough to predict or interpret its output.

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 100% and every parameter carries its own description, including the filter syntax, valid period values, and the start/end-date alternative with a 36-month cap. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

Purpose3/5

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

The description names the report's contents (hires, terminations, attrition rate) and grain (per month), which is more specific than the title alone. However, it doesn't say what distinguishes it from sibling reports like talenthr_get_headcount_report or talenthr_get_time_off_report, leaving the agent to infer which report answers which question.

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

Usage Guidelines2/5

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

It gives no when-to-use guidance, no prerequisites, and no alternatives. An agent must guess whether this is the right report for a given HR analytics question versus the headcount or time-off reports.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.