Input schemas are present but parameters have null descriptions. Tool names are verb-based (search-, call-) but lack context. The 'call-provider' tool accepts an open-ended object (additionalProperties: true) with no validation or guidance. No output schema is documented. Error handling returns generic JSON strings without actionable recovery guidance. This server fails basic definition quality standards.

• Add a 50-200 character description to each tool explaining WHAT it does, WHEN to use it, and what it returns. E.g., 'search-registry: Search the Hyperware provider registry by name or keyword. Returns matching provider metadata including ID, name, and capabilities.'
• Add descriptions to all parameters. E.g., 'query: Search term to find providers in the registry (string, 1-256 chars)' and 'providerId: Unique identifier of the provider to invoke (string, required)'.
• Replace additionalProperties: true with a documented schema for callArgs. Either enumerate expected fields with types, or document the expected structure in the parameter description.
• Document the output schema for both tools. Specify what fields are returned (e.g., 'Returns: {content: [{type: string, text: string}]}') and what data the LLM should extract.
• Enhance error responses with actionable guidance. Instead of '{"error": "Request Failed"}', return '{"error": "Connection failed to Hyperware server at <url>. Verify the server is running and accessible. Retry in 5 seconds."}'.