All 7 tools share identical, severely deficient schemas and descriptions. Each tool accepts only a single 'input' parameter (type: string, description: 'Input data (JSON)') with no structured schema, no parameter validation, and no guidance on expected JSON structure. Descriptions are minimal (8-34 chars) and fail to explain WHAT the tool does, WHEN to use it, or what it returns. No output schemas documented. No error handling guidance. Tools are thin pass-through wrappers to an external Bankr API with no input validation, sanitization, or recovery guidance. This violates 15+ core patterns from arcade.dev.

• Replace the generic 'input' parameter with explicit, typed parameters. E.g., logistics_estimate should accept: origin (enum: ['China']), destination (enum: ['Kazakhstan', ...]), transport_mode (enum: ['auto', 'rail', 'sea']), weight_kg (number, min: 1, max: 50000), etc. Each parameter must have a description explaining its purpose and constraints.
• Expand tool descriptions to 80-150 characters. Example: 'Calculate shipping cost from China to Kazakhstan by auto, rail, or sea. Requires origin, destination, transport mode, and weight. Returns cost in USD and KZT with delivery time estimates.' This tells LLMs WHAT, WHEN, and WHAT to expect.
• Document output schemas for each tool. E.g., logistics_estimate returns: {cost_usd: number, cost_kzt: number, delivery_days: number, transport_mode: string, carrier: string}. Include field descriptions so agents know what to extract.
• Add input validation and structured error responses. Validate enum values, numeric ranges, and required fields. Return errors like: '{status: "error", code: "invalid_transport_mode", message: "transport_mode must be one of: auto, rail, sea", retryable: true}' so LLMs can self-correct.
• Consolidate incoterms_check and incoterms_v2 into a single 'get_incoterms_guide' tool with an optional 'include_country_recommendations' boolean parameter. This reduces LLM confusion and simplifies the tool surface.