Skip to main content
Glama

Create a workspace

bootform_create_workspace

Creates a new workspace to group forms, for example one per client, and returns it with its id. Requires the Pro plan or higher. Workspace names don't have to be unique, so check bootform_list_workspaces first rather than creating a second one with the same name. Put forms in it with bootform_create_form's or bootform_configure_form's workspace_id; change it later with bootform_configure_workspace.

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": {
      "name": "<name>"
    },
    "name": "bootform_create_workspace"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesWorkspace name, for example the client's name
time_zoneNoOptional IANA time zone for the workspace's forms, e.g. "Europe/Athens"
allowed_originsNoOptional default origin allowlist for the workspace's forms (forms without their own list inherit it)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=false, so the mutation/no-idempotency profile is covered. The description adds genuinely non-structured context: a plan-tier gate and the non-uniqueness caveat that makes duplicate creation a real risk. It stops short of anything on rate limits or failure modes, so not a full 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?

Four short sentences, front-loaded with what it does, then prerequisites, then avoidance guidance, then follow-on wiring. Every sentence carries information, though the final routing sentence is slightly dense with three sibling names.

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 3-param creation tool with no output schema, the description covers creation scope, plan gating, duplicate avoidance, and the return shape ("returns it with its id"). Nothing an agent needs to call it correctly or decide against calling it 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 name, time_zone, and allowed_origins (including the inheritance behavior for origins) are already documented in the schema. The description adds only indirect meaning to `name` via the non-uniqueness note; it says nothing about time_zone or allowed_origins. Baseline 3 applies.

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?

Opens with a specific verb+resource ("Creates a new workspace") plus the organizing concept ("to group forms, for example one per client") and the return value ("returns it with its id"). The distinction from siblings like bootform_create_form and bootform_configure_workspace is made explicit.

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?

Gives an explicit precondition ("Requires the Pro plan or higher") and a when-not/alternative rule ("check bootform_list_workspaces first rather than creating a second one with the same name"). It also routes the agent forward: put forms in via bootform_create_form/bootform_configure_form's workspace_id, rename later with bootform_configure_workspace.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources