Skip to main content
Glama

busabase

by com.busabase
OverviewDiscussionsAdmin

Propose a change to an existing record (update / delete / restore)

record_change_request

Propose a change to an existing record (update / delete / restore)

If this job may already have a playbook, call playbooks search first. Review is permission-aware for all three operations, 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 explicit autoMerge: false to force review even when you could write directly. delete ARCHIVES the record — it is reversible with restore, not an erase. For update, fields is keyed by field slug and only needs the fields you are changing; if you set the Base's PRIMARY (first) field, keep it a short human-readable title.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNoNew values keyed by field slug, e.g. {"status":"published"} (update only).
messageNoExplanation for the reviewer — imperative verb + what + why, e.g. "Update deal stage to qualified — demo booked".
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.
recordIdYesRecord to change.
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.
operationYesWhat to propose. Choose this before the other arguments.
submittedByNoProducer label recorded on the change.
requireReviewNoAlways propose a pending ChangeRequest instead of applying the change, 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?

The description discloses key behavioral traits beyond annotations: delete archives (reversible via restore), the merge-vs-pending decision based on write access, the role of autoMerge and requireReview, and the response's materialized field. It also explains that update fields only need changed values and the primary field should be a short title. This is rich, non-contradictory context.

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 description is information-dense but well-organized: it starts with the purpose, then covers playbook search, permission behavior, autoMerge, delete semantics, and field usage. It's long but justified given the complexity of 9 parameters and nuanced behavior. It avoids redundancy and front-loads the most critical usage points.

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?

The description proactively covers the key decision points an agent needs: when to run playbooks_search first, how permissions affect the merge, how to force review, what delete means, and how to handle fields. It also points to the materialized field in the response, compensating for the lack of an output schema. It is thorough for a tool of this complexity.

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 the baseline is 3. The description adds value by clarifying that 'fields' is keyed by slug and only needs changed fields, and that the primary field should be a short human-readable title. It also clarifies autoMerge is not a permission override. These insights go beyond the schema 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 the tool's purpose: 'Propose a change to an existing record (update / delete / restore)' and details the three operations. It distinguishes from siblings by specifying 'record' versus base/node and by noting delete archives and restore reverses, making it unambiguous among the many change-request tools.

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 provides clear context on when to use the tool, including a recommendation to call playbooks_search first if a playbook may exist, and explains the permission-aware merge vs. pending behavior. It also instructs how to force review with autoMerge: false. However, it doesn't explicitly exclude alternatives like nodes_create_change_request, relying on the title and context to differentiate.

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