n8n_explore_node_resources

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful behavioral context beyond this by noting that it uses an instance credential, that it requires N8N_MCP_ACCESS_TOKEN, and that it calls live resource resolution rather than returning static definitions. 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?

The description is two dense, purposeful sentences. It front-loads the core action and examples, then immediately gives prerequisite lookup instructions. There is no filler or redundant repetition of the schema.

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?

Given the tool's complexity (10 parameters, no output schema), the description is quite complete: it names the credential requirement, the two resolution modes, and the source tools for required parameters. It could go slightly further by describing the response shape (label/value items) and pagination behavior, but the schema covers paginationToken and the purpose is unambiguous.

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 description coverage is around 90%, so the schema carries most paramater meanings. The description adds value by explaining where to find methodName/methodType and credentialId, and by connecting currentNodeParameters to loadOptionsDependsOn with an example. This goes beyond the raw schema.

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?

Description names a specific verb and resource: 'Resolve the real options behind a node's dynamic dropdown (loadOptions) or resource-locator search (listSearch)'. It distinguishes itself from get_node by explaining that this tool resolves live options rather than returning the node definition, and gives concrete examples including Slack channels and Google Sheets tabs.

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?

It clearly conveys when to use the tool (when workflow configs need real IDs behind dynamic dropdowns/listSearch) and tells the agent where to obtain prerequisites: methodName/methodType from get_node output and credentialId from n8n_manage_credentials list. However, it doesn't explicitly state when-not-to-use or compare against alternative tools beyond these references.

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