Skip to main content
Glama

busabase

by com.busabase
OverviewDiscussionsAdmin

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

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoDoc body in Markdown (--type doc only).
nameYesHuman-readable node name.
slugYesURL-safe identifier, lowercase letters/digits/hyphens only.
typeYesNode type to create.
filesNoSeed 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.
fieldsNoBase fields (--type base only): [{"slug":"title","name":"Title","type":"text"}]. A Base needs at least one field.
assetIdNoBacking Asset id (--type file only). Upload the Asset first.
messageNoExplanation for the human reviewer. Conventional-commit style, e.g. "Add Products Base for the Q3 catalog".
versionNoSkill/Drive/AirApp only. Defaults to 0.1.0.
playbookNoOptional. 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.
autoMergeNoSkip review and create immediately if you have write access. Default is permission-aware: merge when you can, otherwise propose.
mergeModeNoSkill/Drive/AirApp only. "merge" (default) layers files over the default scaffold; "replace" uses only the files given.
visibilityNoSkill/Drive/AirApp only. Defaults to private.
descriptionNoOptional node description.
submittedByNoProducer label recorded on the change.
agentPromptsNoScenario 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`.
parentNodeIdNoParent folder node id. Omit to create at the space root.
requireReviewNoAlways propose a pending ChangeRequest, even with write access.
targetSpaceIdNoBusabase space id. Call auth_verify first and ask the user which space to use when more than one is returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With only generic annotations, the description carries the behavioral burden and does so thoroughly: review is permission-aware and decided server-side, with immediate merge on write access versus a proposed ChangeRequest otherwise. It also discloses that agentPrompts are stored in a second call and are skipped (and reported) when a ChangeRequest is proposed, and it explains the default scaffold-merging behavior for files. There is no contradiction with the readOnlyHint=false, destructiveHint=false annotations.

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?

The opening sentence is clear and front-loaded, and every subsequent sentence contributes practical guidance: pre-checking playbooks, permission-aware review, and the agentPrompts timing caveat. The text is dense and somewhat run-on for a 19-parameter tool, but it earns its length; light formatting or bullets could improve scannability without changing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with no output schema and only generic annotations, the description covers the key invocation context: when to consult playbooks_search, when a ChangeRequest is proposed instead of a merge, how type-specific payloads vary, and what happens with agentPrompts. The main omission is an explicit return contract (merged node object vs. pending ChangeRequest), though the word 'reported' offers a hint about the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds cross-parameter meaning that the schema alone does not provide: it maps each node type to its specific payload parameter (fields, body, files, assetId) and clarifies how requireReview, autoMerge, and agentPrompts interact with the creation/review flow. It also explains the 'one call, any of 11 node types' design, which helps an agent choose which parameter is relevant for a given type.

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?

The description states a specific verb and resource: 'Create a workspace node of any type,' and immediately expands into the concrete scope: one call creates any of the 11 node types with its type-specific payload. It distinguishes itself from related flows by describing how the call may either merge or propose a ChangeRequest, and by routing playbook lookups to playbooks_search. This is far from a tautology and gives an agent a precise mental model.

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?

The description gives clear context: call playbooks_search first if a playbook may already exist, pass requireReview when you want to force a ChangeRequest, and use nodes set-agent-prompts afterward when agentPrompts could not be stored. It does not explicitly name the sibling nodes_create_change_request or state when to prefer that tool instead, so it stops just short of a full when-not/alternatives declaration.

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

All busabase toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources