chartlink

Update a draft (deep-merge patch, or replace the config) — returns an inline preview image

update_asset

Destructive

configPatch is DEEP-MERGED: objects merge recursively, arrays replace wholesale, null clears a key — send only what changes. To REMOVE keys (drop document.aspect, delete one of texts[]) pass config instead: it REPLACES the whole config (get_asset returns the current one to edit). data (if given) replaces rows wholesale. Requires expectedVersion from the last envelope; on 409 re-merge onto the returned current. Updating does NOT publish by default — pass publish: true to publish in the same call, or call publish_asset separately.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`data`	No	Typed columns + row-major rows. A date column whose strings are not ISO-ish takes dateFormat (e.g. "%d/%m/%Y").
`brand`	No
`title`	No
`config`	No	REPLACES the whole config — the way to remove keys; applied before configPatch if both are given
`publish`	No	true = publish immediately after this update succeeds (one call instead of two)
`showcase`	No	Offer this chart as a template in the public gallery and list_templates (once published). Workspace keys only.
`configPatch`	No	Deep-merged onto the current config
`expectedVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 29, 2026

removedInput schema / properties / brand / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / brand / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / data / properties / rows / items / items / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / data / properties / rows / items / items / type
```
Added value: +[
+  "string",
+  "number",
+  "boolean",
+  "null"
+]
```

Changed10 schema fields changedSep 16, 2026

addedInput schema / properties / data / additionalProperties
```
Added value: +false
```

addedInput schema / properties / data / description

Added value: +"Typed columns + row-major rows. A date column whose strings are not ISO-ish takes dateFormat (e.g. \"%d/%m/%Y\")."

addedInput schema / properties / data / properties / columns / items / additionalProperties
```
Added value: +false
```

addedInput schema / properties / data / properties / columns / items / properties / dateFormat

Added value: +{
+  "description": "For date columns whose strings are NOT ISO-ish: a strftime-style parse hint tried first — tokens %Y %m %d %b %B %q %H %M %S, e.g. \"%d/%m/%Y\" for \"15/03/2024\", \"%b %Y\" for \"Mar 2024\". Removes the day/month guess; ISO-ish strings never need it.",
+  "type": "string"
+}

addedInput schema / properties / data / properties / columns / items / properties / id / description
```
Added value: +"Column identifier referenced by encodings"
```
addedInput schema / properties / data / properties / columns / items / properties / id / minLength
```
Added value: +1
```
addedInput schema / properties / data / properties / columns / items / properties / label / description
```
Added value: +"Display label; defaults to id"
```

addedInput schema / properties / data / properties / columns / items / properties / type / description

Added value: +"date columns parse ISO-ish strings on their own: \"2024\", \"2024-03\", \"2024-03-15\", \"2024-Q2\", full ISO timestamps, or epoch numbers. Anything else needs dateFormat."

addedInput schema / properties / data / properties / columns / minItems
```
Added value: +1
```

addedInput schema / properties / data / properties / rows / description

Added value: +"Row-major values, one array per row, order matching columns"

First observedSep 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true, but the description goes far beyond them: recursive object merge, wholesale array replacement, null-clears-key, ordering of config before configPatch, data replacing rows wholesale, expectedVersion/409 conflict handling, and the non-obvious fact that updates do not publish by default.

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?

Dense but every sentence carries operational content — merge behavior, removal path, concurrency, publish default. The first sentence is long and front-loads a specific parameter's semantics rather than the tool's purpose, which costs a point on front-loading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, nested-object mutation tool with no output schema, the description covers merge/replace semantics, concurrency, and publish behavior well. The inline preview image return is only mentioned in the title, and brand/title/showcase are untouched, leaving minor gaps.

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?

With 56% schema coverage across 9 params, the description meaningfully compensates: it explains configPatch vs config interaction and precedence, data semantics, publish, and the expectedVersion requirement. id, brand, and title get no explanation, but they are largely self-evident, so this is above baseline.

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 reads as an update tool with clear resource semantics (draft config, data rows, publish state) and specifies the two mutually exclusive update modes, configPatch vs config. It never states the base purpose in a single plain sentence — the title carries 'Update a draft' — but the specific verb/resource is unmistakable from the body.

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?

Explicit routing: use configPatch to send only changes, use config when you must remove keys, fetch current state via get_asset, and publish_asset separately if you don't pass publish:true. It also states the 409 recovery path (re-merge onto returned current), which is exactly the when-to-use guidance an agent needs.

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

All chartlink 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.

Update a draft (deep-merge patch, or replace the config) — returns an inline preview image

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources