Skip to main content
Glama

Make a workspace

add_workspace

Create a new workspace beside the current one, blank or copied with all contents, and open it in its own window on request.

Instructions

Make a new workspace beside this one, blank or as a copy of this one, and open it in a window of its own. Only when the person asks for one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
copyNoTrue for a copy of this workspace with everything in it; false or left out for a blank one.
nameYesThe workspace's name, as the person calls it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare that this is a non-destructive, non-idempotent mutation with no open-world side effects. The description adds meaningful behavioral context beyond them: the new workspace opens in its own window, and the operation can be a blank slate or a full copy. It does not cover permissions or failure modes, but against the annotation baseline this is useful added detail.

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?

Two short sentences with zero waste. The main action and its modal options come first, and the usage restriction is correctly placed last as a guardrail.

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

Completeness5/5

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

For a simple two-parameter creation tool with annotations covering the safety profile and no output schema, the description covers purpose, options, and usage conditions. Nothing critical for correct invocation is missing.

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%, so both parameters are already fully documented in the input schema. The description restates the blank-versus-copy distinction but adds no syntax, format, or edge-case detail beyond what the schema provides. A baseline 3 is appropriate when the schema does the heavy lifting.

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 (make) and resource (new workspace), and distinguishes the two creation modes (blank or copy of this one). It does not explicitly differentiate itself from sibling tools like open_workspace or restore_workspace, but the word 'new' and the window-opening side effect make the intent clear.

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?

The sentence 'Only when the person asks for one' gives an explicit when-to-use condition, which is more than many definitions provide. It does not mention alternatives or when not to use it, but the condition is clear enough for an agent to act on.

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