Skip to main content
Glama

Save Tunc Orb data

data_write

Save new data to the user's Tunc Orb: create a named record, or append entries to a log (it is created when absent). Use it when the user asks you to save, record or hand off something, such as a note, decision, approval, result, processed-item state or resume point. Records and logs are kept until deleted. Give each record a clear name and a one-line about so it can be found again, and look the name up with data_read first so you do not create an overlapping record. create never overwrites an existing record and append only adds entries, so no record or log entry is changed or removed: change a record with data_update and remove data with data_delete. When storage is full, saving removes the user's oldest saved files first to make room and the result says how many were removed; records and logs are never removed to make room. Batch log entries. Each call sends at most 64 KiB (one value, or one batch of log entries); a record can hold up to 16 MiB, so grow a larger one with data_update patches. When a record points at a stored file, keep the file's artifact_id, not its viewer link: the id opens the file with art_read, and the link is only for people. The service handles encryption and storage; when you retry a call, send the same mutation_id so it never applies twice.

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": "data_write"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoExact record or log name (UTF-8, at most 512 bytes, never normalized). Required for every operation. Collections are naming conventions such as contacts/<id>.
textNoUTF-8 text payload (exact bytes are kept). create only: exactly one of value or text.
aboutNoOne line (at most 160 characters) saying what the record or log holds, so other agents can find it. Required for create and for append when the log does not exist yet.
valueNoJSON payload (any JSON value; null is a real value). create 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.
entriesNoappend only: 1-100 entries, at most 64 KiB in total. The service assigns entry IDs and order.
shelf_idNoShelf 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.
operationYescreate: new record only if the name is free (name, about, one payload). append: add entries to a log, creating it when absent (name, entries; about when creating).
mutation_idNoOptional: 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.

  1. Changed2 schema fields changed
    • addedInput schema / properties / entries / 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"
      +]
  2. Changed6 schema fields changed
    • removedInput schema / properties / if_revision
      Removed value: -{
      -  "description": "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.",
      -  "type": "string"
      -}
    • changedInput schema / properties / operation / description
      Previous value: -"create: new record only if the name is free (name, about, one payload). replace: whole new value (name, if_revision, one payload; optional about). patch: JSON Patch on a JSON record (name, if_revision, patch). append: add entries to a log, creating it when absent (name, entries; about when creating)."New value: +"create: new record only if the name is free (name, about, one payload). append: add entries to a log, creating it when absent (name, entries; about when creating)."
    • changedInput schema / properties / operation / enum
      Previous value: -[
      -  "create",
      -  "replace",
      -  "patch",
      -  "append"
      -]New value: +[
      +  "create",
      +  "append"
      +]
    • removedInput schema / properties / patch
      Removed value: -{
      -  "description": "patch only: ordered JSON Patch (RFC 6902 subset add, remove, replace, test). If any operation fails, nothing changes.",
      -  "items": {
      -    "additionalProperties": false,
      -    "properties": {
      -      "op": {
      -        "enum": [
      -          "add",
      -          "remove",
      -          "replace",
      -          "test"
      -        ],
      -        "type": "string"
      -      },
      -      "path": {
      -        "description": "JSON Pointer, e.g. /status or /items/0/state.",
      -        "type": "string"
      -      },
      -      "value": {
      -        "description": "New value for add/replace, expected value for test."
      -      }
      -    },
      -    "required": [
      -      "op",
      -      "path"
      -    ],
      -    "type": "object"
      -  },
      -  "maxItems": 200,
      -  "minItems": 1,
      -  "type": "array"
      -}
    • changedInput schema / properties / text / description
      Previous value: -"UTF-8 text payload (exact bytes are kept). Exactly one of value or text."New value: +"UTF-8 text payload (exact bytes are kept). create only: exactly one of value or text."
    • changedInput schema / properties / value / description
      Previous value: -"JSON payload (any JSON value; null is a real value). Exactly one of value or text for create/replace, at most 64 KiB. Keep records small: save a larger file as a file and keep its artifact_id here."New value: +"JSON payload (any JSON value; null is a real value). create 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."
  3. Changed1 schema field changed
    • changedInput schema / properties / value / description
      Previous value: -"JSON payload (any JSON value; null is a real value). Exactly one of value or text for create/replace, at most 64 KiB. Store larger files in Tunc Art."New value: +"JSON payload (any JSON value; null is a real value). Exactly one of value or text for create/replace, at most 64 KiB. Keep records small: save a larger file as a file and keep its artifact_id here."
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that full storage evicts the user's oldest saved files (with a count in the result) while records/logs are never evicted, that create never overwrites and append only adds, the 64 KiB per-call and 16 MiB per-record limits, that encryption/storage is handled server-side, and the mutation_id retry semantics. Notably, the eviction of saved files is a side effect not conveyed by destructiveHint=false, but the description surfaces it rather than hiding it.

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?

Purpose and the create/append split are front-loaded, and nearly every sentence carries distinct information. It is long, though, and a few points (about, mutation_id) are stated in both the description and the schema descriptions, which is mild redundancy rather than waste.

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?

With 8 parameters, no output schema, and multiple subtle behaviors (idempotent retries, eviction, size ceilings, file references), the description covers everything an agent needs to invoke it correctly, including what the result reports back after eviction.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description still adds decision-relevant meaning: batch log entries, grow large content via data_update patches instead of one call, keep artifact_id rather than the viewer link when a record points at a file, and give records a clear name plus one-line about. The operation enum and mutation_id are explained in operational terms, not just restated.

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?

Opens with a specific verb-plus-resource statement ('Save new data to the user's Tunc Orb') and immediately disambiguates the two modes: create a named record vs. append entries to a log. An agent can distinguish this from data_read/data_update/data_delete without opening any 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?

Explicitly states when to use it ('when the user asks you to save, record or hand off something'), lists concrete example payloads, and names the correct alternatives for adjacent intents: change with data_update, remove with data_delete, look up the name with data_read first to avoid overlaps. This is close to a routing table.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources