Get user by id
snipeit_get_userRetrieves a Snipe-IT user record by ID, returning account details for lookups and integrations.
Instructions
GET /users/{id}
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
snipeit_get_userRetrieves a Snipe-IT user record by ID, returning account details for lookups and integrations.
GET /users/{id}
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Changes observed during successful MCP inspections.
v0.2.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds nothing beyond the raw path: no auth/permission notes, no indication of what is returned, no behavior if the id does not exist (404 vs empty).
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?
Extremely short and front-loaded with zero waste, but its brevity comes from omission rather than precision — it is a bare endpoint reference rather than a compressed explanation.
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?
With no output schema, 0% schema description coverage, and dozens of near-identical user/hardware sibling tools, the description needs to carry more: what a user record contains, id semantics, and how it differs from list_users/me. As written an agent cannot confidently choose this over siblings.
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 0% and the single 'id' parameter is undocumented in the schema. The description only reveals that id is a path segment; it does not clarify that it is the Snipe-IT internal user id (as opposed to username, email, or employee number), which matters given sibling tools keyed on other identifiers.
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 is just the HTTP path 'GET /users/{id}', which together with the title 'Get user by id' does convey retrieving a single user record by identifier. However it offers no natural-language statement of purpose and does nothing to distinguish it from siblings like snipeit_list_users, snipeit_me, or snipeit_gen_usersid, which sit in the same space.
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?
There is no guidance on when to use this versus snipeit_list_users, snipeit_me, or snipeit_get_user_assets/licenses/accessories. The endpoint path implies 'fetch one user by numeric id', but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.