Botverse defines 8 tools with basic schemas and descriptions. All tools have names starting with action verbs (get_, convert_, transcode_, transcribe_, conform_) and descriptions present. However, descriptions are terse (10-50 chars), parameter descriptions lack detail about constraints/formats, and output schemas are completely undocumented. No error handling guidance, no parameter validation rules, and no indication of idempotency or side effects. Tools like convert_content and transcode_video accept 'options' as untyped objects with no schema. The server proxies calls to a hosted endpoint, so actual validation happens server-side, but the MCP interface itself lacks the rigor expected for production agent tooling.

• Document output schemas for all tools. Specify what fields are returned (e.g., get_upload_url returns {url: string, expires_at: string}), their types, and structure. This enables LLMs to plan downstream calls.
• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'Convert document content to another format. Use this when you have text content in memory; use convert_file for S3-uploaded files. Returns {job_id, status, download_url}.'
• Replace untyped 'options' objects with explicit, typed parameters or document the valid keys as an enum/schema. For transcode_video, document that options can include {method, target_framerate, ...} with types and constraints.
• Add error handling guidance. Document common errors (e.g., 'Invalid output_format: must be one of pdf, docx, html, xlsx, txt') and recovery steps. Use pattern:recovery-guide to guide LLM behavior on failure.
• Declare idempotency and side effects. Mark tools that modify state (convert_*, transcode_*, transcribe_*, conform_*) with destructiveHint or idempotentHint annotations. Document whether retrying with the same job_id is safe.