How do I use BackCrew HubSpot MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BackCrew HubSpot MCP Server show me all deals in the pipeline" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

BackCrew HubSpot MCP Server

by jayson-svg

Overview Schema Related Servers Score Discussions

TypeScript

Remote

BackCrew HubSpot MCP Server

Think of this like a brand-new employee on their first day, not a business partner. A new hire only does the exact tasks you've shown them, nothing more, until you decide they're ready for more responsibility.

It lets you connect an AI assistant like Claude or ChatGPT to your HubSpot account, so you can ask for things in plain English ("find this lead," "what deals are in the pipeline," "log this call as a note") instead of clicking through HubSpot yourself. On day one, it only knows how to look things up. You decide if and when to train it up to doing more.

HubSpot is a general sales/marketing CRM, not an FSM platform, but a lot of pest control businesses use it (or a tool like it) for lead intake and sales pipeline tracking alongside their actual field-service software. This repo is built to run alongside one of BackCrew's FSM servers in the same AI assistant.

Built by BackCrew, part of a series of free tools like this for pest control businesses.

Not a developer? That's fine. Everything up through "Testing it safely" is written for you, no coding background needed.

Related MCP server: HubSpot MCP Server

What this actually does

Let's be upfront about what this is, because it's easy to oversell: this is not an all-knowing sales assistant that understands your pipeline and handles things for you. It's a specific, listed set of actions that an AI assistant is allowed to trigger when you ask for them in plain English. The AI doesn't have judgment about your business; it matches what you ask for to the closest action on its list and does exactly that, nothing more.

Why use an independent MCP server instead of the platform's own AI?

Software platforms are increasingly shipping their own built-in AI features. Worth knowing why you might still reach for this instead:

No plan-tier gates. Native AI features are often locked to a platform's most expensive plan. This project just needs API access, which is usually available on lower tiers too.
Cross-platform, not walled off. A platform's own AI only sees that platform's own data; it has no reason to work fluently with your FSM software, your accounting software, or your email, since those are somebody else's product. An MCP-connected assistant can have multiple servers attached at once (this one plus one of BackCrew's FSM servers), so it can work across your whole stack in one conversation.
Your choice of AI, not theirs. You keep using whichever assistant you already trust (Claude, ChatGPT, whatever) instead of learning a new vendor-specific AI interface.

Scope: this is intentionally narrow

HubSpot's API covers a huge surface (marketing emails, workflows, forms, tickets, custom objects, and more). This repo covers exactly what's relevant to a pest control business managing leads and sales:

Contacts: the people (leads, prospects, customers)
Companies: the businesses those people belong to
Deals: sales opportunities and where they sit in your pipeline
Notes: logging a call, conversation, or other interaction on a record's timeline
Owners: read-only, needed to assign records to a team member
Associations: linking records together (a contact to a company, a note to a deal, etc.)

Not covered: marketing emails, workflows, forms, tickets, custom objects, and most of the rest of HubSpot's platform. See ROADMAP.md.

Also from BackCrew

This is one of several MCP connectors BackCrew builds, same idea, different software. We've also got FSM connectors like Housecall Pro, plus QuickBooks for the accounting side. Full list and what's live right now: see ROADMAP.md.

Beyond this repo: once a business gets comfortable with an AI assistant reading its data, there's often more it wants to do with it, like catching missed calls faster, processing invoices and paperwork automatically, following up on quotes without someone having to remember, reactivating customers who've gone quiet, or pulling reports without digging through the software. That's a separate, scoped conversation, not part of this free, open-source repo. Same contact as in Built by BackCrew below if it's something you want to explore.

Some words you'll see, explained

API: a locked door into HubSpot's data that only software can open. This project is a key that opens that door.
MCP: the standard way an AI assistant like Claude or ChatGPT is told what it's allowed to do.
Server: a small program that sits between Claude and HubSpot, translating requests back and forth.
Private App token: HubSpot's self-service equivalent of an API key. You generate it from your own HubSpot account settings, no separate developer account or OAuth flow needed for connecting to your own account.
Association: HubSpot's term for a link between two records, e.g. a contact belonging to a company, or a note attached to a deal. Records aren't automatically connected; you (or this server) have to explicitly associate them.
Terminal: a plain-text window where you type commands.
Tool: one specific, individually named action the AI is allowed to take.

