Skip to main content
Glama

change_permissions

Modify file or directory permissions via chmod by specifying a path and octal mode, such as 0755 for directories or 0644 for files.

Instructions

Change file or directory permissions (chmod)

Input Schema

NameRequiredDescriptionDefault
pathYesFile or directory path
permissionsYesOctal permission mode (e.g. '0755' for directories, '0644' for files)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations supplied, the description carries the entire behavioral burden. 'Change' implies mutation, but the description doesn't disclose that it overwrites existing modes non-reversibly, whether the change applies only to the target or descends into directory contents, what happens on invalid octal strings, or whether elevated privileges are needed. Only the bare chmod reference conveys semantics, and that relies on the agent's prior knowledge.

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

Conciseness4/5

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

A single tight sentence with the resource and mechanism front-loaded and zero filler. It is arguably over-terse for a filesystem mutation, but nothing in the text is wasted.

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?

For a mutation tool with zero annotations and no output schema, the description is too thin: it omits recursion behavior for directories, permission prerequisites, and error conditions. The relatively simple two-parameter schema keeps this from being a total gap, but the definition doesn't give an agent enough to call it safely.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents both 'path' and the octal 'permissions' mode with examples ('0755', '0644'). The description adds no further meaning beyond the term 'chmod', so the baseline of 3 is appropriate.

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?

The description states a concrete verb and resource ('Change file or directory permissions') and names the concrete mechanism ('chmod'), which immediately distinguishes it from sibling file tools like create_file, edit_file, and add_directory_user. It doesn't explicitly contrast with those siblings, but no other tool in the list performs permission changes, so the differentiation is effectively achieved.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites (ownership requirements, needing to be logged in via login_cpanel), and no note on whether directories are changed recursively. The agent must infer all of this from the word 'chmod' alone.

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

Deploy Server

Other Tools