Skip to main content
Glama

ZeroWidth

by ai.zerowidth
OverviewDiscussionsAdmin

Set up folders and rooms for their work

workspace_setup
Destructive

Creates folders for the work someone described, rooms linked to those folders (with your first message in each, the concrete next step), and starting pieces filed inside. Records what the workspace is for, which orders what home offers first. Use it once you know what they're working on, typically near the end of setting a workspace up. Say in one sentence what you're setting up and call it; the approval card lists the folders, rooms, and pieces, so don't list them in words too. Every workspace already has a General room, so don't recreate it. May return needs_confirmation; then wait for approval.

Starting shapes by kind of work (adapt, drop, or combine; name everything after what they told you):

  • process_redesign: a folder per process being changed ("Claims intake redesign"). Pieces: a Compass page with pageType WORKFLOW describing how it works today, a Napkin diagram of current and proposed steps, a doc for the change plan. Room: " redesign". After setup, offer a Ledger expectation for the metric they want to move.

  • research: a folder per study or question. Pieces: a research-plan doc (question, who, method), a synthesis doc. Room: " research". After setup, offer a Prism field for the question.

  • ai_design: a folder per AI feature. Pieces: a spec doc (what it does, for whom, what good looks like), a Caliper dataset for test cases. Room: the feature's name, with the flow in it once one exists (file an existing flow via existing). After setup, offer to scaffold the flow and a rubric.

  • knowledge: a folder per domain. Pieces: Compass pages for the main topics. Room: "Ask about ".

  • exploring: usually nothing beyond their priorities and the General room; offer one small first thing instead. Priorities are Compass pages made with compass_pages_create before this, not pieces here; name folders after the work that moves them.

Input Schema

NameRequiredDescriptionDefault
foldersYes
workKindsNoWhat the workspace is for, from what they said.
workspaceNoWorkspace slug. Ignored for workspace API keys.
approvalIdNoApproval id from a prior needs_confirmation envelope.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations: discloses the needs_confirmation return and that the agent must wait for approval, explains the approval card already enumerates folders/rooms/pieces, notes the pre-existing General room, and describes the side effect that workKinds orders what home offers first.

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 contract (create folders/rooms/pieces, approval flow) before the detailed recipes, and nearly every sentence earns its place. It is long, but the length tracks the tool's genuine complexity rather than filler.

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 4-param mutation tool with no output schema, the description covers the mutation surface, the approval/confirmation loop, the return-shape caveat, and the domain model needed to populate nested folders/rooms/pieces correctly. Nothing an agent needs to invoke it is missing.

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

Parameters5/5

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

Schema coverage is 75%, and the description adds real semantics on top: folders must be named after the actual work, workKinds drives scope/ordering, priorities are Compass pages created beforehand rather than pieces, and the per-kind recipes map the abstract fields to concrete content.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource set: creates folders, rooms linked to them, and starting pieces, plus records what the workspace is for. This is clearly distinguishable from siblings like workspace_folders_browse, rooms_add_flow, or compass_pages_create, which each handle one piece of the same domain.

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

Usage Guidelines5/5

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

Explicit timing: 'Use it once you know what they're working on, typically near the end of setting a workspace up.' Adds when-not guidance (don't recreate the General room) and routes priorities to compass_pages_create instead. The per-work-kind shapes tell the agent exactly what to build in each scenario.

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

All ZeroWidth toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources