Skip to main content
Glama
Sign In
mesa-clm

mesa-clm

by idss-mesa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ds_make_directory

Create a new directory or collection at a specified path, allowing datasets and annotation records to be organized in the mesa-clm server.

Instructions

Make a new directory (collection).

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": "ds_make_directory"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesThe path to the new directory to create.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/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 burden of behavioral disclosure, and it says nothing about what happens if the directory already exists, whether parent paths are auto-created, whether this is idempotent, or what permissions are required. For a mutation tool with zero annotation coverage these are significant omissions.

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 short sentence with no filler, and the core action is front-loaded. It is efficient, though its brevity shades into under-specification rather than pure tightness.

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?

The tool is low-complexity with one fully documented parameter and no output schema, so little is strictly required. However, as a mutation with no annotations, the description should at minimum cover error/overwrite behavior or path semantics, and it covers neither.

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 single 'path' parameter is documented as 'The path to the new directory to create.' The description adds no syntax, format, or relative-vs-absolute guidance beyond the schema, so the baseline 3 applies.

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 ('Make a new directory') and adds the domain synonym '(collection)' so an agent can map it to CDE terminology. It is clearly distinguishable from siblings like ds_list_directory, ds_move_file, or ds_delete_file. It stops short of explicitly contrasting itself with any sibling, so it is a solid 4 rather than a 5.

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, and no exclusions. It never mentions, for example, that ds_upload_file or ds_copy_file may create directories implicitly, nor what to do if the path already exists. Only the implied usage of the name is available.

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