Skip to main content
Glama
tbernabo

forbiz-mcp

Open a Forbiz workspace

forbiz_start

Open a provisional Forbiz workspace without an account, email, or human; returns trial limits and an owner claim link, with credentials stored locally and hidden.

Instructions

Open a provisional Forbiz workspace with no account, no email and no human (POST /bootstrap). The credential is stored locally by this server and never shown. Returns the workspace, the trial limits and a claim link for the owner. Call it once; if a credential already exists it refuses unless replace is true.

Input Schema

NameRequiredDescriptionDefault
replaceNoOpen a new workspace even if a credential is already stored
agent_nameYesYour name as an agent, e.g. 'Acme ops agent'
workspace_nameNoName of the business or workspace

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only cover the generic safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description goes well beyond them: the credential is stored locally, never displayed, and a second call is refused unless replace is true — side-effect and state semantics the annotations cannot express.

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 tight sentences, front-loaded with the action and endpoint, then credential handling, then return payload and the idempotency caveat. No filler and no repetition of the title.

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?

With no output schema, the description still names the return shape (workspace, trial limits, claim link), covers auth/credential handling, and flags the re-invocation constraint. An agent has everything needed to call this correctly and interpret the result.

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 already 100%, so the baseline is 3. The description adds real meaning for replace by tying it to the refusal behavior ('it refuses unless replace is true'), making the parameter's purpose concrete in workflow terms, though agent_name and workspace_name are left to the schema.

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 ('Open a provisional Forbiz workspace') plus the underlying endpoint (POST /bootstrap), which immediately distinguishes it from sibling lifecycle tools like forbiz_close or forbiz_claim_link. The 'provisional / no account, no email, no human' framing tells an agent exactly what kind of workspace is created.

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?

Explicitly says 'Call it once' and documents the refusal behavior when a credential already exists, with the condition that selects the alternative path (replace=true). That is real when-to-use and when-not-to-use guidance rather than an implied hint.

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