Create a new folder within a specified parent directory on SAS Viya content or server, enabling Save As operations for files.
Create a folder name in parent on SAS Viya ("content" or "server"), for Save as.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| parent | Yes | ||
| location | Yes |
Changes observed during successful MCP inspections.
v0.10.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say not readOnly and not destructive, which is already weak signal. The description adds no context on permissions required, whether the folder must not already exist, what happens if parent is invalid, or whether the operation is idempotent. For a mutation tool with thin annotations, the description should carry more behavioral burden than it does.
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?
Single sentence, front-loaded with the verb and the essential operands, so it is not bloated. However, the backtick placeholders and parenthetical are awkward for an agent to parse and the sentence tries to pack three concepts without clear separation.
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?
No output schema, no annotations beyond mutation hints, and 0% schema description coverage mean the description must stand alone. It leaves the required location parameter's allowed values ambiguous, gives no return-value or error context, and does not explain the Save as relationship. For a 3-required-parameter mutation tool, this is insufficient.
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?
Schema coverage is 0%, so the schema provides no parameter documentation and the description must compensate. It names three parameters but only loosely: name and parent are shown in backticks without type expectations or format, and location is mentioned only via the parenthetical '("content" or "server")', which does imply an enum without naming it as the location parameter. This is well below what is needed at 0% coverage.
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?
Specific verb (create) plus resource (folder) with the constraint that it lives on SAS Viya under 'content' or 'server'. The 'for Save as' qualifier narrows intent. It is not tautological, but the cryptic quoting of ``name`` and ``parent`` reads like template syntax rather than plain English.
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?
No when-to-use guidance, no stated alternatives, and no indication of prerequisites. Siblings such as viya_files_browse or viya_files_connection are nearby file-system operations, but the description does not distinguish when to mkdir versus browse or save. The 'for Save as' phrase hints at a scenario but is unexplained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.