Create an FTP account on a 1Panel v1 server by specifying username, password, and directory path. Use it to grant file access for uploads or downloads.
Create FTP user
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| password | Yes | ||
| userName | Yes | ||
| description | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure, yet it only implies a mutation ('Create') without stating permissions required, whether the user is immediately active, how the path restricts access, or what happens on duplicate usernames. It conveys the bare minimum side-effect signal but no meaningful behavioral context.
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 brief phrase, but it is under-specified rather than genuinely concise. Every word is front-loaded, yet the phrase fails to earn its place by adding any information beyond the tool name.
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 mutation tool with no annotations, no output schema, and four undocumented parameters, the description is completely inadequate. It omits usage context, parameter meaning, behavioral side effects, and return expectations.
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?
With four parameters and 0% schema description coverage, the description must compensate for the schema's silence, but it provides no information about userName, password, path, or description. An agent gets zero semantic guidance on any input.
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 pairs a specific verb ('Create') with a specific resource ('FTP user'), making the core operation unambiguous and readily distinguishable from siblings like update_ftp_user, delete_ftp_user, and list_ftp_users. However, it offers no explicit sibling differentiation or scope detail beyond the name itself.
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 tool versus alternatives, no prerequisites, and no indication of required context. The description simply states the operation with no usage framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.