Both tools have minimal, generic descriptions (under 100 chars) that lack actionable context for LLM selection. Input schemas are present but extremely sparse: only a bare 'input' string parameter with no description, no constraints, no guidance on expected format or valid values. No output schema is documented. Parameter descriptions are completely absent. Tool names use generic verbs ('process') that do not clearly distinguish the two tools or convey what happens. No error handling guidance, no recovery paths, no idempotency markers. The 'pro_advanced_facturepro_process' name violates single-responsibility principle by embedding tier information. Overall, definitions fall well below production baseline (baseline avg description 194 chars, avg params 4 with descriptions; these have 1 param, no descriptions).

• Add detailed parameter descriptions for 'input' and 'options'. Specify expected format (e.g. 'XML invoice content as string', 'PDF file path', 'JSON object'), constraints (max length, required fields), and examples of valid input.
• Expand tool descriptions to 150 - 250 characters. Include: what the tool does, when to use it (vs the other variant), what it returns, and any prerequisites. E.g. 'Validates and converts electronic invoices (Peppol, Chorus Pro formats). Returns structured invoice data with compliance status. Use for basic validation; call pro_advanced_facturepro_process for Signal Loop optimization.'
• Document output schema explicitly. Define the structure of the response (e.g. {invoice_id, status, validation_errors[], compliance_score, converted_format}). This enables LLMs to chain tools and extract required fields.
• Rename 'pro_advanced_facturepro_process' to a verb_noun pattern without tier info. E.g. 'validate_invoice_with_signal_loop' or 'process_invoice_advanced'. Keep tier gating in the handler, not the name.
• Add error handling with recovery guidance. Return structured errors: {error_code, message, recovery_action}. E.g. 'Invalid XML format. Ensure input is valid Peppol XML. Call search_invoice_formats() to see supported formats.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry