Retrieve Netlify account user details for the authenticated user. Use this read-only operation to fetch current user information when you need to identify the account owner.
Select and run one of the following Netlify read operations (read-only) get-user
| Name | Required | Description | Default |
|---|---|---|---|
| selectSchema | Yes |
Changes observed during successful MCP inspections.
v1.0.1Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / selectSchema / additionalPropertiesRemoved value: -falseInput schema / properties / selectSchema / properties / params / additionalPropertiesRemoved value: -falsev1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats the readOnlyHint annotation with '(read-only)' and adds little behavioral context. It does not explain what get-user does, whether authentication is needed, or how results are returned. It does not contradict the annotation, but it also does not go beyond it.
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 short sentence, so it is concise, but the phrasing 'Select and run one of the following Netlify read operations (read-only) get-user' is redundant because only one operation is listed. The structure is passable but not polished.
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?
Given a nested schema, no output schema, and no parameter documentation, an agent needs to know what get-user returns and what inputs are required. The description only names the operation, leaving the call underspecified for correct invocation.
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%, so the description must compensate, but it only mentions the operation name already enforced by the const 'get-user'. The nested selectSchema wrapper, empty params object, aiAgentName, and llmModelName fields remain unexplained.
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 names the operation 'get-user' and labels it 'read-only', making the tool's purpose as a Netlify user read operation clear. The 'user' in the tool name and the get-user operation differentiate it from sibling service readers, though the phrase 'one of the following' is awkward when only one operation is listed.
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?
No guidance is provided about when to use this tool versus sibling readers (deploy, team, project, extension). The description only names the operation and gives no context for selection or exclusions, leaving an agent to infer the domain from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.