Two tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error handling guidance. Both tools have descriptions (good baseline), but descriptions lack actionable context for LLM selection. Parameter descriptions are minimal. No documented output schemas, pagination support, or error recovery guidance. Tool names follow verb_noun pattern but lack specificity about what data is returned. Schemas use Zod with proper types, but descriptions do not explain constraints, dependencies, or expected formats.

• Document the output schema for both tools. Example: 'Returns an object with fields: pages (array of page objects), tables (array of table objects), key_value_pairs (object). Each page contains: page_number (int), text (string), tables (array of table IDs).' This enables LLMs to extract and chain results.
• Add constraint descriptions to parameters. For 'url': 'Must be a publicly accessible HTTPS URL pointing to a PDF, JPEG, PNG, or TIFF file (max 50 MB). Request times out after 120 seconds.' For 'formType': 'Determines which Azure prebuilt model is used. Use receipt for receipts, invoice for invoices, etc. Custom falls back to generic document analysis.'
• Add error recovery guidance in tool descriptions. Example: 'If the URL is unreachable, verify the link is public and the file format is supported. If analysis times out, try a smaller file or a different format. If the model fails, try a different formType or use analyze-document instead.'
• Clarify the distinction between tools. Example: 'Use analyze-document for general documents (reports, contracts, letters). Use extract-form-data when you know the document type (receipt, invoice, ID, business card), it returns more structured, field-specific data.'
• Add per-parameter type hints and ranges. Example: 'modelId (optional, string, 1-100 chars): Custom model ID from Azure. If omitted, defaults to prebuilt-document. Only use if you have trained a custom model.'