n8n_get_node_execution_data

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

With readOnlyHint=true already covering the safety profile, the description adds meaningful behavioral context: it discloses that only a limited sample of output items is returned (not the full data set), and that the return shape varies by mode (status/item counts/errors vs output items/error details). This goes beyond the annotation and helps set agent expectations about data volume and content. No contradiction with annotations.

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?

Two sentences, no wasted words. The core purpose is front-loaded in the first sentence, and the conditional behavior is packed efficiently into the second. Every clause earns its place.

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 3-parameter tool with one behavioral fork, this is complete: the dual-mode behavior is fully explained, the result content of each mode is described, and the schema already covers required parameters, defaults, and bounds. No output schema exists, but the description preemptively describes what each mode returns, so an agent can invoke it correctly without further digging.

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%, so the baseline is 3. The description adds value on top by tying parameters to actual outcomes: it explains that omitting nodeName yields an overview of all nodes while providing it yields output items and error details, and reinforces itemsLimit's role via 'limited sample'. This behavioral linkage is genuinely useful beyond the schema's per-field descriptions.

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?

Opens with a specific verb+resource ('Inspect the data that flowed through a specific node in an execution') and immediately differentiates itself from the whole-execution alternative ('without downloading the whole execution'). The dual-mode behavior (overview vs node-specific details) is crisply stated, so an agent knows exactly what the tool does and how it differs from siblings like n8n_get_execution.

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 'without downloading the whole execution' phrase is an implicit exclusion that routes agents to this tool for cheap, targeted inspection rather than fetching an entire execution (e.g., via n8n_get_execution). It also gives clear within-tool mode guidance: omit nodeName for an overview, provide it for detailed output items. It stops short of naming sibling tools explicitly, so it doesn't earn a 5.

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