forbiz-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FORBIZ_API_KEY | No | Optional Forbiz credential. If omitted, the agent opens a provisional workspace via forbiz_start and the credential is stored in ~/.forbiz-mcp/credential.json. Credentials starting with fbzr_ are exchanged automatically for a short-lived token. | |
| FORBIZ_API_BASE | No | Base URL of the Forbiz Agent API. | https://forbiz.io/api/public/agent |
| FORBIZ_MCP_HOME | No | Directory where the MCP server stores its local state (e.g. credential.json). | ~/.forbiz-mcp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| forbiz_startA | 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. |
| forbiz_meA | Workspace, agent identity, capabilities, plan and limits of the current credential (GET /me). Call this first. |
| forbiz_claim_linkA | A link the human owner opens to take ownership of a provisional workspace (POST /claim-link). Give it to the owner; the agent keeps working after the claim. |
| forbiz_nextB | The single next thing that needs attention, with its handoff (GET /next). |
| forbiz_promptsA | Everything waiting, grouped (needs_decision, needs_feedback, waiting, needs_review_date), each with timing.available_commands: what you may do right now (GET /prompts). |
| forbiz_stateB | Overview of the workspace: queues, counts and next priorities (GET /state). |
| forbiz_searchA | Full-text search across actions, evidence, people, organizations, projects, outreach and decisions (GET /search). To resume a commitment by its key, use forbiz_commit with the same commitmentKey instead: the 409 returns it. |
| forbiz_agentsA | Every agent of this workspace with its activity and a plain track record over the actions it created: created, executed, signal recorded, outcomes, overdue (GET /agents). Counts only, no ranking. |
| forbiz_commitA | Record an action you will take or took, with the signal you expect back (POST /actions). Always send a commitmentKey (a short stable id for the objective, e.g. 'acme/quote-followup') and expectedSignalAt. A second open commitment with the same key is refused 409 COMMITMENT_ALREADY_OPEN and the body returns the open one: that is how you resume. A look-alike is refused 409 POSSIBLE_DUPLICATE: resend with confirm_new true only if it is a different objective. |
| forbiz_get_actionA | Full state of one action: expected signal, dates, lifecycle, outcome (GET /actions/{id}). |
| forbiz_action_historyB | Chronological changes of one action and who made each one, agent or human (GET /actions/{id}/history). |
| forbiz_mark_executedB | Record that the action really happened (POST /actions/{id}/execute). Only when it did: never mark as executed without evidence that the act occurred. |
| forbiz_record_signalA | Record what actually happened after the action (POST /signals). A signal is written once; a correction is a new record. |
| forbiz_check_signalA | Record that you looked for the expected signal (POST /actions/{id}/signal-checks). not_found_in_source REQUIRES source and period: it says where you looked and when, never that a third party did not answer. found closes nothing; link the signal with forbiz_record_signal. cannot_check REQUIRES reason. |
| forbiz_postponeC | Push the date the signal is expected (POST /actions/{id}/postpone). |
| forbiz_closeC | Resolve an action with its outcome (POST /actions/{id}/close-loop). |
| forbiz_close_without_signalA | Close an action that will not get a signal, saying why (POST /actions/{id}/close-without-signal). Silence is not rejection: say what you know. |
| forbiz_add_evidenceA | Append what you observed, were told, inferred or decided (POST /context/evidence). Append-only epistemic history: nothing becomes workspace truth automatically, and a contradiction never erases what it contradicts. |
| forbiz_find_evidenceB | Recover evidence by text or subject (GET /context/evidence). Each item carries its source and its contradiction and supersession pointers. |
| forbiz_requestA | Escape hatch for any other route of the Forbiz Agent API (https://forbiz.io/openapi.json): projects, decisions, delegations, outreach, policies, export, purchases. The path is relative to the API base, e.g. '/projects' or '/decisions/recommendation'. Forbiz enforces capabilities server-side. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Tools largely target distinct resources and lifecycle steps, and the descriptions explicitly separate similar-looking operations. A few pairs remain easy to confuse—next/prompts/state all surface pending work, and search/find_evidence both retrieve evidence—but the descriptions usually resolve the choice.
All tools use the same forbiz_ prefix and snake_case, with no casing or abbreviation chaos. The only inconsistency is that some names are verb phrases (forbiz_commit, forbiz_get_action) while others are noun-like views (forbiz_state, forbiz_agents), so the pattern is readable but not uniformly verb_noun.
20 tools is on the heavy side for an MCP server and pushes the practical limit before agents must sift through many closely related lifecycle calls. While most tools map to distinct operations, some read-only views and status checks could arguably be consolidated.
The core action lifecycle is well covered: commit, execute, check/record signal, postpone, close, close-without-signal, history, and detail. Evidence and workspace bootstrap/ownership are also present, and the generic forbiz_request escape hatch prevents dead ends for projects, decisions, and other API routes, though those domains lack dedicated tools.