ZeroWidth Caliper

Replace one item in a Caliper dataset

caliper_datasets_update_item

Destructive

Rewrites one item's content, keeping its id (ratings and eval results keyed to it stay attached). The item's KIND can't change — a Q&A item stays Q&A, a chat item stays chat, a sequence stays a sequence — so pass the same shape you read from caliper_datasets_get. Raw items, and chat items captured with tool calls in them, can't be edited from here. May return needs_confirmation.

Input Schema

Name	Required	Description
`item`	Yes	The full replacement item, same four shapes as caliper_datasets_create.
`itemId`	Yes	Item id, from caliper_datasets_get.
`datasetId`	Yes	Dataset id.
`workspace`	No	Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.
`approvalId`	No	Approval id from a prior needs_confirmation response. Omit on the first call.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 13, 2026

changedInput schema / properties / item / description

Previous value: -"The full replacement item, same three shapes as caliper_datasets_create."New value: +"The full replacement item, same four shapes as caliper_datasets_create."

changedInput schema / properties / item / properties / expectedResponse / description

Previous value: -"Sequence: the standard for the FINAL reply."New value: +"Sequence: the standard for the FINAL reply. Chat: the standard for the next reply."

addedInput schema / properties / item / properties / messages

Added value: +{
+  "description": "Chat: the conversation so far as role/content messages (user and assistant alternating, an optional system first), 1-50. Every assistant message here is FIXED, written by you, not the model; the flow under test writes only the NEXT reply. End on a user message and put the standard for that reply in expectedResponse. This is the shape for testing the 5th reply of a conversation with the first four baked in.",
+  "items": {
+    "properties": {
+      "content": {
+        "type": "string"
+      },
+      "role": {
+        "enum": [
+          "system",
+          "user",
+          "assistant"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "role",
+      "content"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedOct 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds rich context beyond the annotations: the id is preserved so ratings and eval results stay attached, the item KIND is immutable across four shapes, certain item types are not editable, and it may return `needs_confirmation` (a real approval flow, tied to the approvalId param). This is materially more than destructiveHint alone conveys.

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?

Four tight sentences, front-loaded with the core rewrite action, then preservation behavior, then constraints, then the confirmation signal. No filler and nothing redundant with structured fields.

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 destructive single-item mutation with a fully described nested schema and no output schema, the description covers what changes, what is preserved, what is forbidden, and the confirmation flow. Nothing an agent needs to call it correctly is 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 meaning: the `item` must be the same shape/kind read back, and the needs_confirmation response explains when to supply approvalId. That ties two parameters to concrete behavior the schema does not.

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 and resource — "Rewrites one item's content" — and immediately distinguishes itself from sibling caliper_datasets_update by scoping to a single item while keeping its id. An agent can tell it apart from add_items/remove_item/update without opening a schema.

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?

Gives clear operational context: read the item first from caliper_datasets_get and pass the same shape, plus two explicit exclusions (raw items and chat items with tool calls can't be edited here). It stops short of naming which sibling to use for the excluded cases, so it's clear but not fully routing.

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

All ZeroWidth Caliper 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.

Resources

Need Help?