converse-mcp provides a framework for building MCP servers with tool, prompt, and resource support. However, definition quality is significantly compromised by incomplete schemas, missing input parameter documentation, and vague descriptions. The 7 tools exhibit inconsistent quality: native MCP protocol tools (initialize, prompts/list, prompts/get, resources/list, resources/read, tools/list) appear to be framework intrinsics with minimal real documentation visible in source. The 'tools/call' tool accepts generic object arguments with no parameter validation schema. Helper builders exist in pkg/api/tools.go showing infrastructure for schema construction, but actual tool registrations in tests show empty or minimal configurations. No evidence of parameter descriptions, enums, or output schema documentation in the actual tool definitions observed.

• Add full input schemas to ALL tools. For 'prompts/get', add properties: name (string, required, 'The prompt identifier. Must match a registered prompt name.'). For 'resources/read', add uri (string, required, 'URI of the resource to read (e.g., file://path/to/resource or https://example.com/resource).'). For 'tools/call', define properties for tool name and arguments with nested schema showing valid keys.
• Expand tool descriptions to 80-150 characters with WHEN/WHY context. E.g., 'prompts/get': 'Retrieve a specific prompt by name. Use this after calling prompts/list to find available prompts, or directly if you know the prompt name. Returns prompt text and variables.' vs current 'Get a specific prompt by name'.
• Document output schemas for all tools. Create ResponseSchema types showing: prompts/get returns {name: string, description?: string, arguments?: {type: string, properties: {}, required: []}}, resources/read returns {uri: string, mimeType?: string, text?: string}, tools/call returns {content: [{type: string, text?: string, ...}], isError?: boolean}.
• Add parameter validation and error guidance. For 'prompts/get' and 'resources/read', document: 'If not found, returns error with available options.' For 'tools/call', validate that 'name' matches registered tools and provide error like: 'Tool "xyz" not found. Available: [list]. Call tools/list to discover.'
• Create dedicated tool wrappers with full schema. Instead of generic tools/call, consider: create_tool_call(name: string, arguments: object) → result. Or split by domain: call_custom_tool(name, args). Make the interface explicit, not generic.

Inferred effective spec: 2025-06-18+.

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