Skip to main content
Glama

busabase

by com.busabase
OverviewDiscussionsAdmin

Propose a Base view change (create / update / delete / restore)

view_change_request

Propose a Base view change (create / update / delete / restore)

Review is permission-aware, decided server-side: the change merges immediately when your key has write access on the Base's node and lands as a pending ChangeRequest otherwise — check the response's materialized field to see which happened. Pass requireReview to always propose instead of merging. Views are structure, not content — when you are building starter structure (a Base plus the views that make it usable) let it merge so the workspace is not left half-built behind a review queue, exactly as you would for node_create and POST /bases. create needs the BASE id; update / delete / restore need the VIEW id — the endpoint split follows whichever id identifies the target, which this task handles for you. View order is shared by everyone: a new view joins the end, update with position moves one (0 = leftmost), and the leftmost view is what the Base opens on. Every Base keeps at least one view, so deleting its last one is rejected — create the replacement first. A new Base already starts with a default "Grid view" (every record and field): when you are about to add your own views, create the Base with node_create skipDefaultView (REST defaultView: false) so your first view is the one it opens on.

Input Schema

NameRequiredDescriptionDefault
nameNoView name (create only).
typeNoView type, e.g. `table`, `gallery` (create only).
patchNoChanges to apply to the view (update only).
actionYesWhat to do. Choose this before the other arguments.
baseIdNoBase the view belongs to (create only).
configNoView configuration — filters, sorts, visible fields (create only).
viewIdNoTarget view id.
messageNoExplanation for the reviewer.
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.
positionNoMove the view to this 0-based index among the Base's views (update only); the others shift to make room. 0 makes it the view the Base opens on.
autoMergeNoSkip review and apply the change immediately if you have write access. Not a permission override — a changeRequest-level key still gets a pending CR. Default is permission-aware: merge when you can, otherwise propose.
submittedByNoProducer label recorded on the change.
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 / position
      Added value: +{
+  "description": "Move the view to this 0-based index among the Base's views (update only); the others shift to make room. 0 makes it the view the Base opens on.",
+  "minimum": 0,
+  "type": "number"
+}
  2. 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"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the permission-aware server-side review decision, the `materialized` response field that signals which path was taken, the shared view-order behavior, and the hard constraint that deleting a Base's last view is rejected. Annotations only cover the safety profile, so this added context is valuable.

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-loads the core purpose and permission behavior, then flows into action-id requirements and ordering rules. It is information-dense and mostly earns its length, though the leading parenthetical restates the title and the paragraph runs long for a single block.

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 14-parameter mutation tool with no output schema, the description covers the review/merge semantics, response signal, per-action id requirements, ordering constraints, and destructive-delete guardrail. An agent has everything needed to call it correctly.

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. The description adds meaning beyond the schema by clarifying which id each action consumes and describing the endpoint split, plus reinforcing position semantics and the requireReview/autoMerge distinction, though much of the position detail duplicates 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+resource ('Propose a Base view change') and enumerates the four supported actions (create/update/delete/restore). It clearly distinguishes itself from adjacent change-request siblings like bases_create_change_request and node_files_change_request by scoping to views.

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?

Gives explicit when-to-use guidance: merge when the key has write access, propose otherwise, and pass requireReview to always propose. Provides action-specific id guidance (create needs BASE id; update/delete/restore need VIEW id) and a proactive tip to use node_create skipDefaultView so the workspace isn't half-built behind a review queue.

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
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.

Resources