busabase

Create a workspace node of any type

node_create

Create a workspace node of any type

If this job may already have a playbook, call playbooks search first. One call creates any of the 11 node types with its type-specific payload: fields for a Base, body for a Doc, files for a Skill/Drive/AirApp, assetId for a File. Review is permission-aware, decided server-side: this merges immediately when you already have write access on the parent node, and proposes a ChangeRequest for a human otherwise. Pass requireReview to always propose instead of merging. Before you finish: if the person will come back to this node to do the same job again, pass agentPrompts so the node opens with THEIR job on it instead of the node type's generic list.

Input Schema

Name	Required	Description
`body`	No	Doc body in Markdown (--type doc only).
`name`	Yes	Human-readable node name.
`slug`	Yes	URL-safe identifier, lowercase letters/digits/hyphens only.
`type`	Yes	Node type to create.
`files`	No	Seed files for a Skill/Drive/AirApp: [{"path":"SKILL.md","content":"..."}]. Layered over the default scaffold unless mergeMode is "replace" — a path you supply REPLACES the scaffold's file at that path. For --type airapp the project MUST be runnable by `npm run dev`: give package.json a "dev" script running a plain Node server (`node server.js`, Hono or node:http). A bundler dev server (Vite/webpack/Next) and any native-binary dependency CANNOT boot in the AirApp runtime, and browser files must need no build step.
`fields`	No	Base fields (--type base only): [{"slug":"title","name":"Title","type":"text"}]. A Base needs at least one field.
`assetId`	No	Backing Asset id (--type file only). Upload the Asset first.
`message`	No	Explanation for the human reviewer. Conventional-commit style, e.g. "Add Products Base for the Q3 catalog".
`version`	No	Skill/Drive/AirApp only. Defaults to 0.1.0.
`playbook`	No	Optional. The playbook you are following, as `kind:nodeId[:key]` from playbooks_search (e.g. `prompt:nod_123:log-visit`). Recorded on the change request so the person can see which playbook produced it.
`autoMerge`	No	Skip review and create immediately if you have write access. Default is permission-aware: merge when you can, otherwise propose.
`mergeMode`	No	Skill/Drive/AirApp only. "merge" (default) layers files over the default scaffold; "replace" uses only the files given.
`visibility`	No	Skill/Drive/AirApp only. Omit to follow the space default and parent folder, like any other node.
`description`	No	Optional node description.
`submittedBy`	No	Producer label recorded on the change.
`agentPrompts`	No	Scenario prompts shown when someone opens this node and asks an agent for something: [{"key":"log-visit","label":"Log a customer visit","body":"Add a visit record with today's date, the contact I name, and a one-line summary.","intent":"change"}]. Write what the PERSON wants in their own words ("Log a customer visit"), not the operation ("Create a record in Visits") — the node type already covers the operations. These are added after the node type's built-in scenario prompts, so 2-5 real recurring jobs help and a generic pair only repeats the defaults: omit this when you cannot name one. Write only the task: Busabase opens every prompt with a line naming the node and space, so do not write `{target}`. Stored in a second call after the node exists, so they are skipped (and reported) when this call proposes a ChangeRequest instead of creating the node; add them afterwards with `nodes set-agent-prompts`.
`parentNodeId`	No	Parent folder node id. Omit to create at the space root.
`requireReview`	No	Always propose a pending ChangeRequest, even with write access.
`targetSpaceId`	No	Busabase space id. Call auth_verify first and ask the user which space to use when more than one is returned.
`skipDefaultView`	No	Base only. Create the Base WITHOUT its default "Grid view" (a table of every record and field). Only when you add your own views right after with view_change_request — a Base must keep at least one view, and the first one is what it opens on.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / skipDefaultView

Added value: +{
+  "description": "Base only. Create the Base WITHOUT its default \"Grid view\" (a table of every record and field). Only when you add your own views right after with view_change_request — a Base must keep at least one view, and the first one is what it opens on.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / agentPrompts / description

Previous value: -"Scenario prompts shown when someone opens this node and asks an agent for something: [{\"key\":\"log-visit\",\"label\":\"Log a customer visit\",\"body\":\"{target}\\n\\nAdd a visit record with today's date, the contact I name, and a one-line summary.\",\"intent\":\"change\"}]. Write what the PERSON wants in their own words (\"Log a customer visit\"), not the operation (\"Create a record in Visits\") — the node type already covers the operations. These REPLACE the node type's default scenario prompts, so 2-5 real recurring jobs help and a generic pair is worse than none: omit this when you cannot name one. `{target}` expands to a complete sentence naming the node and space, so give it its own line. Stored in a second call after the node exists, so they are skipped (and reported) when this call proposes a ChangeRequest instead of creating the node; add them afterwards with `nodes set-agent-prompts`."New value: +"Scenario prompts shown when someone opens this node and asks an agent for something: [{\"key\":\"log-visit\",\"label\":\"Log a customer visit\",\"body\":\"Add a visit record with today's date, the contact I name, and a one-line summary.\",\"intent\":\"change\"}]. Write what the PERSON wants in their own words (\"Log a customer visit\"), not the operation (\"Create a record in Visits\") — the node type already covers the operations. These are added after the node type's built-in scenario prompts, so 2-5 real recurring jobs help and a generic pair only repeats the defaults: omit this when you cannot name one. Write only the task: Busabase opens every prompt with a line naming the node and space, so do not write `{target}`. Stored in a second call after the node exists, so they are skipped (and reported) when this call proposes a ChangeRequest instead of creating the node; add them afterwards with `nodes set-agent-prompts`."

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / visibility / description

Previous value: -"Skill/Drive/AirApp only. Defaults to private."New value: +"Skill/Drive/AirApp only. Omit to follow the space default and parent folder, like any other node."

Changed1 schema field changedSep 27, 2026

addedInput schema / properties / playbook

Added value: +{
+  "description": "Optional. The playbook you are following, as `kind:nodeId[:key]` from playbooks_search (e.g. `prompt:nod_123:log-visit`). Recorded on the change request so the person can see which playbook produced it.",
+  "type": "string"
+}

First observedSep 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say readOnly=false, destructive=false, openWorld=false; the description adds substantial behavioral context: review is permission-aware and decided server-side, merges on existing write access or otherwise proposes a ChangeRequest, and requireReview forces a proposal. It also discloses that agentPrompts are stored in a second call and silently skipped (and reported) when a ChangeRequest is proposed.

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 playbook routing note, then payload mapping, then review semantics. The agentPrompts paragraph is long and partially restates schema text, but every element is actionable 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 20-parameter creation tool with no output schema, the description covers the essential dynamics: type-specific payloads, server-side review outcome, the requireReview override, and the deferred agentPrompts write. An agent has enough to call it correctly and anticipate either a node or a ChangeRequest.

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 baseline is 3, but the description adds cross-parameter meaning the schema states only piecemeal per-property: the compact payload-to-type mapping and the non-obvious sequencing rule that agentPrompts cannot ride along with a proposed ChangeRequest.

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 ('Create a workspace node of any type') and immediately scopes it: 'One call creates any of the 11 node types with its type-specific payload.' The type-to-payload mapping (fields/body/files/assetId) makes it clearly distinct from siblings like bases_create_change_request or forms_create.

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?

Explicitly routes to playbooks_search first ('If this job may already have a playbook, call playbooks search first') and explains the requireReview vs permission-aware auto-merge decision. It doesn't directly contrast with the near-identical sibling nodes_create_change_request, so it stops short of full alternative routing.

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

All busabase tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Create a workspace node of any type

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources