All 5 tools suffer from severely underdeveloped schemas and descriptions. Each tool accepts a single generic 'input' parameter (type: string, description: 'Input data (JSON)') with no guidance on what JSON structure is expected. Descriptions are minimal (12-27 chars) and fail to explain WHAT the tool does, WHEN to use it, or what it returns. No output schemas are documented. Tools are wrappers around external Bankr API endpoints but provide no contract clarity for LLM reasoning. This server would require agents to guess at input formats and interpret raw JSON responses without structure.

• Replace generic 'input' parameter with explicit, typed parameters. E.g., b2b_lead_score should accept company_name (string), industry (enum), revenue_range (string), contact_email (string), not a JSON blob.
• Expand each tool description to 50 - 150 characters explaining: (1) what data it analyzes, (2) what it returns, (3) when to use it. Example: 'Scores B2B leads by company profile, industry, and contact info. Returns a 0 - 100 score and risk classification. Use before outreach to prioritize prospects.'
• Document output schemas. Specify what fields the Bankr API returns (e.g., score, risk_level, confidence, reasoning) and their types. Include example responses in comments.
• Add error handling with recovery guidance. Catch network timeouts, invalid JSON, and API errors. Return structured errors: {status: 'error', code: 'invalid_input', message: '...', suggestion: 'Try with a valid company name'}.
• Move WALLET and BASE URL to environment variables (process.env.BANKR_WALLET, process.env.BANKR_API_BASE). Never hardcode credentials or endpoints in source.