Loading ToolBench
A simple Hubspot MCP server providing tools for interacting with HubSpot API through an MCP server interface
16 tools present with reasonable naming conventions (all start with action verbs like 'get_', 'create_', 'update_'). However, descriptions are present but often generic and lack LLM-specific guidance. Input schemas are properly formatted with types and required fields, but output schemas are not documented in the visible code. Parameter descriptions exist but vary widely in quality, some are detailed (e.g., 'Maximum number of companies to return (default: 10)') while others are minimal. Error handling details are not visible in the tool definitions provided. The server accepts string/enum constraints appropriately (e.g., criteria enum in hubspot_get_tickets), but lacks guidance on chaining IDs for downstream tool calls. Overall, this is a functional baseline implementation that meets minimum quality standards but lacks production-grade LLM optimization and error recovery guidance.
Create a new company in HubSpot
Create a new contact in HubSpot
Create a new custom property
Get most recently active companies from HubSpot
Get most recently active contacts from HubSpot
Get a specific company by ID from HubSpot
Output schemas not documented in tool definitions. The visible code shows input schemas but returns are described only in descriptions ('Get most recently active companies', etc.) without formal output schema declarations. LLMs cannot reliably plan downstream tool calls without knowing which fields are returned (e.g., does get_company return company_id, is that the same as the company_id parameter expected by update_company?).
Missing error handling guidance in tool descriptions. No tool explains what to do if a company_id does not exist, if the API rate limit is hit, or if a required property is missing. Descriptions do not distinguish retryable errors (rate limit) from user-fixable errors (invalid ID) from fatal errors (auth failure). LLMs receive no recovery guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Get activity history for a specific company
Get a specific contact by ID from HubSpot
Get details of a specific property
Get recent conversation threads from HubSpot with their messages
Get conversation threads associated with a specific ticket
Get tickets from HubSpot based on configurable selection criteria
Search for similar data in stored HubSpot API responses
Update an existing company record in HubSpot
Update an existing contact record in HubSpot
Update a property definition
Minimal parameter descriptions on 'properties' fields. Tools like hubspot_create_company and hubspot_update_company accept a 'properties' object with no description of valid keys, format, or constraints. LLMs must guess what properties exist (company_name? name? displayname?). This forces agents to call hubspot_get_property first, adding latency and tokens.
Missing chaining IDs in response documentation. If hubspot_create_company returns a company object, the description should state 'Returns the created company with company_id, which can be passed to hubspot_update_company or hubspot_get_company_activity.' Without this, agents cannot reliably chain calls.
Vague search tool naming and description. 'hubspot_search_data' does not clearly convey that it searches stored HubSpot API responses via FAISS embeddings, not live HubSpot data. This will confuse agents into expecting real-time search when cached data may be stale. Should be renamed to 'hubspot_search_cached_data' or 'hubspot_search_embeddings' with clear description of caching behavior.
Parameter type ambiguity: 'properties' in hubspot_update_company is type 'object' with no description of what keys/values it accepts. Is it flat {key: value} or nested {category: {key: value}}? This invites malformed requests.