refresh_data

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

Beyond annotations (which already indicate mutation), the description discloses error outcomes (not_refreshable, not_found) and the return envelope (same as connect_data). It implies network/API activity by 're-pull from origin' and clarifies the exact failure modes, adding significant behavioral context.

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 front-loaded with the core action and scoping, then details usage constraints and error cases in a compact, information-dense manner. No wasted words; every sentence contributes.

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 single-parameter tool with no output schema, the description covers purpose, usage prerequisites, error handling, and the expected return envelope. It tells the agent exactly how to check readiness (list_data refreshable flag) and what to expect, making it complete for correct invocation.

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 100% with the dataset_id parameter already described as 'Dataset ID from connect_data or list_data.' The description does not add further meaning to the parameter beyond that, so the baseline 3 applies.

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 description states a specific action (re-pull) on a saved dataset from its origin, with clear scope (only live-connection datasets). It distinguishes itself from siblings like connect_data (initial connection) and list_data (listing) by specifying the refresh action and the envelope reference.

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?

Explicitly tells when to use it: only for datasets created from a live connection, and instructs to check the refreshable flag in list_data first. It also warns of failure conditions (not_refreshable, not_found), guiding the agent on preconditions and error handling.

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