Cloche

Save record

save_record

Destructive

Saves a record in a collection an app declares, as the person this call acts for, the way the app's own page does. With no id it adds a record and returns it. With an id and the etag list_records gave it, it replaces only the fields sent on that record, only if it is unchanged since, and returns it. The previous values of those fields are not kept. A person changes only records they may edit. Field values are written by the app's users. With no id, a repeated call adds another record.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	the record to edit, as list_records gave it; omit to add a record
`etag`	No	the record's etag from list_records, required with id
`app_id`	Yes	the app, as list_apps gave it
`fields`	Yes	the record's fields, as the collection declares them; an edit takes only the fields to change
`collection`	Yes	a collection the app declares

Output Schema

TableJSON Schema

Name	Required	Description	Default
`record`	Yes	the stored record

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 11, 2026

addedOutput schema / properties / record / properties / created_by

Added value: +{
+  "description": "the account that wrote the record, in the form user.id takes. Absent when someone wrote it through a share link without signing in, when the platform wrote it, and when the person cannot see who is in the app",
+  "type": [
+    "null",
+    "string"
+  ]
+}

addedOutput schema / properties / record / properties / updated_by

Added value: +{
+  "description": "the account that last changed the record. Absent when that is not known",
+  "type": [
+    "null",
+    "string"
+  ]
+}

AddedOct 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations it discloses concrete behavioral traits: field replacement is partial, prior values "are not kept" (destructive consequence), edits are gated by "records they may edit" (permission model), and a repeated no-id call "adds another record" (non-idempotency, corroborating idempotentHint=false). This is rich, non-redundant behavioral context for a mutation tool.

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 add-vs-edit behavior is front-loaded and every sentence carries information about semantics or constraints. It is slightly dense and the two sentences both opening with "With no id" create mild redundancy, but nothing is wasted.

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 mutation tool with five parameters and a non-trivial add/edit duality, the description covers modes, concurrency (etag), destructive partial replacement, permissions, and idempotency. Since an output schema exists, return-value explanation is correctly omitted, leaving nothing essential missing.

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, but the description adds real meaning: it explains the id/etag pairing and optimistic-concurrency intent, and clarifies that fields "takes only the fields to change" on edit. This goes beyond the schema's field-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 ("Saves a record in a collection an app declares") and clearly splits the two operating modes: add when no id, field-level replace when id+etag are supplied. It references list_records for the etag, implying the read/write pairing, but never explicitly names a sibling it is not, so differentiation is inferred rather than stated.

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?

It gives clear conditions for each mode ("With no id it adds a record", "With an id and the etag list_records gave it, it replaces only the fields sent") and the precondition for the etag coming from list_records. It does not name an alternative tool to use instead or state when not to call it, so guidance is contextual rather than exhaustive.

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

All Cloche tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.