Sora Commander

Overview Schema Source Related Servers Discussions Admin

create_directory

Creates a single absent directory under configured local roots via the Owner GUI, requiring an existing parent and rejecting links, protected names, or existing targets.

Instructions

DEV_ONLY: ask the local Owner GUI to create one absent directory in configured roots. Reject links, protected names and existing targets; no command/job spawn. UNKNOWN requires manual reconciliation, never retry or assumed rollback.

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": {
      "path": "<path>"
    },
    "name": "create_directory"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes	Absolute absent directory under configured Owner roots; existing parent required, no recursive creation.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Nov 9, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden, and it discloses rejection rules, the absence of command/job spawning, and the no-retry/no-assumed-rollback policy for UNKNOWN results. It does not describe required permissions or authentication beyond the implicit 'Owner GUI' context.

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

Conciseness5/5

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

The definition is front-loaded with the DEV_ONLY marker and scope, then packed into compact clauses with no redundant wording. Every sentence adds an operational constraint or failure-mode rule.

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

Completeness4/5

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

Because an output schema exists, return values need not be explained, and the description covers scope, rejection rules, and UNKNOWN handling adequately for a one-parameter mutation tool. Minor gaps around permissions or GUI availability are left implicit rather than stated.

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 coverage is 100%, and the path parameter already documents that it must be an absolute absent directory under configured Owner roots with an existing parent and no recursive creation. The description reinforces the same constraints but adds no format or syntax details 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?

The description states a specific verb and resource ('create one absent directory') and constrains scope to 'configured roots' and the local Owner GUI. It is clearly distinguishable from write tools like create_file, though it does not name a sibling alternative explicitly.

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

Usage Guidelines4/5

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

It gives explicit preconditions and exclusions: targets must be absent, links and protected names are rejected, and no command or job is spawned. It also states that UNKNOWN outcomes require manual reconciliation and must never be retried, which is strong when-not guidance, but it does not name a sibling tool to use instead.

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