busabase

Propose a Base schema change (add / update / delete / convert / reorder / restore)

base_field_change_request

Propose a Base schema change (add / update / delete / convert / reorder / restore)

Review is permission-aware for every operation, 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 status. Pass requireReview to always propose instead. Worth doing on delete and convert when the data matters: delete soft-deletes the field's stored values with it (restore brings both back), and convert can drop values that do not fit the new type. Pick operation first, then supply only that operation's arguments — add needs slug+name; update needs fieldId+patch; delete/restore need fieldId; convert needs fieldId+newType; reorder needs the complete fieldIds order. Before a convert, bases_preview_field_conversion shows what the data would become.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New field display name (add only).
`slug`	No	New field slug (add only).
`patch`	No	Changes to apply, e.g. {"name":"Status","required":true} (update only).
`baseId`	Yes	Base to change.
`fieldId`	No	Target field id.
`message`	No	Explanation for the reviewer.
`newType`	No	Field type to convert to (convert only).
`options`	No	Field type options, e.g. {"choices":[{"id":"live","name":"Live"}]} (add only).
`fieldIds`	No	Complete field order (reorder only). Repeat the flag per field.
`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.
`required`	No	Mark the new field required (add only).
`autoMerge`	No	Skip review and apply the schema 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.
`fieldType`	No	New field type, defaults to text (add only).
`operation`	Yes	What to do to the schema. Choose this before the other arguments.
`submittedBy`	No	Producer label recorded on the change.
`requireReview`	No	Always propose a pending ChangeRequest, even with write access. Worth passing on delete and convert when the field holds data you would not want dropped without a second look.
`targetSpaceId`	No	Busabase space id. Call auth_verify first and ask the user which space to use when more than one is returned.
`selectChoiceMode`	No	Converting into a select: create missing choices, or null the value out. Defaults to null_on_missing.

Schema Changelog

Changes observed during successful MCP inspections.

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

A5/5.0

Behavior5/5

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

The description enriches the sparse annotations (readOnlyHint=false, destructiveHint=false) with the permission-aware merge/pending behavior, soft-delete semantics, convert value-dropping risk, and effects of autoMerge/requireReview. This is exactly the behavioral context an agent needs. There is no contradiction with annotations.

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?

For an 18-parameter tool with six operation modes, the description is remarkably well-structured: purpose, then permission behavior, then per-operation argument mapping, then a targeted tip. Every sentence serves a distinct informative purpose; nothing is redundant.

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?

Given the tool's complexity, the description covers operation selection, required arguments per operation, permission flow, data-loss warnings, and even points to a preview helper. The absence of an output schema is mitigated by the instruction to check the status field. The description leaves no critical gap for correct invocation.

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?

While schema coverage is 100%, the description adds critical cross-parameter dependencies (which arguments belong to which operation), explains the default behavior of autoMerge and requireReview, and clarifies magic parameters like selectChoiceMode and playbook. This surpasses the schema's isolated descriptions.

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 clearly states a specific verb ('Propose') and resource ('Base schema change') with all six operations enumerated. It differentiates itself from sibling tools like bases_create_field (field creation only) and bases_create_change_request (generic) by specifying the full scope of schema mutations.

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 explains when to use requireReview and autoMerge, and warns when to be cautious (delete/convert on valuable data). It even instructs to use bases_preview_field_conversion before a convert, and dictates the per-operation argument sets. This is textbook usage guidance.

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

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.

Propose a Base schema change (add / update / delete / convert / reorder / restore)

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources