Retrieve employee details by employee ID or full or partial name to access employee ID, manager ID, and email for HR workflows.
Get employee details by employee ID (e.g. "E003") or by name (full or partial).
:param name: Employee ID or name of the employee
:return: emp_id, name, manager_id (None if the employee has no manager) and email
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose the return shape including the manager_id = None case, plus that name matching can be partial. It omits what happens on ambiguous partial matches (multiple hits?), what happens when nothing matches, and any auth/scope requirements, which matters for a lookup with fuzzy matching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short lines, front-loaded with the verb and lookup modes, no filler. The reST :param:/:return: markup is slightly noisy for a one-parameter tool but the content is informative rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, yet the description still adds the useful None-manager detail. What's missing for a fuzzy-matching lookup is the ambiguity/not-found behavior and result cardinality, which an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema says only "Name: string", so the description does real work: it defines the single parameter as either an employee ID (with the "E003" format example) or a name, and allows partial name matching. It doesn't say how partial matches are resolved, which keeps it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get employee details") and both lookup keys (employee ID or name, full or partial), which separates it from add_employee and the leave-balance/history siblings. It does not explicitly name a sibling or state a boundary, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the wording — an agent can infer this is the lookup tool for employee records, but there is no explicit when-to-use/when-not guidance relative to siblings like get_employee_leave_balance or add_employee, and no prerequisites (e.g. permissions, whether the employee must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.