Skip to main content
Glama
Sign In

BootForm

by com.bootform
OverviewDiscussionsAdmin

Change a workspace's settings

bootform_configure_workspace
DestructiveIdempotent

Renames a workspace or changes the defaults its forms inherit (allowed origins, time zone, retention). Only the arguments given change. A shorter retention_days that would delete stored submissions is refused with the count until you pass confirm_delete: true, so tell the person the count and ask first.

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

Input Schema

NameRequiredDescriptionDefault
nameNoNew name
time_zoneNoNew IANA time zone; an empty string removes the default
workspace_idYesThe workspace's id (bootform_list_workspaces)
confirm_deleteNotrue confirms that a shorter retention_days may delete submissions already stored. Only pass it after the person agreed to the count the refused call gave.
retention_daysNoDefault for member forms without their own: delete submissions this many days after they arrive (1 up to the plan's period). 0 goes back to the plan's period. Deletion is permanent.
allowed_originsNoNew default origin allowlist; replaces the whole list

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds what the annotations cannot: that a shortened retention_days is refused with a submission count until confirm_delete: true is supplied, and that unspecified fields are left untouched. That is exactly the pre-call behavioral context an agent needs to avoid silent data loss.

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?

Three sentences, no filler: what changes, what happens to omitted arguments, then the destructive-confirmation rule placed where the agent will read it before acting. The order matches the decision sequence.

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?

Six parameters all documented in schema, plus description coverage of the one non-obvious behavior (retention reduction refusal and confirmation). No output schema exists, and the only return detail that matters — the refusal carrying a count — is already stated.

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 baseline is 3; the description earns above that by explaining partial-update semantics and the two-step confirm_delete handshake with the refusal count. It does not add anything on allowed_origins replacing the whole list beyond what the schema already says, so it stops short of 5.

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 and resource ('Renames a workspace') and enumerates the settings it touches (allowed origins, time zone, retention). The phrase 'defaults its forms inherit' scopes it to workspace-level settings, which cleanly separates it from the sibling bootform_configure_form.

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?

Gives a clear operating rule ('Only the arguments given change') and a concrete procedure for the destructive case: report the refused count to the person and ask before passing confirm_delete. It does not explicitly name alternatives such as bootform_configure_form or bootform_create_workspace, so selection among siblings is inferred rather than stated.

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

All BootForm toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources