HubSpot

Discovers HubSpot data types, pipelines, and stages.

<capabilities>

• Searches across all HubSpot data types available to the current user
• Returns type names that can be used as input to other tools
• Shows read/write access status for each type based on the current user's permissions
• Returns pipelines and their stages (including open/closed status) for a data type

</capabilities>

<usage_guidance>

• Use this tool FIRST when you need to identify which data types exist before querying data
• Use SEARCH_OBJECT_TYPES when you don't know the exact type name
• Use GET_OBJECT_TYPES when you already know the type names (e.g. CONTACT, DEAL), or with an empty typeNameFilter list to retrieve all available types
• Use GET_PIPELINES to list the pipelines and stages for a type (e.g. deal or ticket stages)
• GET_PIPELINES stage metadata: probability (DEAL only) is the likelihood (0-1) the deal closes successfully. state (all other types) is OPEN or CLOSED, except for LEAD where the values are NEW, IN_PROGRESS, QUALIFIED, or UNQUALIFIED — QUALIFIED and UNQUALIFIED are the closed/terminal states, NEW and IN_PROGRESS are open
• Check readAccess/writeAccess before attempting operations on a type

</usage_guidance>

<examples> <example> <user_input>How many support requests did we get last month?</user_input> <tool_call>{"query": {"_queryType": "SEARCH_OBJECT_TYPES", "searchTerms": "support requests tickets"}}</tool_call> </example>

<example> <user_input>How many products do we have?</user_input> <thoughts>"products" is ambiguous — it may be HubSpot's standard Products object or a custom object like p12345_product_models, and semantic search tends to rank the standard one first, so I won't just take the top hit. I'll review all candidates and, if more than one plausibly matches, ask the user to clarify before querying.</thoughts> <tool_call>{"query": {"_queryType": "SEARCH_OBJECT_TYPES", "searchTerms": "products"}}</tool_call> </example>

<example> <user_input>What fields are on contacts and deals?</user_input> <tool_call>{"query": {"_queryType": "GET_OBJECT_TYPES", "typeNameFilter": ["CONTACT", "DEAL"]}}</tool_call> </example>

<example> <user_input>What types of data does HubSpot have?</user_input> <tool_call>{"query": {"_queryType": "GET_OBJECT_TYPES"}}</tool_call> </example>

<example> <user_input>What are the deal pipeline stages?</user_input> <tool_call>{"query": {"_queryType": "GET_PIPELINES", "objectType": "DEAL"}}</tool_call> </example> </examples>

<deprecation_notice> DEPRECATED: DO NOT USE. This tool is deprecated. Use these replacements instead:

• Use search_properties to discover available property definitions for a CRM object type
• Use get_crm_objects to fetch specific CRM objects by their IDs

</deprecation_notice>

Portal-level AEO analytics: brand visibility, mentions, citations, competitor share-of-voice, and per-assistant breakdowns for a date window. Select the sections you need with include, a JSON array of section names, e.g. ["SUMMARY", "PROMPTS"] (SUMMARY, PROMPTS, CITATIONS, CITATION_ANALYSIS, COMPETITORS, ASSISTANT_BREAKDOWN, RUN_STATUS, ICPS_AND_PRODUCTS, BUSINESS_UNITS, LIMITS); defaults to {SUMMARY, RUN_STATUS}. businessUnitId is optional: omit it to use the portal's business unit automatically, or call once with include=["BUSINESS_UNITS"] first to choose one when the portal has several. CITATION_ANALYSIS additionally requires a citationUrl. Dates are ISO-8601 (YYYY-MM-DD); default to the last 30 days. Call tool_guidance (mcpToolInstructions) for the full section catalog, setup-status semantics, and field-level details.

Get campaign analytics (METRICS or REVENUE_ATTRIBUTION) for one or more campaigns. Each entry in the request list is a full analytics request. Each response contains the campaignObjectId of the requested campaign.

Get metrics for specific CRM objects associated with a campaign. campaignObjectId, assetType, and crmObjectIds are all required. Search the campaign's associated objects for objects of the given asset type to retrieve their CRM object IDs, then pass those IDs here. assetType should be a valid campaign asset type such as LANDING_PAGE, SITE_PAGE, BLOG_POST, or MEETING_EVENT. If an invalid assetType is provided, the error will list the valid types. Optional date range (ISO 8601 YYYY-MM-DD) to populate date range metrics.

REQUIRED FIRST STEP: before your first call, invoke tool_guidance for "get_campaign_attribution_reports" and follow it. The dimension names, filter syntax, date-range semantics, grouping rules, and query patterns live in tool_guidance, not in this description; calling this tool without them produces wrong or failed queries. If you skip tool_guidance, submit your first call with hasReadToolInstructions=false (the default); the tool will return status=READ_TOOL_INSTRUCTION_REQUIRED with the full instructions in toolInstructions — read them, then retry with hasReadToolInstructions=true. Attribution data tool: all metrics (revenue, deal amounts, deal counts, contact counts) are scoped to the closed-won deal attribution pipeline. Use for revenue, attributed deal, and attributed contact questions. CONTACT_COUNT = contacts whose interactions influenced closed-won deals; this is NOT a "new contacts generated" metric. For non-attribution contact queries (new contacts, influenced contacts, sessions), use read_campaign_data with GET_ANALYTICS. Scope note: this data covers closed-won / attributed deals only. For deals at any stage (open, opportunity, qualifiedtobuy, and so on), use read_campaign_data with operation=GET_ASSET_METRICS and assetType=DEAL (returns name, stage, amount, close date for all associated deals) or search_crm_objects with a campaign association filter. For long-running queries, this returns a PROCESSING status with a taskId to poll for results.

Get paginated contact IDs for a campaign filtered by attribution type. contactType options: NEW_CONTACTS_FIRST_TOUCH (first marketing interaction was this campaign), NEW_CONTACTS_LAST_TOUCH (last interaction before conversion), INFLUENCED_CONTACTS (any engagement within the date range). Returns contact VIDs usable with CRM tools. Date range is optional (ISO 8601 YYYY-MM-DD); omit for full campaign lifetime. Pagination: offset-based, limit 100–500.

Run a content analytics report across landing pages, website pages, and blog posts in the portal. Returns: TOTALS: ranked rows of contentId, contentTitle, and the requested metric value. TIME_SERIES: per-contentId series of {timestamp, value} points for the requested metric and period. SUMMARY: aggregated per-period points (one value per bucket) for the requested metric. PEOPLE: list of contacts/visitors (contactId or session identifier, plus available identity fields) who viewed the specified contentIds. Pick mode by intent: TOTALS to rank, TIME_SERIES to chart trends per page, SUMMARY for a single aggregated trend, PEOPLE for who-viewed lookups. TIME_SERIES/PEOPLE require contentIds. Examples: mode=TOTALS metric=VIEWS limit=10 -> top 10 pages by views. mode=TIME_SERIES contentIds=[123] metric=SUBMISSIONS period=LAST_30_DAYS -> daily submissions for page 123. Requires 'Read analytics related to pages, blogs and other content assets' permission and a Pro or Enterprise portal.

Fetches multiple CRM objects of the same object type in a single request.

<returns> A list of CRM objects with their properties, identified by their unique IDs, containing:

• id: Unique identifier for the CRM object
• properties: Key-value pairs of property names and their values
• createdAt: Timestamp when the object was created
• updatedAt: Timestamp when the object was last updated
• url: URL to view the object in HubSpot

</returns>

<usage_guidance>

• Use the search_crm_objects tool to list a few objects first without a filter criteria
• Then use the get_crm_objects tool to retrieve those objects by their IDs without any properties in the tool input to understand the data model
• This will help you understand the structure of the objects and their properties

</usage_guidance>

Provides analytics data for marketing emails based on sends in the given date range. To find emails created or published within certain date ranges, use search_crm_objects instead.

The request takes a single field, analysisRequest, which is an OBJECT — never a bare string. It carries a "_type" discriminator plus the section settings for that type. Available analysisRequest types (set as analysisRequest._type):

• "OVERVIEW" — portal-level aggregate statistics (sends, deliveries, opens, clicks, bounces, unsubscribes) over a date range, optionally scoped to specific emails or broken down by time interval. Uses statisticsSection.
• "HEALTH" — portal email health diagnostics. Four sections: mxGroupStatisticsSection (delivery performance statistics by the destination domains with the most deliveries, over a date range); healthScoresSection (monthly 0–100 health scores with per-metric breakdown for click, open, hard bounce, spam report, unsubscribe, and click-to-open — up to 6 months, GLOBAL or INDUSTRY benchmark); sourceHealthScoresSection (same per-metric breakdown per contact source, i.e. where contacts were imported from, past ~30 days); bounceReasonsSection (breakdown of bounces by reason category over a date range, split into hard and soft bounces, optionally scoped to a single MX group).
• "RECIPIENTS" — delivery outcome and engagement summary for a specific contact recipient, with an optional ordered event timeline (sent, opened, clicked, bounced, etc.). Uses recipientDetailsSection. No operation returns a collection of all recipients for an email; only individual recipient information is available.
• "UNSUBSCRIBE_SURVEY" — breakdown of unsubscribe survey responses by reason code (NO_LONGER_INTERESTED, DID_NOT_SIGN_UP, TOO_MANY_EMAILS, IRRELEVANT_CONTENT, OTHER) over a date range. Optionally scoped to a specific email by emailContentId. Use this to understand WHY contacts unsubscribed and improve future emails.

Lists organization-wide teams, job titles (roles), seats, and account information (eg timezone, currency). Use the include parameter to request only the data you need.

<returns>

• GUIDANCE (optional): Returned if additional context is required so provide a useful response

Only fields listed in the include parameter are returned (or all fields if include is omitted):

• TEAMS: Team objects with name, member's owner IDs, and metadata (org-wide, not personal — for the current user's team use get_user_details with include=[TEAMS_AND_ROLES])
• SEATS: Available seat type names in the organization (use these as filters with search_crm_objects on USER objectType to count how many users hold each seat)
• JOB_TITLES: Job titles/roles present in the organization
• ACCOUNT_INFORMATION: Account timezone, currency, account type, UI domain, account ID, portal name, and create date (epoch millis). Portal name and create date require the portal-context-metadata rollout

</returns>

<usage_guidance>

• IMPORTANT: Check if user query contains first-person language ("my team", "my role", "my manager", "my direct reports")
• If query uses "my", "I", or "me" referring to personal context → Use get_user_details instead
• EXCEPTION: "my teams" or "which teams am I on" should use this tool since get_user_details only returns a single primaryTeam
• If query is organization-wide ("our marketing team", "the sales team", "all managers", "my teams") → Use this tool
• Use the include parameter to fetch only what you need and reduce response size
• Include TEAMS when you need team membership or structure
• Include SEATS when you need available seat types
• Include JOB_TITLES when you need roles/job titles to filter users by role
• Include ACCOUNT_INFORMATION when you need the account's timezone, currency, account type, UI domain, portal name, or create date
• To find or count users by role or seat, use the returned job titles or seat types as filters with search_crm_objects on USER objectType
• SEATS returns only seat type names, not user counts — you MUST follow up with search_crm_objects to get user counts per seat type
• When the user references a team's data (e.g., 'our sales team's deals', 'marketing team pipeline'), use this tool first with include=[TEAMS] to resolve team membership to owner IDs, then pass those IDs as filters to search_crm_objects.
• To find "my teams" (plural), call this tool with include=[TEAMS] and find teams with the user's ownerId -- [IMPORTANT]: DO NOT use member name for matching, only use ownerId
• [IMPORTANT] If the guidance field is present, read it carefully before responding — it may contain a user-facing message (e.g., missing permissions requiring reauthorization) that must be relayed to the user, or an agent-internal hint (e.g., name disambiguation) that should influence how you process the results

</usage_guidance>

<examples> <example> <user_query>Who works in sales at my company?</user_query> <action>Use this tool with include=[TEAMS] to get teams, then filter for sales-related ones</action> </example>

<example> <user_query>Show me deals for MY team?</user_query> <action>Do NOT use this tool, use get_user_details instead</action> </example>

<example> <user_query>Search deals for all marketers</user_query> <action>Use this tool with include=[JOB_TITLES] to find marketing-related roles</action> </example>

<example> <user_query>How many users have each seat type?</user_query> <action>Use this tool with include=[SEATS] to get seat type names, then use search_crm_objects on USER objectType filtering by each seat type to count users per seat</action> </example>

<example> <user_query>Show me our sales team's deal pipeline</user_query> <action>Use this tool with include=[TEAMS] to get the sales team's member owner IDs, then use search_crm_objects to filter deals by those owner IDs.</action> </example>

<example> <user_query>Which teams am I on?</user_query> <action>Use this tool with include=[TEAMS] to get all teams, then find teams that contain the member's ownerID (NOT MEMBER'S NAME)</action> </example> </examples>

Fetches property definitions including data types and enumeration values.

<capabilities>

• Particularly useful for discovering valid options in enumeration-type properties
• To search for actual data, use search_crm_objects

</capabilities>

<returns> List of property definition objects containing:

• name: Property identifier
• label: Display label
• description: Property description
• type: Data type (string, enumeration, number, etc.)
• options: For enumeration types, list of valid values with labels

</returns>

<usage_guidance>

• Property details can be unexpectedly large. Consider fetching in batches
• It's not advised to pass an objects full list of properties into this tool

</usage_guidance>

Returns user, team and hub info; CRM/marketing object and tool availability.

Call this before other HubSpot operations to establish the current user's identity, permissions, and which object types and tools are available. Returns info for the current user only — to find other users/owners, search the "users" objectType with search_crm_objects.

<usage_guidance>

