The pairing is the design decision worth noticing. Companies, contacts and leads get their own create, update, search and property tools because their filters and validated properties genuinely differ; everything else runs through crm_list_objects, crm_get_object and their siblings with an objectType argument, so a custom object is reachable without waiting for somebody to add a dedicated tool. Batch variants sit almost everywhere, which is what makes a migration or a bulk correction practical rather than theoretical. The cost is the count: 112 tool definitions is a lot of surface to carry into a session that wanted to look up one contact.
A HubSpot CRM server with a typed tool set for the objects whose properties differ, a generic objectType layer underneath it, and the association, engagement, communication-preference and product surfaces around both.
- Companies, contacts and leads each with create, update, get, object-specific search, batch create and batch update, plus reading and creating that object's property definitions
- A generic layer taking an objectType argument, so any CRM object is reachable: list, get, create, update, archive, search, and batch create, read, update and archive
- Associations: the available association types for a pair of object types, associations read between objects, and created or archived one at a time or in batches
- Engagements as first-class objects — meetings, notes, tasks, calls and emails — each with create, get, update, archive, list, search, and batch variants
- engagement_details, including a get_associated variant for pulling an engagement's related records
- Communication preferences read and updated, subscription definitions and status, and a contact subscribed or unsubscribed
- Products listed, read, created, updated, archived, searched and handled in batches
A HubSpot access token in HUBSPOT_ACCESS_TOKEN.
One command plus a key — npx -y @smithery/cli install @shinzo-labs/hubspot-mcp, then supply credentials