writeDatabaseRows
Add rows to a table or change rows, in one of two ways that never mix. Call getDatabase with table first: it gives each field's exact name and choices, how each kind of value is written and which fields are never written. rows (up to 500): written at once, with no mode, changeId or maxRows. A row...
This record as markdown: /tools/io-stablebaseline-sb/writedatabaserows.md
What writeDatabaseRows does on Stable Baseline
AI agents use writeDatabaseRows to create or update resources in Stable Baseline, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Stable Baseline environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
set | object | — | Field name -> a value as in rows, or {"formula": "..."} for each row, such as {"Discount": {"formula": "{Discount} * 100"}}. |
form | string | — | Answer this form (id or name) instead, with answers by field name. |
mode | string | — | Every row that matches only: preview (the default) changes nothing yet; apply does it now. |
rows | array | — | Rows by id, or new rows: written at once, never with mode or changeId. Leave out to change every row that matches. |
stop | boolean | — | With changeId: stop it; what it changed stays. |
undo | string | — | A finished change's changeId: put it back. |
view | string | — | A saved view: its filter picks the rows too. |
match | object | — | The one row of another table (its name, or its id in another database) whose field equals a formula over this row, such as {"table": "Customers", "on": [{"field |
table | string | Yes | The table's id or name. |
where | object | — | Every row that matches: queryDatabaseRows' where. |
answers | object | — | |
matchOn | string | — | A unique field, by name: rows without id (or copied rows) change the row with the same value, or are added. |
Parameters from the server's own tool schema.
Why writeDatabaseRows is rated Medium
An AI agent can call writeDatabaseRows faster than any human can review: one bad instruction and it creates or modifies resources in Stable Baseline by the hundred, each call as confident as the last.
Risk signalsHigh parameter count (28 properties)
Attacks that exploit this kind of access
The rule that runs writeDatabaseRows safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Stable Baseline, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For writeDatabaseRows, this is the rule to start with:
writeDatabaseRows stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Stable Baseline, apply this rule, and every writeDatabaseRows call is checked against it from then on.
Questions about writeDatabaseRows
Add rows to a table or change rows, in one of two ways that never mix. Call getDatabase with table first: it gives each field's exact name and choices, how each kind of value is written and which fields are never written. rows (up to 500): written at once, with no mode, changeId or maxRows. A row without id is added; a row with id is changed, touching only the fields you send, so other people's changes to other fields stay (send strict: true with the version you read to refuse a change when the row has changed since). With matchOn (a field marked unique, such as Email), a row without id changes the row holding the same value, or is added when there is none. The rows changed and the rows added are each all or nothing. Values as getDatabase says: choices by name, people by id or "me", files this job holds as {"fileId": "<id>"}, relations by the linked rows' ids, or {"add": [ids], "remove": [ids]} to change some links and keep the rest (a link field holds up to 10,000 links in one row by default). Or every row that matches, without rows: where (or view) picks them; set gives each field a value or a formula for each row; match reads a row of another table; copyFrom adds another table's rows. It previews (the count, the first rows before and after, a changeId); mode "apply" does it in the same call. One call is enough: never one row at a time. undo puts it back. getDatabaseGuide topic bulk_changes (also joins, copying, formulas). It is categorised as a Write tool in the Stable Baseline MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
writeDatabaseRows accepts 12 parameters: set, form, mode, rows, stop, undo, view, match, table, where, answers, matchOn. Required: table. The full parameter table on this page comes from the server's own tool schema.
Register the Stable Baseline MCP server in PolicyLayer and add a rule for writeDatabaseRows: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Stable Baseline. Nothing to install.
writeDatabaseRows is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the writeDatabaseRows rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for writeDatabaseRows. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
writeDatabaseRows is provided by the Stable Baseline MCP server (https://api.stablebaseline.io/functions/v1/cloud-serve/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Stable Baseline, and thousands of servers like it.
This server
Across the catalogue