This is an n8n node package wrapping MCP client functionality, not an MCP server itself. Tool definitions are present but lack depth. All 7 tools have basic descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization) and minimal parameter documentation. Input schemas exist but are sparse: executeTool has only 2 params with generic descriptions; others have 0-1 params. No output schemas documented. No error handling guidance, no parameter constraints (enums, ranges), no idempotency hints. Naming is verb-forward (get_, list_, read_, execute_) but descriptions don't explain WHEN to use each tool or what distinguishes them. For example, listResources vs listResourceTemplates are not differentiated in their descriptions.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it, and what it returns. Example: 'List all available MCP tools. Call this first to discover what tools are available before executing one. Returns tool names, descriptions, and input schemas.'
• Document output schemas for all tools. Specify what fields each tool returns (e.g., listTools returns [{name, description, inputSchema}]). This enables LLMs to plan multi-step workflows.
• Add parameter constraints to executeTool.toolParameters. Either provide a schema showing valid keys, or document the expected structure in the description (e.g., 'JSON object with keys matching the tool's input schema').
• Add error recovery hints to tool descriptions. E.g., 'If the tool is not found, call listTools() to see available tools.' This guides agents on self-correction.
• Differentiate listResources vs listResourceTemplates in descriptions. Explain when to use each (e.g., 'List available resource templates (blueprints) vs instantiated resources'). Add examples if possible.