Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. list_user_tools has an optional query parameter with minimal description. fetch_user_tool accepts only a required id with no format guidance. Neither tool documents its output structure, forcing LLMs to infer response shape. Descriptions are present but generic (10 - 20 words each). No error handling guidance, no pagination support despite list_user_tools returning potentially large result sets, and no indication of which fields are safe to chain to downstream tools. Hardcoded sample data limits real-world applicability.

• Add explicit output schema documentation: 'Returns {tools: [{id, slug, summary, auth_type}]}' for list_user_tools and '{source_url, source_type, spec, docs_url, auth_block, user_context}' for fetch_user_tool.
• Enhance parameter descriptions with format constraints: query → 'Filter by tool slug or summary (case-insensitive substring match)'; id → 'Tool ID (alphanumeric, 6 chars, e.g. a1b2c3)'.
• Add pagination to list_user_tools: accept limit (1 - 100, default 20) and offset parameters; return {tools: [...], total: N, has_more: bool}.
• Improve error messages with recovery hints: 'Tool id=xyz not found. Call list_user_tools to see available IDs, or search by slug/summary.'
• Expand tool descriptions to 100 - 150 chars explaining use case: 'List all registered tools or filter by name/summary. Call this first to discover available integrations, then fetch_user_tool for full spec and auth details.'