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

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

Annotations only provide openWorldHint=false, so the description carries the behavioral burden, and it does a strong job: it discloses immediate auto-republishing for published assets, draft behavior, staging via publish=false, the 2 MB asset limit, and the ~100 KB per-call recommendation. It stops short of describing return values or error behavior, but for the invocation logic this is solid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence carries operational value: core purpose, publish semantics, staging, size limits, chunking strategy, and the set_data_source alternative. The LIMITS section is clearly structured and the most important behavioral facts are front-loaded.

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

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

For a nested-parameter data-replacement tool with no output schema and minimal annotations, the description delivers the critical invocation guidance: acceptable data size, chunking, publishing side effects, and when to delegate to set_data_source. It could be more complete by mentioning what a successful call returns or whether replacement is destructive to existing rows, but the main calling decisions are well covered.

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

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

Schema coverage is about 60%, and the description adds important parameter meaning beyond the schema: publish defaults to 'auto,' what auto/true/false do in published vs draft context, and mode='append' as the chunking path. The schema already explains columns/rows/dateFormat well, so the description appropriately targets the under-documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The title clearly states 'Replace data rows' and the description positions this as 'THE core flow for refreshing numbers,' so the core action is identifiable. It also distinguishes itself from set_data_source by referring to that tool for URL-based data. However, the description's main clause is a bit informal and leans on the title rather than fully stating 'replaces the asset's inline data table.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly defines when to use this tool versus alternatives: use it for inline data replacement, chunk large datasets with mode='append' and deferred publish, and use set_data_source when the server should fetch a URL up to 2 MB. It also explains the draft-vs-published publish behavior, giving clear decision rules.

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