Retrieve employee or user data from SuccessFactors using user ID, employee ID, or email, with optional field selection.
Retrieve employee/user data from SuccessFactors. Returns specified fields for a user by USERID, EMPID, or EMAIL.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional: Specific fields to retrieve. If not provided, returns all standard fields. | |
| userId | Yes | User ID (USERID), Employee ID (EMPID), or Email address to query |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Retrieve' and 'Returns' clearly indicate a read-only lookup with no side effects, but it does not disclose permissions, error behavior, or what happens when no user is found. The main behavioral trait is adequately conveyed, though not richly.
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?
The description is a single, front-loaded sentence with no wasted words. It states the resource, action, and key parameters in a tight format that is easy to parse.
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?
For a simple two-parameter read operation, the description covers the core need, but it lacks guidance on selecting among siblings and does not describe the response shape or behavior when 'fields' is omitted. No output schema exists to fill that gap.
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 description coverage is 100%: the schema already documents both fields and userId with the same USERID/EMPID/EMAIL clarification. The description therefore adds no parameter meaning beyond what an agent can already see in the schema.
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?
The description uses a specific verb ('Retrieve') with a clear resource ('employee/user data from SuccessFactors') and further scopes the operation by identifier type (USERID, EMPID, EMAIL) and return behavior (specified fields). This makes it distinguishable from siblings like get_complete_employee_data (full vs specified fields) and search_user_by_email (exact identifier lookup vs search).
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?
The description implies this is the right tool when you have an exact user identifier and want selected data, but it never explicitly states when to prefer it over sibling tools such as search_user_by_email or get_complete_employee_data. There are no exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.