Skip to main content
Glama
HR-Partner

HR Partner MCP Server

Official
by HR-Partner

List Employees

list_employees

Retrieve employee summaries with optional filters for department, location, position, status, and dates. Returns code, name, and key details for quick reference.

Instructions

Get a list of employees in HR Partner with optional filters. Returns summary details per employee (code, name, department, location, position, status flags, dates). Use get_employee with the employee 'code' for full details including contacts, addresses and custom fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoOnly return employees who have this tag (single tag only)
groupNoOnly return records within this group (note: the field is always called 'group' in the API even if renamed to Branch/Entity etc. in the app)
searchNoReturn only employees whose first or last names match this search text
locationNoOne or more location names (separated by commas) to filter by
positionNoOnly return employees with this position description
can_logonNoOnly return employees who can log on to their portal (true/false)
is_activeNoOnly return active employees (true/false)
pay_pointNoOnly return employees that have this pay point identifier
departmentNoOne or more department names (separated by commas) to filter by
reports_toNoOnly return employees who report to the employee with this Employee Code
end_date_toNoReturn employees whose termination date is on/before this date (format yyyy-mm-dd)
max_recordsNoOptional client-side limit on the number of records returned. Use to keep responses small when exploring data; the API itself does not paginate.
birth_date_toNoReturn employees whose birth date is on/before this date (format yyyy-mm-dd)
end_date_fromNoReturn employees whose termination date is on/after this date (format yyyy-mm-dd)
is_terminatedNoOnly return terminated employees (true/false)
start_date_toNoReturn employees whose employment start date is on/before this date (format yyyy-mm-dd)
birth_date_fromNoReturn employees whose birth date is on/after this date (format yyyy-mm-dd)
gender_identityNoOnly return employees with this gender (M/F or full extended identity string)
start_date_fromNoReturn employees whose employment start date is on/after this date (format yyyy-mm-dd)
employment_statusNoOnly return employees with this employment status
eligible_for_rehireNoOnly return employees who are eligible for re-hiring (true/false)
Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It explains that the operation returns summary details and lists the fields, clarifies that the API does not paginate (via the max_records parameter description), and even notes the API quirk about the 'group' field always being called 'group' internally. These are useful behavioral details that go beyond a simple 'list.' However, it does not explicitly state that this is a read-only and safe operation, though that is strongly implied.

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?

The description is exactly two sentences. The first sentence states the purpose and result type, the second sentence directs to get_employee for deeper detail. It is front-loaded, direct, and contains no filler. Every clause adds value without redundancy.

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?

The tool has 21 optional parameters and no output schema, so the description must fill gaps. It does by listing the exact summary fields returned and by pointing to get_employee for richer data. It also communicates the non-pagination behavior through max_records, which is crucial for handling potentially large result sets. Yet, it does not specify the default response size or warn about very large result sets when no filters are applied, which would have been helpful given the exploratory nature spotlighted in max_records.

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?

The input schema already provides 100% coverage with each parameter having a descriptive comment. The description itself adds little parameter-level meaning beyond the schema, except that it mentions 'optional filters' generically and the max_records note is also in the schema. Given the high schema coverage, a baseline score of 3 is appropriate; the description does not need to compensate.

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?

The description opens with a specific verb-resource pair: 'Get a list of employees in HR Partner,' immediately clarifying the tool's function. It further distinguishes from the sibling 'get_employee' by noting that this returns summary details, and it lists the summary fields, which clearly separates this list endpoint from more detailed retrieval tools.

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 provides clear directional guidance: for full details including contacts, addresses, and custom fields, it directs users to 'get_employee' with the employee code. It implies that this tool is for browsing or searching with optional filters, but does not explicitly enumerate scenarios where this tool should not be used (e.g., when needing specific contact or address data). This is a minor gap given the sibling list tools, but the main alternative is addressed.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HR-Partner/hrpartner-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server