Critical gaps across all dimensions. Tool names lack action verbs (pipe_pull_*, pipe_push_* are generic; 'pull' and 'push' don't convey intent). Descriptions are minimal (10-30 chars) and fail to explain WHEN to use each tool or what distinguishes similar ones. Parameter descriptions are completely absent, 'config' and 'params' are opaque objects with no guidance on structure, required fields, or valid values. No output schemas documented. No error handling guidance. The 19 tools are nearly identical in structure (pull_X_source, push_X_sink pattern), making them indistinguishable to an LLM. No validation, no examples, no recovery paths.

• Add detailed parameter descriptions for 'config' and 'params' objects. Document required fields, structure, and valid values. Example: 'config: {type: object, description: "Connector configuration with keys: api_key (string, required), base_url (string, optional, default: https://api.example.com), timeout_ms (integer, 1000-30000, default: 5000)"}'
• Expand tool descriptions to 100-200 characters. Explain WHAT the tool does, WHEN to use it, and what it returns. Example: 'Fetch data from Salesforce using configured credentials. Use this to retrieve records, contacts, or custom objects. Returns array of records with id, name, and metadata fields.'
• Document output schemas for all tools. Specify return type (object, array, string), field names, types, and meanings. Example: 'Returns: {type: array, items: {type: object, properties: {id: string, name: string, created_at: ISO8601 string}}}'
• Rename tools with clear action verbs. Replace 'pipe_pull_X_source' with 'fetch_from_X' or 'read_X_data'. Replace 'pipe_push_X_sink' with 'send_to_X' or 'write_to_X'. This helps LLMs understand intent from the name alone.
• Add error handling guidance to tool descriptions. Specify which errors are retryable (network timeout, rate limit) vs user-fixable (invalid credentials, missing required field) vs fatal (unsupported connector type). Provide recovery hints.