Tunc Orb

Update Tunc Orb data

data_update

Destructive

Change a record that already exists in the user's Tunc Orb: replace its whole value, or patch fields of a JSON record. Use it when the user asks you to correct or update something saved earlier. This overwrites the saved value and the previous value cannot be read back, so read the record with data_read first and send its current revision as if_revision; a stale revision is refused with revision_conflict, so reread and decide again. Prefer patch (an ordered JSON Patch; if any step fails nothing changes) for small changes to a JSON record, and replace only when you intend the entire new value. Each call sends at most 64 KiB; a record can hold up to 16 MiB. When you retry, send the same mutation_id so the change applies once. Save new data with data_write and remove data with data_delete.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation": "<operation>",
      "name": "<name>",
      "if_revision": "<if_revision>"
    },
    "name": "data_update"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Exact record or log name (UTF-8, at most 512 bytes, never normalized). Required for every operation. Collections are naming conventions such as contacts/<id>.
`text`	No	UTF-8 text payload (exact bytes are kept). replace only: exactly one of value or text.
`about`	No	Optional: a new one-line description (at most 160 characters) of what the record holds.
`patch`	No	patch only: ordered JSON Patch (RFC 6902 subset add, remove, replace, test). If any operation fails, nothing changes.
`value`	No	JSON payload (any JSON value; null is a real value). replace only: exactly one of value or text, at most 64 KiB. Keep records small: save a larger file as a file and keep its artifact_id here.
`shelf_id`	No	Shelf to use (a stable ID from data_read operation=shelves). Omit to use the current default shelf, which is resolved once and pinned for this call and its retries.
`operation`	Yes	replace: whole new value (name, if_revision, one payload; optional about). patch: JSON Patch on a JSON record (name, if_revision, patch; optional about).
`if_revision`	Yes	Current revision from your latest read or write. Required for replace and patch. A stale revision is rejected with revision_conflict; reread and decide again.
`mutation_id`	No	Optional: an ID you choose once for this change (a UUID, or a mut_ ID from an earlier result) and send again when you retry, so the change never applies twice. Omit it and the service assigns one; the result carries it for data_read operation=status.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

addedInput schema / properties / patch / items / properties / value / type

Added value: +[
+  "object",
+  "array",
+  "string",
+  "number",
+  "boolean",
+  "null"
+]

addedInput schema / properties / value / type

Added value: +[
+  "object",
+  "array",
+  "string",
+  "number",
+  "boolean",
+  "null"
+]

AddedOct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true but the description goes well beyond: the previous value cannot be read back, a pre-read is required, if_revision risk with the revision_conflict error, per-call 64 KiB vs 16 MiB record limits, and retry semantics via mutation_id. This is exactly the extra context the destructive annotation cannot convey.

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?

Front-loads the core action and mode split, then layers prerequisites, limits, and alternatives in a logical order with zero filler. It is dense but long; a few clauses (size limits, mutation_id) could be compressed, keeping it just shy of ideal.

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, 9-param mutation tool with no output schema, the description covers the prerequisites (read first, supply revision), the failure mode (revision_conflict), idempotency handling, and size limits. The note that the result carries mutation_id substitutes well for a missing output schema.

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 baseline is 3; the description still adds real meaning by explaining patch-vs-replace payload requirements, the retry contract for mutation_id, and the size-ceiling distinction between call and record. It stops short of detailing the JSON Patch ops or if_revision provenance, which the schema already carries.

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 ('Change a record that already exists in the user's Tunc Orb') and immediately breaks it into the two modes (replace whole value / patch JSON fields). It explicitly distinguishes itself from siblings (data_write, data_delete), so an agent can route correctly without opening another schema.

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?

Gives an explicit trigger ('when the user asks you to correct or update something saved earlier'), a clear patch-vs-replace decision rule ('Prefer patch for small changes... replace only when you intend the entire new value'), and names the alternatives (data_read for pre-read, data_write, data_delete). Nothing is left to inference.

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

All Tunc Orb 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?