Server exposes 4 language detection/verification tools with basic schemas and descriptions. All tools have input schemas with type definitions and descriptions present. However, descriptions are repetitive (all include identical payment boilerplate), lack actionable guidance for LLM selection, and omit critical details like minimum text length enforcement or error recovery paths. Tool names lack clear verb-noun structure (detect_langue vs detect_language suggests inconsistent naming). No output schemas documented. Error handling returns raw challenge objects without recovery guidance. STDIO transport caps protocol readiness at 50, further limiting overall score.

• Refactor descriptions to remove payment boilerplate. Move it to server documentation or a single 'Getting Started' resource. Each tool description should focus on its unique purpose: 'Detect language from text (186 languages, ISO 639-3). Returns top 5 matches with confidence scores. Requires 10+ character input.' Keep to 100-150 chars.
• Document output schemas for all tools. Add a 'Returns' section to each tool definition showing the response structure, e.g., 'Returns: {languages: [{code: string, confidence: number}], ...}'. This enables LLMs to chain tools correctly.
• Enhance error handling with actionable recovery paths. When payment is required, return: 'Payment required (0.002 USDC). Call bundle_check() to purchase credits, or set X402_CREDIT_TOKEN env var. Then retry.' Include the specific tool name and next step.
• Standardize tool names to English verb_noun format: rename detect_langue → detect_language, verifier_langue → verify_language. Consistency across tool names reduces LLM confusion and improves discoverability.
• Add parameter validation and clear constraints. For credit_topup, validate montant is a valid decimal string and within [0.006, 1000]. Return 'Invalid amount: "abc", must be a decimal string between 0.006 and 1000 USDC' on failure, not a generic error.