mcptool.sh is a bash-based MCP server management utility with significant definition quality gaps. While 25 tools are listed, most lack comprehensive schema definitions, parameter type information, and detailed descriptions. The server appears designed as a CLI wrapper for managing other MCP servers rather than exposing rich tool definitions. Of the 25 tools: (1) Naming is generally adequate (verb-noun pattern mostly followed), with names like 'run', 'list', 'add', 'info' being clear. (2) Descriptions exist for all tools but are brief (10-50 chars typically) and lack LLM-optimized detail about when to use each tool, what prerequisites exist, or what downstream operations become possible. Example: 'List all available MCP servers and groups from configuration' (60 chars) doesn't explain why an agent would call this vs. directly running a server. (3) Schemas are visible for tools 2-8, 13-17, and 20-25, but many lack detailed parameter descriptions beyond one sentence. Tools 1, 9, 10, 11, 12, 18, 19 show no visible input schemas in the source. (4) Output schemas are not documented for any tool, agents cannot know what fields to expect after calling 'run', 'list', or 'json'. (5) Error handling is absent; no tool describes retryability, failure modes, or recovery guidance. The 'add' tool family (tools 5-8) handles configuration writes but lacks confirmation patterns or dry-run options despite modifying user config files.

• Document output schemas for all tools. Example: 'list' should return {servers: [{name: string, status: string, ...}], groups: [{name: string, servers: string[], ...}], total_count: number}. This enables agents to chain tools and parse responses correctly.
• Expand tool descriptions to 100-200 characters, answering: What does it do? When should an agent call it vs. similar tools? What are the prerequisites? Example for 'add': 'Register an MCP server with Claude, Cursor, or a custom JSON config. Use this after 'setup' to configure credentials. Supports project and user scopes, user scope is global, project is local to the repository.'
• Add confirmation patterns to all write tools. Example: add_to_claude should support a 'dry_run' parameter that returns the changes without applying them, allowing agents to preview before committing.
• Consolidate 'add', 'add_to_claude', 'add_to_cursor' into a single parameterized 'add_server' tool with a 'target' enum (claude | cursor | custom_json) to eliminate tool-selection ambiguity.
• Add pagination parameters (limit: 1-100, offset: 0-unlimited) to list-returning tools. Document the default limit (e.g., limit=20) in the description.
• Provide error handling guidance in all write-tool descriptions. Example: 'If the server is already registered, returns conflict. Retry with overwrite=true or adjust the server name.' For interactive tools, document that they require a TTY (and will fail in headless agents).
• Add per-parameter descriptions explaining the impact of enum choices. Example for 'scope': 'project = register in .mcp.json (local to repository); user = register in ~/.mcp.json (global, applies to all projects).'