Jeprum exposes 11 tools across multiple example files with basic schemas and descriptions. Most tools have minimal descriptions (10-50 chars, well below the 194-char baseline). Parameter descriptions are sparse or absent. No output schemas documented. Error handling is generic. Tools lack annotations (readOnlyHint, destructiveHint). Naming is reasonable (verb_noun pattern), but descriptions do not guide LLM selection or explain when to use each tool vs. similar ones. No evidence of pagination, result limits, or chaining IDs in responses. Security-sensitive tools (delete_file, send_email, write_file) lack permission gates or confirmation patterns.

• Expand all tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs. similar tools), and any prerequisites. E.g., 'Search the web for current information using a query string. Use this for real-time web results; use web_search for API-based searches with cost tracking. Returns mock results for demo.'
• Add descriptions to all parameters. For enums (target_lang), list valid values or reference a discovery tool. For paths, specify format (absolute/relative, allowed chars). For emails, clarify format ([email protected]).
• Document output schemas for all tools. Show what fields are returned, their types, and which are safe to chain to downstream tools. E.g., read_file returns {content: string, path: string, size_bytes: int}.
• Add tool annotations: mark read-only tools with readOnlyHint=true; mark delete_file, send_email, write_file with destructiveHint=true. Mark idempotent tools (get_time, read_file) with idempotentHint=true.
• Implement confirmation pattern for delete_file and send_email: add a 'confirm' parameter (default false) or return a confirmation_token that must be passed in a follow-up call. Log all destructive operations with user/timestamp for audit.