This server has only 2 tools, both with minimal definitions. start_homedata_signup has a parameter (email) with no description (null), violating the requirement that every parameter must have a description. check_homedata_api_key has no parameters at all. Both tool descriptions are extremely brief (under 50 chars) and lack actionable context for LLM selection. The server dynamically builds tools from a manifest (homedata_mcp/manifest/tools.json), but the source code provided does not show the actual tool definitions, schemas, or descriptions for the data tools, only the signup helpers are visible. This makes it impossible to verify schema quality, parameter descriptions, or output documentation for the main catalog.

• Add a non-empty description to the 'email' parameter in start_homedata_signup. Example: 'Your email address (required to create a Homedata account and receive an API key).'
• Expand tool descriptions to 50 - 200 characters, explaining WHAT the tool does, WHEN to use it, and any prerequisites. Example for start_homedata_signup: 'Initiate Homedata API key signup. Call this first if you don't have an API key yet. Returns signup instructions and a link to complete registration.'
• Document the output schema for each tool. Specify what fields are returned, their types, and which fields are needed for chaining to other tools (e.g., if check_homedata_api_key returns a status, document it).
• Add error handling guidance in tool descriptions. Example: 'If the API key is invalid, call start_homedata_signup to request a new one.'
• Expose the manifest-based tool definitions in the source code or documentation so schemas, parameter descriptions, and output structures can be verified against the rubric.