MCPDactyl

Update subuser permissions

subuser_update

Replace a subuser's permission set on a Pterodactyl server. Use it to overwrite access rights and optionally block or hide specific files via the SFTP-permissions addon.

Instructions

Replace a subuser's permission set.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "server": "<server>",
      "user": "<user>",
      "permissions": "<permissions>"
    },
    "name": "subuser_update"
  }
}

Input Schema

Name	Required	Description
`user`	Yes
`extra`	No	Extra body fields merged into the request verbatim. Modified panels add their own subuser fields whose request names do not always match the ones the API returns; this is how to reach them without another deploy.
`panel`	No	Name of a saved panel. Omit to use the active or default panel.
`server`	Yes
`baseUrl`	No	Inline panel URL override, e.g. https://panel.example.com. Not persisted.
`clientKey`	No	Inline client API key (ptlc_…) override. Not persisted.
`denyfiles`	No	SFTP-permissions addon: paths this subuser may not see or touch. Anything absent from the list stays readable, so treat it as a blocklist and keep it complete.
`hidefiles`	No	SFTP-permissions addon: hide the denied paths outright instead of only blocking them.
`permissions`	Yes
`applicationKey`	No	Inline application API key (ptla_…) override. Not persisted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. 'Replace' hints that existing permissions are overwritten rather than merged, which is useful, but it says nothing about required auth, the effect of the extra/panel/clientKey overrides, or what happens to permissions omitted from the request. For a 10-parameter mutation with zero annotation coverage this is a thin disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with zero filler, but the brevity comes at the cost of substance rather than from disciplined editing. It is concise without being informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with 10 parameters, nested extra object, no annotations and no output schema would need the description to cover preconditions, overwrite semantics and validation rules. The single sentence covers only the overwrite idea, leaving an agent unable to call it confidently with the required fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 70%, below the high-coverage threshold, and the three required parameters (server, user, permissions) have no schema descriptions at all. The description does not explain what form permissions takes (strings, validated against permissions_list, minimum one entry) or how extra fields are merged. It adds no parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Replace a subuser's permission set.' An agent knows this is a permission-set write on a subuser. However it does not distinguish this from sibling subuser_set_files, which also changes file-related permissions, leaving ambiguity about which tool owns permission updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance and no mention of alternatives, despite sibling tools subuser_create, subuser_get, subuser_set_files and subuser_delete existing in the same family. The agent must infer that this tool is for changing permissions on an already-existing subuser.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server