Single tool 'extract_file' has a basic schema with two required string parameters (file_path, tika_url) and a generic 10-word description. Schema is present but lacks output documentation. No parameter descriptions beyond the names themselves. No error handling guidance, no idempotency hints, no pagination or result limits. Tool name is verb-based (extract_) which is good, but the implementation exposes a Tika server URL as a parameter, a security and usability anti-pattern. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Descriptions are minimal (10 chars for tool, 0 chars for params). Baseline for A+ tools requires 50-200 char descriptions and 100% param descriptions; this server has neither.

• Move tika_url to server-side configuration (environment variable or config file). Accept only file_path as a parameter. This prevents credential leakage and simplifies the agent interface.
• Add descriptions to both parameters: 'file_path: Absolute or relative path to the file to extract (e.g., /tmp/document.pdf or ./reports/Q4.xlsx).' and 'tika_url: (DEPRECATED, use server config) URL of the Tika server (e.g., http://localhost:9998).'
• Document the output schema in the tool description: 'Returns an object with fields: content (string, extracted text), metadata (object with keys like Author, Title, Content-Type), and status (string: success or error).'
• Add error handling with recovery hints: 'If file not found, verify the path exists and is readable. If Tika server unreachable, check that the server is running at the configured URL.'
• Add readOnlyHint annotation to the tool definition to signal to LLMs that this tool does not modify state and is safe to call multiple times.

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

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