Skip to main content
Glama

Make a folder

folder

Create a named document directory and optionally set its icon, color, or parent; reuse an existing one by name without moving or deleting content.

Instructions

Make a folder for documents, and give it an icon and a colour if they fit. If a folder by that name is already there it is used as it is — and without inside, one by that name is found however deep it sits, so a name you mean as a new top-level folder may hand you one inside another. An icon or colour you send changes how it looks; nothing is renamed, moved or deleted. Folders hold documents, not tasks; tasks go in lists.

Input Schema

NameRequiredDescriptionDefault
iconNoA single emoji, or one name from the drawn catalogue: home, work, money, study, travel, health, food, family, code and the like. An emoji is often the plainer choice
nameYesA word or two, at most 40 characters. It is the folder's own name, never a path: send the whole path only to say where to nest it, and then every step but the last has to exist already
colorNored, orange, amber, green, teal, blue, indigo, purple, pink, brown or gray
insideNoAn existing folder to nest it in, by its name, its whole path or its id. Four deep at most

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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 burden and does so well: it discloses idempotent behavior when a same-named folder exists, the surprising deep-search lookup when `inside` is omitted, and that icon/colour changes affect appearance only ('nothing is renamed, moved or deleted'). It is missing return-value expectations and any permission/auth notes, which keeps it from a 5.

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?

Front-loaded with the core action and sized tightly at four sentences. The second sentence is long and nested, bundling idempotency and the `inside` pitfall together, but every sentence carries useful information and none feel like padding.

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?

For a mutation tool with no annotations and no output schema, the description covers the important behavioral risks: idempotency, surprising lookup scope, appearance-only changes, and domain boundaries. It leaves the success response and error conditions (e.g., invalid icon/color) unaddressed, which is a modest gap given the otherwise thorough coverage.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds value beyond it by explaining the consequence of omitting `inside` (global name lookup regardless of depth) and reinforcing that `name` is not a path. That is meaningful semantic guidance rather than repetition.

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 folder for documents') and adds a domain boundary ('folders hold documents, not tasks; tasks go in lists') that separates it from the task/list siblings. It does not explicitly contrast with the doc-centric siblings (write_doc, file_doc, etc.), so it falls just short of full sibling differentiation.

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?

Implies when to use it (organizing documents) and gives one explicit exclusion and alternative ('tasks go in lists'). It also supplies a crucial usage warning about omitting `inside`, but stops short of a full when/when-not map or naming the sibling to use for other organization operations.

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