Server has 15 well-named tools with consistent verb_noun patterns (search_*, get_*, create_*, update_*, list_*). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas are present with type definitions and parameter descriptions. However, output schemas are NOT documented, responses are inferred from HubSpot API but never formally declared. Parameter descriptions lack constraints (e.g., limit 1-100 is enforced in code but not stated in schema descriptions). Error handling returns structured objects but lacks recovery guidance (no 'try search_contacts first' hints). No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Missing idempotency guidance for create/update tools.

• Document output schemas for all tools. E.g., search_contacts returns {results: [{id, firstname, lastname, email, ...}], total: int}. This enables LLMs to chain tools (search → get → update) without guessing field names.
• Add constraint descriptions to numeric parameters: 'limit: Max results (1-100, default 20)' and 'properties: Optional array of HubSpot property names (e.g., ["email", "phone", "company"])'.
• Add tool annotations via FastMCP: @mcp.tool(annotations={"readOnlyHint": true}) for search_*/get_*/list_* and @mcp.tool(annotations={"destructiveHint": true}) for create_*/update_* to signal safety and retry behavior.
• Enhance error messages with recovery hints. E.g., if get_contact fails with 404, return {error: true, message: 'Contact not found. Try search_contacts(query="...") to find the contact ID first.'}
• For create_* and update_* tools, document common properties in descriptions: 'Common properties: email, firstname, lastname, phone, company, lifecyclestage. See HubSpot docs for full list.' Consider adding a separate list_contact_properties() discovery tool.