• Object availability drives which objectType values other tools accept. Each object type has TWO statuses: read (view/search) and write (create/update) — check the one matching your operation.
• Also reports availability of the other MCP tools; trust this over a tool's own listing, especially when a tool is not AVAILABLE.
• Any non-AVAILABLE object or tool needs user action to resolve (some issues the user alone cannot fix) — surface it only if the task requires that object/tool.
• include selects sections: omitted/empty returns USER_INFORMATION + TOOL_INFORMATION; TEAMS_AND_ROLES must be requested explicitly.
• TEAMS_AND_ROLES is personal context only (the user's primary team with member owner IDs, job title, seats, direct report owner IDs). For org-wide teams/roles, "my teams", or account settings (timezone, currency, account type), use get_organization_details.
• directReports are NOT team members. If the user asks about direct reports and directReports is empty, tell them none are configured and ask before substituting team members — never substitute automatically.

</usage_guidance>

Availability statuses:

• AVAILABLE: usable
• REQUIRES_REAUTHORIZATION: disconnect and reconnect the connector
• REQUIRES_PERMISSION_MODIFICATION: user lacks a HubSpot permission
• REQUIRES_ACCOUNT_MODIFICATION: account needs an upgrade
• BLOCKED_FOR_PORTALS_WITH_SENSITIVE_DATA: sensitive data, unresolvable
• NOT_AVAILABLE: no user action can enable it

Returns:

• userId and hubId (accountId)
• guidance (if present): relay its message to the user
• onboarded (if present): false = portal has not completed initial setup

Read AI responses to tracked prompts, or create and run new tracked prompts. Provide exactly one operation: DETAIL (a single prompt's per-run AI response text, citations, and mentions for an assistant and date window) or CREATE (start tracking new prompts and run them immediately). CREATE requires a confirmed=false preview before confirmed=true. Call get_aeo_metrics with include=[BUSINESS_UNITS] then include=[ICPS_AND_PRODUCTS] to get the businessUnitId, icpIds, and productIds that CREATE needs. Call tool_guidance (mcpToolInstructions) for the confirmation workflow and per-operation details.

List and inspect AI-search brand recommendations for a business unit. Provide exactly one operation: LIST (recommendations for a business unit, filterable by status/prompt), DETAIL (one recommendation enriched with action-status fields), or START_ACTION. Call get_aeo_metrics with include=[BUSINESS_UNITS] first to get the businessUnitId. Starting a recommendation's action isn't available through the assistant yet — START_ACTION returns a message directing the user to complete it in HubSpot AEO. Call tool_guidance (mcpToolInstructions) for per-operation details.

Create, update, publish, and inspect HubSpot blog posts. One action per call. Read actions: GET_POST, GET_AUTHOR, LIST_BLOGS, LIST_BLOG_POSTS, LIST_TAGS, GET_BRAND_KIT. Write actions: CREATE, UPDATE, SET_AUTHOR, PUBLISH, UNPUBLISH. A blog post is rich text (an HTML body) plus metadata and tags, NOT a module grid — there are no module/layout actions. Posts are created as DRAFTS; PUBLISH is a separate explicit action. PUBLISH requires the post to already have a metaDescription and an author, so set both (via UPDATE and SET_AUTHOR) before publishing. Read before you write: call action=GET_POST to capture the current title, body, metadata, and tags before editing. Write actions mutate the same shared draft, so issue them ONE AT A TIME — never concurrently. Creating a post is confirm-first: describe the post to the user (title, outline, which blog) IN CHAT and get their explicit confirmation before calling CREATE. If the user hasn't said which blog to use, call action=LIST_BLOGS and pass the chosen id as blogId. This tool can also list existing posts: call action=LIST_BLOG_POSTS when the user wants to browse posts or edit one without knowing its contentId; optionally pass blogId to scope the list. Tagging: before setting tags on CREATE or UPDATE, call action=LIST_TAGS and reuse existing tags whose names fit, using their exact names; tags are matched by exact name, so a near-variant (e.g. "Content Marketing" when "Marketing" already exists) creates a duplicate instead of reusing it. Do not create new tags on your own — if none of the existing tags fit, ask the user before setting createNewTags=true, and if they don't approve, add no tags. This tool never renders a card. After your LAST edit (or after CREATE or PUBLISH), call render_asset with assetType=BLOG_POST and assetId=contentId to show the finished post. Typography and color: HubSpot blog templates often set font-family and color on individual HTML elements. When changing the body font or text color, put the inline style directly on every affected text-bearing element, such as h2, h3, p, li, a, and span. For example: <h2 style="font-family: Georgia, serif;">…</h2><p style="font-family: Georgia, serif;">…</p>. Do not put font-family or color only on a wrapping <div>: a template rule on a child element can override that inherited value. Examples: action=LIST_BLOGS -> blogsJson with each blog's id and name. action=LIST_BLOG_POSTS blogId=456 limit=10 -> postsJson with existing post summaries. action=CREATE title="…" postBody="<h2>…</h2><p>…</p>" tags="Marketing, SEO" -> contentId + editorUrl. action=GET_POST contentId=789 -> postJson with title, body, metadata, and tags. action=UPDATE contentId=789 postBody="<h2>Intro</h2><p>…</p>" -> verifiedChangesJson. Read actions require 'blog-post-read' or 'blog-posts-write'. GET_POST for a tagged post additionally requires 'blog-tags-read' to return tag names. Write actions require 'blog-posts-write'; non-empty tags additionally require 'blog-tags-read' and 'blog-tags-write'; PUBLISH additionally requires 'blog-posts-publish'.

Creates or updates HubSpot marketing campaigns and manages asset associations.

<prerequisites> Use CRM tools to retrieve the campaign's campaignCrmObjectId before using CAMPAIGN_UPDATE or CAMPAIGN_ASSET operations. </prerequisites>

<mandatory_confirmation_process> Always show proposed changes in a table and get explicit user approval before creating or updating campaigns or modifying asset associations. This step is CRITICAL.

<confirmation_rules>

• First confirmation only: Add this line after the approval prompt: "Want to skip confirmations for this chat? Just ask."
• After 1 confirmation: Stop offering the skip option, but keep confirming
• If user opts out: Skip confirmations for remainder of session

</confirmation_rules>

<confirmation_format> Proposed Changes:

| operationType | Field | Value | |-----------------|-------------|-------------------| | CAMPAIGN_CREATE | displayName | Q3 Brand Campaign |

Approve? [✓ Yes / ✗ No] Want to skip confirmations for this chat? Just ask. </confirmation_format> </mandatory_confirmation_process>

<operations> The operationType field is required on every request:

• CAMPAIGN_CREATE: set createRequest with required displayName, optional startDate, endDate, goal, audience, notes, customProperties.
• CAMPAIGN_UPDATE: set updateRequest with required campaignCrmObjectId, optional displayName, startDate, endDate, goal, audience, notes, customProperties.
• CAMPAIGN_ASSET: set assetRequest with required campaignCrmObjectId, assetOperations (non-empty list of {action, assetObjectType, crmObjectIds}). Each entry has its own ADD|REMOVE action. Check assetOperationFailures in the response — if non-empty, those operations failed; succeeded ones are already applied. Call CAMPAIGN_ASSET_TYPES_LIST first.
• CAMPAIGN_ASSET_TYPES_LIST: no additional fields required.

</operations>

Creates or updates CRM objects with properties. Create object associations.

<prerequisites> Use the get_user_details tool to identify the ownerId and check supported object types. </prerequisites>

<mandatory_confirmation_process> Always show proposed changes in a table and get explicit user approval before creating or updating CRM objects. This step is CRITICAL for you to use this tool correctly.

<confirmation_rules>

• First confirmation only: Add this line after the approval prompt: "Want to skip confirmations for this chat? Just ask."
• After 1 confirmation: Stop offering the skip option, but keep confirming
• If user opts out: Skip confirmations for remainder of session

</confirmation_rules>

<confirmation_format> Proposed Changes:

| Object Type | ID | Property | Current Value | New Value | |-------------|-----|----------|-----------------|--------------------| | Contact | 123 | email | old@example.com | new@example.com |

Approve? [✓ Yes / ✗ No] Want to skip confirmations for this chat? Just ask. </confirmation_format> </mandatory_confirmation_process>

<creating_associations> To create associations between CRM objects:

• Use the createRequest attribute to create a new CRM object and associate it with an existing CRM object
• Use the updateRequest attribute to associate two existing objects
• ALWAYS ask user to confirm which specific objects should be associated before creating associations
• Example workflow: create contact → get contact ID → find company ID → confirm with user → create an association

</creating_associations>

<guidance>

• Limit upsert objects and associations to a MAXIMUM of 10 objects per request
• Not all properties are editable. Use search_properties tool to list available properties or search_crm_objects to sample existing data before making changes
• For concept nouns ("lead", "appointment", "account"), ALWAYS call discover_hubspot_schema first to get the exact typeName — never infer from training data. Schemas are portal-specific (e.g. "lead" may be LEAD or a CONTACT lifecycle stage), and creating the wrong object type cannot be undone.

</guidance>

Create, edit, style, publish, clone, and inspect HubSpot landing pages. One action per call. Reads: MODULES, MODULE_TYPES, MODULE_DEF, MODULE_STYLES, MODULE_GUIDE, REVISIONS, TEMPLATES, FORMS, BRAND_KIT. Writes: CREATE_FROM_TEMPLATE, CREATE_CUSTOM_TEMPLATE, UPDATE_CUSTOM_TEMPLATE, SET_MODULE_FIELDS, SET_MODULE_STYLES, SET_SECTION_STYLES, INSERT, REMOVE, REMOVE_SECTION, MOVE, SET_METADATA, PUBLISH, CLONE, RESTORE_REVISION. Read before write: MODULES before any edit; MODULE_TYPES before INSERT; MODULE_DEF before unfamiliar fields; MODULE_STYLES before SET_MODULE_STYLES. Writes mutate one shared draft — never concurrently. BATCH IS THE DEFAULT for compound edits: group SET_MODULE_FIELDS/STYLES/SECTION_STYLES/METADATA/REMOVE/MOVE into one action=BATCH call (operationsJson, sequential server-side, returns batchResults). Max 10 operations per batch; at most one REMOVE/REMOVE_SECTION/MOVE per batch. NOT batchable (always separate): INSERT/CREATE_*/CLONE/PUBLISH/RESTORE_REVISION. If BATCH returns "not currently supported", fall back to sequential calls. CREATE_FROM_TEMPLATE requires explicit user confirmation IN CHAT — choosing a template is NOT confirmation. Confirm before PUBLISH or RESTORE_REVISION. Never renders a card — after your LAST edit or PUBLISH, call the render tool. Examples: action=MODULES contentId=123 -> modulesJson. action=CREATE_FROM_TEMPLATE pageName="Spring Promo" templatePath="..." -> {status,contentId,editorUrl}. action=SET_MODULE_FIELDS contentId=456 moduleId="hero_1" fieldOverridesJson={headline:"Hi"} -> verifiedFieldsJson. action=SET_SECTION_STYLES contentId=456 moduleId="hero_1" stylesJson={backgroundColor:{r:255,g:238,b:0,a:1}} -> verifiedStylesJson. Scopes: reads need landingpages-read or -write; writes need landingpages-write; PUBLISH additionally needs landingpages-publish.

Manages a marketing email's settings and content. Call tool_guidance for guidance.

Settings sub-operations (_type):

• "LIST_SUBSCRIPTION_TYPES" — list subscription types; call before CREATE to get a valid subscriptionTypeId
• "LIST_FROM_ADDRESSES" — list verified from addresses; call before CREATE to choose a replyToEmail; if address not listed, list options and stop
• "CREATE" — create a new email (required: name, subject, fromName, replyToEmail, subscriptionTypeId; permanent fields — ask the user BEFORE calling CREATE: templatePath: ask template or blank? call LIST_TEMPLATES to show options; brandId; emailType: BATCH by default, AUTOMATED for workflow emails)
• "POLL_EMAIL_CREATION" — poll for CRM object; takes marketingEmailId
• "UPDATE" — update email settings; template/brandId cannot be changed after creation
• "CLONE" — clone into a new draft
• "GET_EMAIL_DETAILS" — retrieve current settings
• "GET_TEMPLATE" — retrieve a template by path
• "LIST_TEMPLATES" — search/browse templates by kind (CODED or DND) and filename

Content sub-operations (marketingEmailObjectId):

• "GET_CONTENT" — returns the editable layout
• "EDIT_CONTENT" — always call tool_guidance; resubmit full layout; preserve all styling, only change text/links/images
• "PREVIEW_CONTENT" — renders the email; returns subjectLine, renderedText, (optional) renderedHtml
• "AB_TEST_EMAIL" — set up an A/B test on a draft email by adding Version B; use this whenever the user asks to test two versions, create a version B, split test, or try two subject lines — they often don't say "A/B" explicitly

Only draft emails can be edited. Always show proposed changes and get explicit user confirmation before creating, updating, or editing.

<purpose>Assess a portal's CRM onboarding status and guide the user through the next onboarding step.</purpose><usage_guidance>Call this tool when get_user_details returns onboarded: false — this indicates the portal may be new and not yet set up. After answering the user's immediate question, invoke this tool proactively and offer to help them get started. Do not call this tool if get_user_details returned onboarded: true. Use action to control behavior: leave empty (the default) to just check status. SET_GOAL — records the user's primary goal; requires goal to be set to one of organizeAndTrackContacts, automateMarketing, generateLeads, manageSalesPipeline, customerSupport, billsAndCollectPayment, buildWebsite, createMarketingContent, or stillExploring — map the user's own words to the closest matching value. Only one goal can be stored; setting a new goal replaces any previous one.</usage_guidance><returns>goalStatus: NOT_STARTED or COMPLETE — whether the user has set an onboarding goal; goal: the user's stored goal (present once set); taskGroup: the onboarding task group for that goal (present once the goal is set, unless every task is already done) — a nested structure of a group with a name, a list of childGroups (each with its own name and further childGroups), and tasks, where each task has a name, description, and link the user can open; tasks the user has already completed or skipped are excluded, and taskGroup is omitted entirely when nothing is left to do; guidance: actionable guidance for you, the agent — when present, follow it and present the returned tasks as a set of options for the user to choose from; do not collapse them into a single step</returns><response_rendering>Render every returned task, including those nested in child groups, as a markdown link [task name](task link) with its description. List all of them (guidance says how many); do not omit or limit. Always render: See all onboarding tasks in your [start guide](guideLink).</response_rendering>

Create, edit, style, publish, clone, and inspect HubSpot website pages, and edit the site's navigation menus. Set exactly one operation; the operation's own shape lists the fields it takes, so there are no conditional field rules to infer. Read before you write: read MODULES to capture verbatim current values AND each module's layout position before any edit, MODULE_TYPES before an insert, MODULE_DEF before writing unfamiliar fields, MODULE_STYLES before restyling one. Write operations mutate the same shared draft, so issue them ONE AT A TIME — never in parallel, or they clobber each other. Reads have no side effects and may be batched. Creating a page is confirm-first: present the page and template in chat and get an explicit user confirmation IN CHAT before CREATE_FROM_TEMPLATE — choosing a template is NOT confirmation. This tool never renders a card; after your LAST edit call render_asset with assetType=WEBSITE_PAGE and the contentId as assetId. Confirm with the user before PUBLISH or RESTORE_REVISION, and before any NAV_* write (those are live and site-wide). Reads require website page read access ('sitepages-access' or 'pages-write'); writes require 'pages-write'; PUBLISH additionally requires 'pages-publish'.

Queries HubSpot CRM data via SQL with HubSpot-specific extensions. IMPORTANT: You MUST call the Tool Guidance tool before your first query. It contains required guidance and examples.

<select> IMPORTANT: Property names must exactly match HubSpot internal names. Always call search_properties to confirm names before querying. The record identifier property is hs_object_id. For financial values, prefer properties ending in _in_home_currency. <unsupported>SELECT DISTINCT, AS aliases, CASE WHEN, IF(), string functions (CONCAT, UPPER, etc.), COALESCE, associations.OBJECT.</unsupported> </select>

<from> One object type per query: CONTACT, COMPANY, DEAL, TICKET, etc. Use a user-details tool to discover supported types. <unsupported>JOIN, UNION, subqueries, CTEs.</unsupported> </from>

<where> Operators — comparison: =, !=, <, >, <=, >=; text/substring match: column LIKE '%value%'; presence: column IS NULL / column IS NOT NULL. List membership: hs_crm_search.ilsListIds = 'LIST_ID' (cannot combine with aggregates or GROUP BY). Date filters: in an aggregation (GROUP BY or aggregate) use a YYYY-MM-DD date, matched by day; in a plain row SELECT either a date or a full timestamp (e.g. '2025-01-01 14:00:00') works. "My"/"I" queries: filter by hubspot_owner_id (see Tool Guidance for resolution steps). </where>

<group-by> DATE_TRUNC(prop, 'INTERVAL') — INTERVAL: DAY | WEEK | MONTH | QUARTER | YEAR. MEDIAN(prop) supported alongside standard aggregates. <unsupported>HAVING.</unsupported> </group-by>

<order-by> Sort direction: ORDER BY column ASC for ascending, DESC for descending. </order-by>

<cross-object> To retrieve associated object data, use OBJECT.property (e.g., SELECT COMPANY.name FROM CONTACT) — NOT associations.OBJECT. associations.OBJECT is for WHERE existence checks only (IS NULL / IS NOT NULL). Never use it in SELECT or GROUP BY. A query can reference at most 2 different associated object types. </cross-object>

REQUIRED FIRST STEP: before your first call, invoke tool_guidance for "read_campaign_data" and follow it; it contains the required parameter details and examples for each operation. Reads campaign data using one of four operations selected by the operation field. GET_ANALYTICS: engagement metrics (sessions, new contacts, influenced contacts) for one or more campaigns. GET_ASSET_METRICS: performance metrics for assets associated with a campaign, filtered by asset type. GET_CONTACTS: paginated contact IDs attributed to a campaign, filtered by attribution type (NEW_CONTACTS_FIRST_TOUCH, NEW_CONTACTS_LAST_TOUCH, INFLUENCED_CONTACTS). GET_CAMPAIGN_ASSET_TYPES: returns the portal-enabled campaign asset types with human-readable aliases (e.g. AUTOMATION_PLATFORM_FLOW → workflows). No additional request parameters needed.

Renders a HubSpot asset inline as an MCP UI component. Call this after a manage or read tool completes to show the user a visual preview. Pass the assetType matching the asset you just worked with and its assetId.

<deprecation_notice> DEPRECATED: DO NOT USE. This tool is deprecated, use search_crm_objects instead </deprecation_notice>

Searches and retrieves CRM records from HubSpot based on filters and criteria.

<critical_requirements> *Important*: You must use this over the search:find_objects|count_objects tool. </critical_requirements>

<capabilities>

• Useful to sample data from a specific object type to understand the data model
• Can list and filter by associations between objects (e.g., "contacts associated with company X or contacts with num_associated_deals > 1")
• Use the search_owners tool to list users/owners in the HubSpot account

</capabilities>

<returns> List of matching CRM records containing:

• id: Unique identifier for the CRM object
• properties: Key-value pairs of property names and their values for the requested properties
• urlTemplate: URL template to view the object in HubSpot (replace {property_name} with the property value from the response)
• total: Total count of records matching the search criteria (for analytics and pagination)
• offset: Current pagination offset for retrieving the next page of results

</returns>

<usage_guidance>

• This searches for ACTUAL DATA (records), not field definitions. To discover available fields, use search_properties
• objectType must be an exact type identifier. Standard types (CONTACT, DEAL) may be used directly; for any concept noun ("leads", "appointments", "accounts"), ALWAYS call discover_hubspot_schema first — never infer from training data, as schemas are portal-specific (e.g. "lead" may be a standalone LEAD or a CONTACT lifecycle stage). Re-verify via discover_hubspot_schema if results are empty or unexpected, before concluding data is absent.
• Always check 'total' count to ensure you're not missing data due to pagination limits. You MUST NOT use sample data or insufficient data as a substitute for actual data
• Use the get_crm_objects without properties to understand the data model of an objectType
• You can include a maximum of five filterGroups with up to 6 filters in each group, with a maximum of 18 filters in total
• [Important] When the requested data includes a currency-typed amount property (e.g., DEAL.amount, LINE_ITEM.price, QUOTE.hs_quote_amount, INVOICE.hs_amount_billed, CART/ORDER.hs_total_price, SUBSCRIPTION.hs_mrr, COMMERCE_PAYMENT.hs_initial_amount), you MUST also include the matching currency-code property in properties (DEAL: deal_currency_code; LINE_ITEM: hs_line_item_currency_code; QUOTE/INVOICE: hs_currency; CART/ORDER/SUBSCRIPTION/COMMERCE_PAYMENT: hs_currency_code). Without it the response cannot be narrated in the correct currency.
• [Important] For DEAL aggregations: amount_in_home_currency is pre-converted to the portal's home currency (from get_user_details -> accountInformation.companyCurrency); never pair it with deal_currency_code. NEVER sum raw amount across different deal_currency_code values. To aggregate: filter to a single currency, or use amount_in_home_currency and state the total is in the portal's home currency.
• [Important] CRM Analysis can be a complex task. Work with the user to refine requirements and segment large datasets into manageable parts before performing analysis
• [Important] You MUST include a clickable URL for every record returned, without exception. ALWAYS include UTM params in the URL
• [Important] You should use associatedWith for searching objects by associations

</usage_guidance>

<filtering_capabilities>

• Think of "filterGroups" as separate search conditions that you want to combine with OR logic (meaning ANY of them can match)
• If you want to find things that match ALL of several conditions (AND logic), put those conditions together in the same filters list
• If you want to find things that match AT LEAST ONE of several conditions (OR logic), put each condition in a separate filterGroup
• You can include a maximum of five filterGroups with up to 6 filters in each group, with a maximum of 18 filters in total

</filtering_capabilities>

Lists and searches for owners who can be assigned to CRM records.

<capabilities>

• Supports searching by name/email or batch lookup by owner IDs
• HubSpot owner ids and user IDs are distinct, lookups only work when owner ids are provided specifically

</capabilities>

<returns> List of owner objects containing:

• ownerId: The ID to use for hubspot_owner_id assignments
• name: Display name of the owner
• isActive: Whether the owner is currently active

</returns>

<examples> <example> <description>Search by name</description> <query>{"searchQuery": "John Smith"}</query> </example>

<example> <description>Lookup specific IDs</description> <query>{"ownerIds": [12345, 67890]}</query> </example>

<example> <description>Paginate results</description> <query>{"limit": 50, "offset": 50}</query> </example> </examples>

Finds the most relevant CRM property definitions using keyword-based search.

<critical_requirements> *Important*: You must use this over the fetch tool to get HubSpot CRM Objects. </critical_requirements>

<capabilities>

• Lists all property definitions for specified object type when no search terms provided
• To search for actual data, use search_crm_objects

</capabilities>

<returns> A filtered list of properties matching the search criteria containing:

• name: Property identifier
• label: Display label
• description: Property description
• matchScore: Relevance score for the property based on the search query (absent if no query is provided)

</returns>

<usage_guidance>

• Use keywords field for multiple related property guesses in a SINGLE request (recommended for performance)
• MAXIMUM OF 5 KEYWORDS ALLOWED PER REQUEST - exceeding this limit will return a validation error
• Keywords should be property name guesses, not natural language phrases
• Use query field for backward compatibility with single property guess
• No search terms provided: Returns ALL properties for the object type (useful for discovery)

</usage_guidance>

<examples> <example> <user_input>total number of open tickets grouped by urgency</user_input> <thoughts>Customer is asking for total number of open tickets grouped by "urgency". I will look for the best matches on the "urgency" property for the "TICKET" object type.</thoughts> <query>{"objectType": "TICKET", "keywords": ["urgency"]}</query> </example>

<example> <user_input>calls assigned to me</user_input> <thoughts>Customer is asking us to filter by calls assigned to them. I have a few guesses for what that property might be called: "assigned_to", "assignee", "owned_by", or "owner". Let me search for those on the "CALL" object type in one efficient request.</thoughts> <query>{"objectType": "CALL", "keywords": ["assignee", "assigned_to", "call_owner", "owned_by"]}</query> </example>

<example> <user_input>list each company with its name, employees amount, zip code, and when we last touched base</user_input> <thoughts>Customer is asking us to list companies by a few attributes. I will guess keywords for each of those properties and search for them on the "COMPANY" object type in one request.</thoughts> <query>{"objectType": "COMPANY", "keywords": ["name", "employees", "zip_code", "last_contact"]}</query> </example>

<example> <user_input>tickets for this year to identify top 10 most problems our customers face</user_input> <thoughts>Customer is asking us to analyze tickets. I will return all properties for the "TICKET" object type to help with discovery.</thoughts> <query>{"objectType": "TICKET"}</query> </example> </examples>

<common_mistakes>

• Do not exceed 5 keywords per request (will return validation error)
• Keywords should be property name guesses, not natural language phrases

</common_mistakes>

Opens an interactive feedback form for the user to send feedback about the HubSpot connector to HubSpot.

<scope> EXCLUSIVELY for feedback about HubSpot connector tools (search_crm_objects, manage_crm_objects, get_properties, etc.). Do NOT use for:

• Non-HubSpot tools (Slack, Microsoft 365, Notion, iMessage, Intercom, etc.)
• General AI/LLM quality issues (wrong answers, hallucinations, formatting)
• HubSpot product/UI issues unrelated to the connector

If the issue is with a non-HubSpot tool, do NOT invoke this tool; tell the user this feedback channel is for HubSpot connector issues only. </scope>

<routing> If submit_feedback is available in your toolset, call it directly — do NOT call this tool. A successful response here does not mean the form rendered; clients without MCP UI support still return success. </routing>

<when_to_invoke>

• Agent-detected: user corrects HubSpot connector behavior, reports wrong data/errors, or is dissatisfied with a HubSpot connector tool.
• User-initiated: explicit requests ("I want to give feedback"), indirect asks ("HubSpot should know...", "Tell HubSpot..."), or any clear intent to send feedback to HubSpot.

</when_to_invoke>

<agent_detected_flow> 1. Complete your response FIRST (give the corrected answer). 2. At the END, add a divider (---), then on a NEW LINE acknowledge the trigger ("I noticed you had to correct that"), offer feedback ("Want to share feedback on the connector?"), and make it optional ("Just ask anytime — I'll send it to HubSpot."). 3. If user opts in: call this tool to show the form. 4. If user declines or doesn't respond: continue normally. Never ask again this session. </agent_detected_flow>

<user_initiated_flow> 1. Acknowledge: "Happy to help — opening the feedback form now." 2. Call this tool to show the form. </user_initiated_flow>

<critical_requirements>

• NEVER suggest Claude/ChatGPT thumbs up/down buttons send feedback to HubSpot. Those go to Anthropic/OpenAI only. ONLY this tool sends feedback to HubSpot.

</critical_requirements>

Collects and submits user feedback about the HubSpot connector to HubSpot. Only after the user explicitly confirms the exact feedback to send.

<scope> EXCLUSIVELY for feedback about HubSpot connector tools (search_crm_objects, manage_crm_objects, get_properties, etc.). Do NOT use for:

• Non-HubSpot tools (Slack, Microsoft 365, Notion, iMessage, Intercom, etc.)
• General AI/LLM quality (wrong answers, hallucinations, formatting)
• HubSpot product/UI issues unrelated to the connector

If the issue is not about a HubSpot connector tool, do NOT initiate feedback - tell the user this channel is for HubSpot connector issues only. </scope>

<when_to_invoke> Agent-detected: user corrects HubSpot connector behavior, reports it returned wrong data/errors, or is dissatisfied with a HubSpot connector tool. User-initiated: explicit requests ("I want to give feedback"), or intent to reach HubSpot ("HubSpot should know...", "Tell HubSpot..."). </when_to_invoke>

<flow> 1. Agent-detected only: finish your answer first, then after a divider (---) note the connector issue and OFFER feedback; if declined, continue and never ask again this session. 2. Ask the user to describe the issue in their own words; WAIT. 3. Preview "Here's what I'll send to HubSpot: [their exact words]. Should I go ahead?" and WAIT for confirmation. 4. Only call this tool once the user confirms. </flow>

<critical_requirements>

• NEVER call without explicit user confirmation of the feedback to send.
• The feedback field MUST be the user's own words - never auto-generate or paraphrase.
• Claude/ChatGPT thumbs up/down send feedback to Anthropic/OpenAI, NOT HubSpot; only this tool sends to HubSpot.
• NEVER submit feedback about non-HubSpot tools or connectors.

</critical_requirements>

<purpose> Retrieves guidance and usage instructions for a set of HubSpot tools. </purpose>

<when_to_use>

• If a tool's description isn't enough to commit to using it
• To find if a tool's inputs or outputs have further semantic meaning
• To learn understand if and how certain tools can work together

</when_to_use>

<how_to_call> Pass the names of the tools you want guidance for in toolNames (e.g. ["manage_crm_objects"]). Provide at least one tool name. </how_to_call>