How this keeps you safe by default

Out of the box, this server can only look things up. It ships in read-only mode.
When you're ready for more, you choose a responsibility level:
- readonly-owner: same as the default. Look-ups only.
- office-ops: create/update contacts, companies, deals, and notes, and associate records together. No deletes.
- admin: everything, including deletes.
A typo can't accidentally hand out more trust than you intended. An invalid profile falls back to the safest option.

What it can look up (always safe)

What it covers	Examples
Contacts	Search and view contact records
Companies	Search and view company records
Deals	View deals and pipeline/stage configuration
Notes	View logged notes
Owners	View which team members can be assigned records
Associations	View which records are linked together

11 look-up actions in total.

⚠️ What it can change (off by default)

office-ops level:

What it covers	Examples
Contacts, Companies, Deals	Create or update a record
Notes	Log a note and attach it to a record
Associations	Link or unlink two existing records

admin level only:

Deleting a contact, company, deal, or note (HubSpot moves deleted records to a recycling bin recoverable for 90 days from the HubSpot UI; not undoable via this API, so treat it as effectively permanent from this tool's perspective)

How to set it up

No context-switching here: do these three steps in order, and you won't need to jump back and forth.

You'll need a computer with Node.js installed before you start.

Step 1: Make a folder for this on your computer

Open Finder (Mac) or File Explorer (Windows), go to your Desktop or Documents, and create a new folder. Give it a name you'll recognize later, like backcrew-mcp-hubspot.

That's it for now. Just know where this folder is. Everything else gets put inside it.

Step 2: Get a HubSpot Private App token

Do this now, before touching the terminal:

Log into your HubSpot account
Go to Settings → Integrations → Private Apps → Create a private app
Under Scopes, grant read/write access to the objects you want this server to touch (Contacts, Companies, Deals, Notes/Engagements, Owners)
Copy the generated access token into a temporary note somewhere; you'll paste it in during Step 3

Step 3: Install it

With your folder made and your token in hand, this is one continuous run: don't skip ahead or double back.

Open a terminal. On a Mac, press Cmd+Space, type "Terminal," and hit enter. On Windows, click the Start menu, type "PowerShell," and hit enter. Use PowerShell rather than Command Prompt: a couple of the commands below, like pwd, only work in PowerShell.
Type cd (with a space after it), then drag your Step 1 folder from Finder/File Explorer straight into the terminal window; it'll paste the folder's path in automatically. Press enter.
Paste this exact command and press enter. It downloads the project directly into the folder you made (the trailing . matters, it means "put it here, not in a new folder"):
```
git clone https://github.com/jayson-svg/backcrew-mcp-hubspot.git .
```
Paste this and press enter. It installs the project's dependencies:
```
npm install
```
Paste this and press enter. It builds the project:
```
npm run build
```
Paste this and press enter. It prints the full folder path. Don't close this terminal window yet; you'll need this exact text in the next section.
```
pwd
```
Paste this and press enter. It creates your settings file from a template:
```
cp .env.example .env
```
Open that new .env file in a text editor. On a Mac, paste open -e .env into the terminal and press enter. On Windows, paste notepad .env and press enter.
Find the line that says HUBSPOT_ACCESS_TOKEN=. Paste in the token you copied in Step 2, right after the =, with no extra spaces or quotes.
Leave HS_MCP_MODE=read_only and HS_MCP_PROFILE=readonly-owner exactly as they are for now; that's the safe default. Save the file and close the editor.

Connecting it to Claude

This step comes last on purpose: it needs the exact folder location from Step 3, and now you have it.

Open Claude's settings file (for Claude Desktop, claude_desktop_config.json) and add:

{
  "mcpServers": {
    "hubspot": {
      "command": "node",
      "args": ["PASTE_YOUR_PWD_OUTPUT_HERE/dist/index.js"],
      "env": {
        "HUBSPOT_ACCESS_TOKEN": "your_token_here",
        "HS_MCP_MODE": "read_only",
        "HS_MCP_PROFILE": "readonly-owner"
      }
    }
  }
}

Replace PASTE_YOUR_PWD_OUTPUT_HERE with the exact text the pwd command printed back in Step 3 (keep the /dist/index.js part after it). If you're on Windows, swap any backslashes in that path for forward slashes (for example C:/Users/yourname/Desktop/... instead of C:\Users\yourname\Desktop\...), since the config file needs regular slashes.

Restart Claude. Also works with ChatGPT and other MCP-compatible AI tools. If you're also running one of BackCrew's FSM servers, add both to the same config.

Testing it safely

Start in read-only mode and stay there for a while.
When you turn on office-ops, test on a clearly fake contact first.
Never go straight to admin mode. Deletes aren't reliably undoable via the API.
Never share your Private App token: treat it like a password.
If something looks wrong, switch back to HS_MCP_MODE=read_only immediately.

For developers

Everything below this point assumes a coding background.

Tool reference

Run the server and call tools/list to see exact schemas: every tool's description includes the HubSpot API path it maps to and its access tier.

Why this repo uses a CRUD factory instead of hand-written tools per object

HubSpot's CRM v3 API is uniformly object-oriented: Contacts, Companies, Deals, and Notes (and every other CRM object) all share the same list/get/create/update/delete shape around a properties object and an optional associations array. Rather than hand-write near-identical code four times, this repo has one small factory, registerCrmObjectTools() in src/crud.ts, that generates the five tools for an object type from one config object (object type name, property fields, default tiers). Each generated tool is still a fully separate, individually named, individually gated MCP tool. Same rationale used elsewhere in this series for platforms with an equally uniform REST API.

Project layout

src/
  index.ts          Server entrypoint
  client.ts          Minimal fetch-based HubSpot API client (Bearer auth, error handling)
  toolkit.ts          Tier/profile-aware helper that wires a Zod input schema + handler into an MCP tool
  crud.ts             Factory that generates list/get/create/update/delete tools for uniform CRM objects
  tools/
    contacts.ts
    companies.ts
    deals.ts             (+ list_pipelines)
    notes.ts
    owners.ts              (read-only)
    associations.ts

The tier/profile system

Same pattern as the rest of this series: HS_MCP_MODE/HS_MCP_PROFILE gate what's registered at startup; read_only always wins; invalid profile falls back to the safest tier.

Notes on the HubSpot API

Base URL: https://api.hubapi.com
Auth header: Authorization: Bearer <private_app_token> (same header shape whether you're using a Private App token or an OAuth access token)
CRM objects use properties (the actual field data) and associations (links to other records) as the two top-level request keys
Pagination is cursor-based: pass after from a previous response's paging.next.after
Association type IDs are numeric and HubSpot-assigned for default types (e.g. contact-to-company) or custom-assigned for user-defined labels; look them up via HubSpot's associations API guide or GET /crm/v4/associations/{fromObjectType}/{toObjectType}/labels
Full reference: developers.hubspot.com

This server was built by reading HubSpot's public API documentation directly for Contacts, Companies, Deals, and Notes, with real field names and required-property rules taken from HubSpot's own docs.

This repo intentionally stops at honest API access. It does not include business-logic features; those live in BackCrew's managed offering, not in this public repo. See ROADMAP.md.

What's next

See ROADMAP.md for the rest of the planned series and the pattern this repo follows.

Built by BackCrew

This project is free and open for anyone to use, copy, or build on.

It's also a sample of the kind of work BackCrew does. If you want this expanded (tickets, workflows, custom properties) or connected alongside a specific FSM server for your business, that's exactly the kind of project we take on.

Want this done for you? Reach out: jayson@backcrew.co

No pressure either way, everything above works on its own, for free.

License

MIT

Available Tools

8 tools

get_companyC

Get a single a company record. At least one of name or domain is required on create — domain is recommended, since it's the primary de-duplication key. by ID. Maps to GET /crm/v3/objects/companies/{id}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`properties`	No	Defaults to: name, domain, phone, city, state, industry

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description mentions 'by ID' and endpoint tier but does not disclose auth needs, rate limits, or error handling. Insufficient for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short but contains extraneous information about create requirements (not relevant to get). Could be more focused on the get operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with 2 params, no output schema. Explains endpoint and tier, but omits return format and error conditions. Partially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only properties has a description). The description does not clarify id or properties beyond what schema already states, and includes irrelevant creation info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 'a single company record', and specifies the endpoint mapping. It distinguishes from siblings like list_companies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes irrelevant info about create requirements but no guidance on when to use this tool vs alternatives like list_companies or get_contact. No when-not or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_contactC

Get a single a contact (person) record. At least one of email, firstname, or lastname is required on create. by ID. Maps to GET /crm/v3/objects/contacts/{id}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`properties`	No	Defaults to: firstname, lastname, email, phone, company, hs_lead_status, lifecyclestage

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description only implies read-only via the HTTP mapping and a tier hint, but does not explicitly state non-destructiveness, auth needs, or other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, but the second sentence about create is irrelevant and wastes space. Could be more concise by removing that part.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, no annotations, incomplete parameter info. The description offers an HTTP mapping and tier hint but omits return format, error handling, and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 50% parameter description coverage (properties has defaults). The description adds no meaning beyond what the schema provides; it does not explain parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets a single contact record by ID. However, it includes an irrelevant sentence about create requirements, which may confuse.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like list_companies or get_company. No explicit when-not-to-use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_dealB

Get a single a deal (sales opportunity) record. dealname and dealstage are required on create; pipeline defaults to your account's default pipeline if omitted. by ID. Maps to GET /crm/v3/objects/deals/{id}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`properties`	No	Defaults to: dealname, dealstage, pipeline, amount, closedate, hubspot_owner_id

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry burden. It discloses endpoint (GET), read-only nature (tier: readonly-owner), and that it retrieves by ID. However, includes irrelevant create requirements which detract from transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is somewhat cluttered: first sentence is clear, but then includes irrelevant create info, a fragment 'by ID', endpoint mapping, and tier. Could be more concise and structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple read tool with 2 parameters. Mentions endpoint and auth tier, but lacks description of return value structure (no output schema). The irrelevant create info reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema documentation coverage is 50% (only 'properties' has description). Description adds little beyond 'by ID' and create constraints that are not relevant to this GET operation. Does not elaborate on the 'id' parameter or the default for 'properties'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Get a single deal (sales opportunity) record', which specifies the verb and resource. Distinguishes from sibling 'list_deals' by indicating single record retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage by ID, but no explicit guidance on when to use this tool vs alternatives. Includes irrelevant create constraints that could confuse. No exclusions or alternative tool names mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_noteA

Get a single a note logged on a CRM record's timeline (e.g. a contact, company, or deal). hs_timestamp is required on create — pass associations to attach it to a record, otherwise it won't show up anywhere useful. by ID. Maps to GET /crm/v3/objects/notes/{id}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`properties`	No	Defaults to: hs_note_body, hs_timestamp, hubspot_owner_id

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions the tier and endpoint, but lacks details on error handling, permissions, or what happens on missing note.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise but includes extraneous information about creation (hs_timestamp, associations) that is irrelevant for a get tool, making it slightly less focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description covers the core purpose and endpoint, but lacks details on return format and error scenarios, making it somewhat adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% with only properties described. The description adds that id is used to identify the note and mentions the default properties, but no further semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets a single note from a CRM record's timeline, specifying the resource and action. It also mentions the endpoint mapping and distinguishes from list_notes sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving a single note but includes irrelevant create details and doesn't provide clear when-to-use or when-not-to-use guidance or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_associationsA

List the records of one object type associated with a specific record. Maps to GET /crm/v4/objects/{fromObjectType}/{fromObjectId}/associations/{toObjectType}. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`fromObjectId`	Yes
`toObjectType`	Yes	e.g. contacts, companies, deals, notes
`fromObjectType`	Yes	e.g. contacts, companies, deals, notes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It includes the endpoint mapping and a tier hint ('readonly-owner'), indicating a read operation with owner-based access. However, it does not disclose pagination, result format, or other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence plus endpoint and tier annotation—concise and front-loaded. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has three required parameters and no output schema, the description covers purpose, endpoint, and a basic access constraint. It lacks return format details, but for a standard CRM association list, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67% (two of three parameters have descriptions with examples). The description does not add further meaning beyond what is in the schema. The parameter names are self-explanatory, so minimal extra value is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists records of one object type associated with a specific record, using a specific verb-resource combination. It maps to a clear API endpoint, distinguishing it from sibling tools that get or list single object types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving associations between object types, but does not explicitly contrast with sibling tools like get_contact or list_deals. The tier annotation provides some context but lacks when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_companiesC

List a company record. At least one of name or domain is required on create — domain is recommended, since it's the primary de-duplication key. records, cursor-paginated. Maps to GET /crm/v3/objects/companies. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No	Pagination cursor from a previous call's paging.next.after
`limit`	No	Default 10, max 100
`properties`	No	Which properties to return. Defaults to: name, domain, phone, city, state, industry

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description mentions cursor pagination, the HTTP GET method, and a tier 'readonly-owner', indicating a safe read operation. However, it contradicts itself by including create requirements, which is misleading. Without annotations, the description carries full burden but fails to disclose behavioral traits consistently.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but includes irrelevant create information that wastes space. It is not concise; every sentence should serve the tool's purpose, and the create sentence is unnecessary and confusing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should compensate by explaining return values and how to use the tool. It mentions pagination but omits details on response format. The contradictory create info further reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for its 3 parameters, fully describing them. The description adds a note about 'cursor-paginated' which relates to the 'after' parameter, but otherwise adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List a company record,' indicating the primary purpose. However, it immediately follows with create requirements ('At least one of name or domain is required on create'), which is irrelevant and potentially misleading for a list tool, reducing clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this list tool over its sibling 'get_company'. It mentions cursor pagination, implying it's for listing multiple records, but no explicit when-to-use or when-not-to-use advice is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_dealsB

List a deal (sales opportunity) record. dealname and dealstage are required on create; pipeline defaults to your account's default pipeline if omitted. records, cursor-paginated. Maps to GET /crm/v3/objects/deals. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No	Pagination cursor from a previous call's paging.next.after
`limit`	No	Default 10, max 100
`properties`	No	Which properties to return. Defaults to: dealname, dealstage, pipeline, amount, closedate, hubspot_owner_id

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry full burden. Mentions read-only tier and pagination, but fails to disclose behavioral traits like access scoping, rate limits, or whether response order is guaranteed. Minimal value beyond obvious list behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose. Could be tighter by omitting create-related information that distracts from the list operation. Efficient but not maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description provides pagination and readonly hints, but lacks details on response structure, error handling, or field value limits. Adequate for a simple list tool but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by specifying default properties returned and clarifying that the 'after' parameter handles cursor pagination. Also notes default pipeline for creation, though not directly relevant to listing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states tool lists 'deal records' and differentiates from sibling tools like get_deal. However, mentions create requirements (dealname, dealstage required on create) which are irrelevant for a list operation, causing minor confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides pagination details and maps to a specific API endpoint, but lacks explicit guidance on when to use this vs. get_deal or other list tools. No when-not-to-use or exclusions stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_notesA

List a note logged on a CRM record's timeline (e.g. a contact, company, or deal). hs_timestamp is required on create — pass associations to attach it to a record, otherwise it won't show up anywhere useful. records, cursor-paginated. Maps to GET /crm/v3/objects/notes. [tier: readonly-owner]

ParametersJSON Schema

Name	Required	Description
`after`	No	Pagination cursor from a previous call's paging.next.after
`limit`	No	Default 10, max 100
`properties`	No	Which properties to return. Defaults to: hs_note_body, hs_timestamp, hubspot_owner_id

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It reveals that results are cursor-paginated and maps to a specific GET endpoint. It also notes the tier ('readonly-owner'). However, it does not mention rate limits, authentication requirements, or behavior when no notes exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief with four sentences. The main purpose is front-loaded. Each sentence adds value, but the mention of 'hs_timestamp' on create could be seen as slightly off-topic. Overall, it is concise without significant waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description conveys that results are 'records, cursor-paginated', which provides some structure. The sibling tools (like list_companies, get_note) give context. It could be more complete by describing the return format, but it is adequate for a simple list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides. The tip about 'hs_timestamp' on create does not relate to the current tool's parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists notes from a CRM record timeline, with examples of record types (contact, company, deal). It distinguishes itself from sibling 'get_note' by implying this is for multiple notes, and the verb 'list' is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing notes on a record timeline but does not explicitly state when to use this tool versus alternatives like 'get_note'. The mention of 'hs_timestamp' and associations is more relevant to creation than listing. No explicit 'when not to use' guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct resource or action: contacts, companies, deals, notes, and associations, with clear 'list' vs 'get' differentiation. No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case (e.g., get_contact, list_companies). The 'list' and 'get' prefixes are standard and predictable.

Tool Count5/5

8 tools is well-scoped for a read-only CRM server covering contacts, companies, deals, notes, and associations. Each tool serves a clear purpose without redundancy.

Completeness2/5

The server is read-only and lacks essential create, update, and delete operations for CRM objects. For a HubSpot CRM server, this is a significant gap that limits agent workflows.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

HubSpot
com.hubspot.app
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.
Customer Data Platforms Databases Marketing
3
RevOrbit CRM
com.revorbit
Search, summarize, and update your RevOrbit CRM (leads, deals, contacts, tasks) in plain language.
CRM Search
2
FirstTouch
io.github.First-Touch-Inc
Give AI agents real hands on LinkedIn: sourcing, AI qualification, HubSpot-native attribution.
Social Media AI & Machine Learning CRM
2
Plixana
com.plixana
Operate the Plixana CRM from any AI: contacts, deals, quotes, WhatsApp and metrics.
CRM Communication
2

Related MCP Servers

HubSpot MCP Server
Databases Search RAG Systems
baryhuang
A
license
B
quality
F
maintenance
Enables AI models to interact with HubSpot CRM data and operations through a standardized interface, supporting contact and company management.
Updated 10 months ago (2025-11-11 18:22 UTC)
16
128
MIT
HubSpot MCP Server
Customer Data Platforms Communication Marketing
Manhar-Chaurasia
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with HubSpot CRM for managing contacts, companies, deals, and sending emails through natural language commands.
Updated 10 months ago (2025-11-17 07:31 UTC)
527
MIT
HubSpot MCP Server
Customer Data Platforms Marketing App Automation
dynamic
F
license
Not graded
quality
Not graded
maintenance
Enables management of HubSpot CRM entities including contacts, companies, deals, and pipelines through natural language. It provides comprehensive tools for listing, searching, creating, and updating records with support for OAuth 2.0 authentication.
Updated 8 months ago (2026-01-14 17:07 UTC)
HubSpot MCP Server
CRM Communication
djmoore-projects
A
license
A
quality
B
maintenance
Exposes HubSpot CRM data and actions as tools for AI agents, enabling contact lookup, company search, contact creation, and activity logging via natural language.
Updated 2 months ago (2026-07-10 16:32 UTC)
4
527
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jayson-svg/backcrew-mcp-hubspot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

BackCrew HubSpot MCP Server

Contents

What this actually does

Why use an independent MCP server instead of the platform's own AI?

Scope: this is intentionally narrow

Also from BackCrew

Some words you'll see, explained

How this keeps you safe by default

What it can look up (always safe)

⚠️ What it can change (off by default)

How to set it up

Step 1: Make a folder for this on your computer

Step 2: Get a HubSpot Private App token

Step 3: Install it

Connecting it to Claude

Testing it safely

For developers

Tool reference

Why this repo uses a CRUD factory instead of hand-written tools per object

Project layout

The tier/profile system

Notes on the HubSpot API

What's next

Built by BackCrew

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API