원활한 HubSpot CRM 통합을 위한 강력한 MCP(Model Context Protocol) 서버 구현으로, AI 어시스턴트가 HubSpot 데이터와 상호 작용할 수 있습니다.
이 MCP 서버는 HubSpot CRM API와 상호 작용하기 위한 포괄적인 도구 세트를 제공하여 AI 도우미가 다음을 수행할 수 있도록 합니다.
HubSpot CRM에서 연락처와 회사를 만들고 관리하세요.
자세한 회사 활동 내역 및 참여 일정을 검색합니다.
HubSpot 인스턴스 전체에서 최근 참여 데이터에 액세스하세요.
최근 활동한 회사 및 연락처 목록을 받으세요
AI 어시스턴트 인터페이스를 벗어나지 않고도 CRM 작업을 수행하세요
Related MCP server: HubSpot MCP Server
원활한 AI 통합 : AI 어시스턴트를 HubSpot CRM 데이터에 직접 연결
간소화된 CRM 작업 : 자연어 명령을 통해 일반적인 HubSpot 작업 수행
실시간 데이터 액세스 : HubSpot 인스턴스에서 최신 정보를 얻으세요
보안 인증 : HubSpot의 보안 API 토큰 인증을 사용합니다.
확장 가능한 디자인 : 필요에 따라 더 많은 HubSpot API 기능을 쉽게 추가할 수 있습니다.
지엑스피1
서버에는 HubSpot API 액세스 토큰이 필요합니다. 다음 방법으로 토큰을 얻을 수 있습니다.
HubSpot 개발자 계정 으로 이동
필요한 범위(연락처, 회사, 참여)를 갖춘 개인 앱 만들기
생성된 액세스 토큰 복사
토큰은 두 가지 방법으로 제공할 수 있습니다.
환경 변수로서:
HUBSPOT_ACCESS_TOKEN=your-access-token명령줄 인수로:
npm start -- --access-token=your-access-token개발을 위해 프로젝트 루트에 .env 파일을 만들어 환경 변수를 저장합니다.
HUBSPOT_ACCESS_TOKEN=your-access-token# Start the server
npm start
# Or with a specific access token
npm start -- --access-token=your-access-token
# Run the SSE server with authentication
npx mcp-proxy-auth node dist/index.jsSSE 서버는 인증을 위해 mcp-proxy-auth 패키지를 사용합니다. 인증을 구현하려면 다음을 수행하세요.
패키지를 설치하세요:
npm install mcp-proxy-authAUTH_SERVER_URL 환경 변수를 API 키 확인 엔드포인트를 가리키도록 설정합니다.
export AUTH_SERVER_URL=https://your-auth-server.com/verify인증을 사용하여 SSE 서버를 실행합니다.
npx mcp-proxy-auth node dist/index.jsSSE URL은 다음에서 확인할 수 있습니다.
localhost:8080/sse?apiKey=apikey인증을 위해 apikey 실제 API 키로 바꾸세요.
mcp-proxy-auth 패키지는 다음과 같은 프록시 역할을 합니다.
SSE 서버에 대한 요청을 가로채기
인증 서버에 대해 API 키를 확인합니다.
인증된 요청만 SSE 엔드포인트에 도달하도록 허용합니다.
이 MCP 서버는 모델 컨텍스트 프로토콜(MCP)을 지원하는 AI 어시스턴트와 함께 작동하도록 설계되었습니다. 서버가 실행되면 호환되는 AI 어시스턴트가 HubSpot CRM 데이터와 상호 작용하는 데 사용할 수 있는 도구 세트가 제공됩니다.
이 서버는 다음과 같은 강력한 HubSpot 통합 도구를 제공합니다.
허브스팟_연락처_생성
중복 검사를 통해 HubSpot에서 새 연락처 만들기
매개변수:
firstname (문자열, 필수): 연락처의 이름
lastname (문자열, 필수): 연락처의 성
email (문자열, 선택 사항): 연락처의 이메일 주소
properties (객체, 선택 사항): 회사, 전화번호 등과 같은 추가 연락처 속성
예:
{
"firstname": "John",
"lastname": "Doe",
"email": "john.doe@example.com",
"properties": {
"company": "Acme Inc",
"phone": "555-123-4567",
"jobtitle": "Software Engineer"
}
}허브스팟_회사_만들기
HubSpot에서 중복 검사를 통해 새 회사를 만듭니다.
매개변수:
name (문자열, 필수): 회사 이름
properties (객체, 선택 사항): 추가 회사 속성
예:
{
"name": "Acme Corporation",
"properties": {
"domain": "acme.com",
"industry": "Technology",
"phone": "555-987-6543",
"city": "San Francisco",
"state": "CA"
}
}허브스팟_회사_활동_받기
특정 회사의 포괄적인 활동 내역을 확인하세요
매개변수:
company_id (문자열, 필수): HubSpot 회사 ID
이메일, 통화, 회의, 메모, 작업을 포함한 자세한 참여 데이터를 반환합니다.
허브스팟_최근_참여_가져오기
모든 연락처와 회사의 최근 참여 활동을 확인하세요.
매개변수:
days (숫자, 선택 사항, 기본값: 7): 되돌아볼 일 수
limit (숫자, 선택 사항, 기본값: 50): 반환할 최대 참여 수
최근 CRM 활동의 모든 연대순 목록을 반환합니다.
허브스팟_활성_회사_만들기
HubSpot에서 가장 최근에 활동한 회사를 받으세요
매개변수:
limit (숫자, 선택, 기본값: 10): 반환할 최대 회사 수
마지막 수정 날짜별로 정렬된 반품 회사
허브스팟_활성_연락처_받기
HubSpot에서 가장 최근에 활성화된 연락처 가져오기
매개변수:
limit (숫자, 선택 사항, 기본값: 10): 반환할 최대 연락처 수
마지막 수정 날짜별로 정렬된 연락처를 반환합니다.
이 서버는 쉽게 확장할 수 있도록 설계되었습니다. 새로운 HubSpot API 기능을 추가하려면 다음을 수행하세요.
src/hubspot-client.ts 의 HubSpotClient 클래스에 새로운 메서드를 추가합니다.
src/index.ts 의 setupToolHandlers 메서드에 새 도구를 등록합니다.
npm run build 로 프로젝트를 다시 빌드하세요.
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
HubSpot, CRM, 모델 컨텍스트 프로토콜, MCP, AI 어시스턴트, TypeScript, API 통합, HubSpot API, CRM 통합, 연락처 관리, 회사 관리, 참여 추적, AI 도구
Create a new company in HubSpot
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Company name | |
| properties | No | Additional company properties |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a company but lacks critical details: it doesn't specify required permissions, whether the operation is idempotent, potential side effects (e.g., triggering workflows), or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success (e.g., returns a company ID) or failure, nor does it cover behavioral aspects like authentication needs or rate limits, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (name and properties). The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new company in HubSpot'), making the purpose immediately understandable. It distinguishes from siblings like hubspot_update_company (update vs. create) and hubspot_get_active_companies (get vs. create), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when not to use it, or compare it to siblings like hubspot_update_company for existing companies, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new contact in HubSpot
| Name | Required | Description | Default |
|---|---|---|---|
| firstname | Yes | Contact's first name | |
| lastname | Yes | Contact's last name | |
| No | Contact's email address | ||
| properties | No | Additional contact properties |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a contact, implying a write operation, but doesn't cover critical aspects like required permissions, whether the operation is idempotent, error handling for duplicate emails, or what the response looks like (e.g., success/failure, contact ID). This leaves significant gaps for an agent to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning a top score for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a write operation with no annotations and no output schema, the description is insufficient. It doesn't explain the behavioral traits (e.g., mutation effects, error cases) or what to expect upon success, leaving the agent without key context needed for reliable tool invocation in a HubSpot environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all four parameters (firstname, lastname, email, properties) with their types and purposes. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for adequate coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new contact in HubSpot'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'hubspot_update_contact' beyond the creation vs. update distinction, which is implicit but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'hubspot_update_contact' for existing contacts or 'hubspot_get_active_contacts' for retrieval. It also doesn't mention prerequisites, such as needing HubSpot access or when creation is appropriate versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get most recently active companies from HubSpot
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of companies to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'most recently active' but doesn't specify what 'active' means, how recency is determined, or any limitations like rate limits, permissions required, or pagination behavior. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'active' entails, how results are ordered, or what data is returned, which are critical for a tool that fetches data. This leaves the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'limit' parameter well-documented. The description doesn't add any additional meaning beyond the schema, such as explaining the 'active' criteria or default behavior, so it meets the baseline of 3 without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('most recently active companies from HubSpot'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'hubspot_get_company_activity' or 'hubspot_get_active_contacts', which would require more specificity to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'hubspot_get_company_activity' and 'hubspot_get_active_contacts', the description lacks context on selection criteria, such as whether this tool is for recent activity versus detailed activity tracking or contacts versus companies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get most recently active contacts from HubSpot
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of contacts to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions retrieving 'most recently active contacts' but doesn't explain what 'active' means, how recency is determined, whether this is a read-only operation, what permissions are required, or how results are formatted. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple retrieval tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes 'active' contacts, how results are sorted, what fields are returned, or any limitations. Given the lack of structured metadata, the description should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'limit' parameter clearly documented. The description doesn't add any parameter-specific information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('most recently active contacts from HubSpot'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'hubspot_get_company_activity' or 'hubspot_get_recent_engagements', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for retrieving HubSpot data, but no indication of when this specific 'active contacts' tool is appropriate versus other contact or activity-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get activity history for a specific company
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | Yes | HubSpot company ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It states 'Get activity history', which implies a read-only operation, but does not disclose any behavioral traits such as whether it returns a list or single object, whether it supports filtering, or if any side effects occur. More detail is needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the key information. Could be slightly expanded to include more detail while remaining concise, hence 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description provides the core purpose and required parameter. However, it lacks information about the return format, potential pagination, or examples of activity types. It is adequate but leaves some questions unanswered for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'company_id' having a description. The tool description does not add additional semantic value beyond the schema, but the schema itself is sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'activity history' for a specific company. It distinguishes from sibling tools like hubspot_get_company (which likely returns company details) and hubspot_get_active_companies (list of companies). However, it could specify the type of activity for even greater clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as hubspot_get_company or hubspot_get_recent_conversations. The description lacks context on prerequisites, such as needing a valid company_id, or when to prefer this over other activity-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent engagement activities across all contacts and companies
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to look back (default: 7) | |
| limit | No | Maximum number of engagements to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] recent engagement activities', which implies a read-only operation, but it doesn't disclose any behavioral traits such as authentication requirements, rate limits, pagination, or what constitutes an 'engagement activity'. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple tool and earns its place by clearly stating what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no output schema, the description is incomplete. It doesn't explain what 'engagement activities' entail, the format of the return data, or any error conditions. For a tool that retrieves data across multiple entities, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters (days and limit), including defaults. The description doesn't add any parameter semantics beyond what the schema provides, such as explaining what 'engagements' include or how the lookback period works. This meets the baseline of 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'recent engagement activities across all contacts and companies', making the purpose specific and understandable. It distinguishes this tool from siblings like hubspot_get_company_activity by specifying 'across all contacts and companies' rather than focusing on a single entity, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent engagement activities, but it doesn't provide explicit guidance on when to use this tool versus alternatives like hubspot_get_company_activity or hubspot_get_active_contacts. No exclusions or prerequisites are mentioned, leaving the agent to infer context based on the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing company in HubSpot (ignores if company does not exist)
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | Yes | HubSpot company ID to update | |
| properties | Yes | Company properties to update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals one important behavioral trait ('ignores if company does not exist'), which is valuable context not in the schema. However, it doesn't disclose other critical behaviors: whether this is a partial or full update, what permissions are required, whether changes are reversible, rate limits, or what happens when properties are invalid. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that communicates the core purpose and one key behavioral constraint. Every word earns its place with no redundancy or fluff. The structure is front-loaded with the primary action and includes the important qualifier at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description provides minimal but essential context about the update operation and its behavior with non-existent companies. However, it doesn't address what the tool returns, error conditions, authentication requirements, or how property updates interact with existing data. For a tool that modifies business data, this leaves important gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain property format expectations, validation rules, or provide examples. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing company in HubSpot'), making the purpose immediately understandable. It distinguishes from 'hubspot_create_company' by specifying it updates existing records rather than creating new ones. However, it doesn't explicitly differentiate from 'hubspot_update_contact' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating it 'ignores if company does not exist', which implies it should only be used when you know the company exists or want a no-op behavior for missing companies. However, it doesn't explicitly guide when to use this versus alternatives like 'hubspot_create_company' or provide any prerequisites about required permissions or data formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing contact in HubSpot (ignores if contact does not exist)
| Name | Required | Description | Default |
|---|---|---|---|
| contact_id | Yes | HubSpot contact ID to update | |
| properties | Yes | Contact properties to update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by stating 'ignores if contact does not exist', which clarifies idempotent behavior. However, it lacks details on permissions, rate limits, response format, or whether updates are partial/complete, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core purpose and includes a key behavioral note. There is no wasted text, and it effectively communicates essential information in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is moderately complete. It covers the basic purpose and one behavioral trait but lacks details on permissions, error responses, or update semantics. For a 2-parameter tool with high schema coverage, it's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('contact_id' and 'properties') adequately. The description doesn't add any additional meaning or examples beyond what the schema provides, such as property format or validation rules. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing contact in HubSpot'), making the purpose specific and understandable. It distinguishes from sibling tools like 'hubspot_create_contact' by focusing on updates rather than creation. However, it doesn't explicitly differentiate from 'hubspot_update_company', which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'ignores if contact does not exist', which suggests it's for updating existing contacts only. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'hubspot_create_contact' or 'hubspot_update_company', nor does it mention prerequisites or error handling beyond the ignore behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
hubspot_create_companyhubspot_create_contacthubspot_get_active_companieshubspot_get_active_contactshubspot_get_company_activityhubspot_get_recent_engagementshubspot_update_companyhubspot_update_contactScored across 8 tools
Each tool has a clearly distinct purpose targeting specific resources (companies, contacts, engagements) and actions (create, get, update). The 'get' tools differentiate by scope (active vs. specific activity vs. recent engagements), eliminating ambiguity. No tools appear to do the same thing, making misselection unlikely.
All tools follow a consistent 'hubspot_verb_noun' pattern with snake_case throughout. The verbs (create, get, update) are used predictably across resources, and the naming structure is uniform, making the set highly readable and predictable for agents.
With 8 tools, this server is well-scoped for HubSpot CRM operations, covering core entities (companies, contacts, engagements) with essential CRUD actions. Each tool earns its place without bloat, providing a focused yet functional surface for typical agent workflows.
The toolset offers strong coverage for companies and contacts with create, get (active/specific), and update operations, plus engagement retrieval. Minor gaps include no delete operations and limited get options (e.g., no general get_company or get_contact by ID), but agents can work around these with the provided tools.
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
MCP server for the HubSpot Integrations Center HubDB: search and retrieve integration data.
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
