Skip to main content
Glama

chartlink

Replace data rows — published assets auto-republish (live embeds update)

replace_asset_data

THE core flow for refreshing numbers. publish defaults to auto: a published asset republishes immediately (every embed/PNG updates); a draft stays draft. Set publish=false to stage instead. LIMITS: an asset holds up to 2 MB of data, but keep each tool call under ~100 KB of rows — for larger datasets chunk with mode: "append" (publish: "false" on every chunk but the last), or skip inline entirely with set_data_source (the server fetches a URL, up to the full 2 MB).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
dataYes
modeNoappend adds rows after the existing ones (same columns required) — the chunking path
noteNoPublish note for the version history
publishNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With only openWorldHint=false in annotations, the description carries the full burden and delivers: it discloses that publish defaults to auto, that published assets republish immediately affecting every embed/PNG, that drafts stay draft, and it states size limits (2 MB asset cap, ~100 KB per call). These are critical behavioral traits not visible in the schema.

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?

The description is dense but tightly organized: core purpose first, then publish semantics, then limits and chunking alternative. Every sentence adds decision-relevant information; no filler.

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 nested params and no output schema, the description covers the operational context: size limits, chunking strategy, publish behavior, and an alternative tool for URL-based data. An agent has enough to invoke it correctly and avoid common failure modes.

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 only 40%, but the description compensates by explaining publish's default ('auto') and staging behavior, and by giving mode='append' its chunking purpose. It does not add semantic detail for note or id, but those are self-evident or already described in the schema, so the gap is acceptable.

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?

The title and description state a specific action ('replace data rows' / 'refreshing numbers') on a clear resource (asset data), and the description differentiates from set_data_source by naming it as the alternative for large datasets. The auto-republish behavior is front and center, so an agent knows exactly what the tool does.

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?

The description gives explicit guidance on when to use this tool ('THE core flow for refreshing numbers'), when to stage instead (publish=false), when to chunk (larger datasets with mode append), and when to choose set_data_source instead (skip inline entirely for datasets up to full 2 MB). This is strong routing guidance beyond the schema.

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.