HubSpot

Read AI responses to tracked prompts, or create and run new tracked prompts. Provide exactly one `operation`, a JSON object (not a string) with an `_operationType` field set to DETAIL (a single prompt's per-run summaries — assistant, model, mention and citation counts, cited URLs — for an assistant and date window, without response text), RESPONSES (the full AI response text of up to 5 runs, by promptId or runUuids), 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.

manage_aeo_prompts

List and inspect AI-search brand recommendations for a business unit. Provide exactly one `operation`, a JSON object (not a string) with an `_operationType` field set to LIST (recommendations for a business unit, filterable by status/prompt and paginated via cursor/hasMore/nextCursor), DETAIL (one recommendation enriched with action-status fields and its full citation list), 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.

manage_aeo_recommendations

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>

manage_crm_objects

<purpose>Check whether the user's HubSpot is connected and working. Use it when they ask if it's connected or working, are testing the connection, have just connected, or ask if their CRM is empty or has any data. Also assesses CRM onboarding status and guides the next step.</purpose><usage_guidance>For those connection checks, call this tool right away, without asking first, whatever get_user_details returned for onboarded. Otherwise, call it when get_user_details returns onboarded: false, after answering the user's question and offering to help them get started; do not call it when 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 goal's remaining onboarding tasks (omitted until a goal is set, or when nothing is left to do) — a group with a name, nested childGroups, and tasks, each with a name, description, and link; completed or skipped tasks are excluded; guidance: instructions for you, the agent — when present, follow it and present the returned tasks as 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>

manage_onboarding

Reads and lists saved HubSpot reports. Set action=LIST to search and browse available reports (returns IDs, names, descriptions, and total count). Set action=FETCH to retrieve a single report's full data including its definition and formatted dataset — identify the report by either reportId or reportName. Use LIST first to discover which reports exist, then FETCH to get the data. After a FETCH, display the report by calling render_asset with its ID rather than re-rendering the dataset yourself as a table.

manage_saved_reports

Create, edit, delete, or restore a segment, add/remove its records, or change its exclusions. Set operation.type to one of the operations below; segments are identified by list ID. <mandatory_confirmation> This tool writes to the portal. Before calling it, you MUST show the user a summary of the exact action and get explicit approval: - CreateStaticSegmentOperation (new hand-picked segment): the name, object type, and how many records (if any) will pre-populate it. - CreateDynamicSegmentOperation (new segment whose filter keeps membership current): the name, object type, and filter. - UpdateSegmentOperation (edit in place): the target segment and which of its name, description, or filter change. - AddMembersOperation / RemoveMembersOperation (static membership): the target segment, object type, and number of records added or removed. - RemoveAllMembersOperation (empty it, segment kept) / DeleteSegmentOperation: the target segment, and whether you are emptying or deleting it. - RestoreSegmentOperation (undo a delete): the deleted segment and any new name. - UpdateSegmentSuppressionOperation (exclusions): the target segment and each segment, record, rule, or email domain it starts or stops excluding. End with an explicit approval prompt (e.g. "Proceed? [Yes / No]"). Leave confirmationStatus as UNCONFIRMED until the user approves; only after they confirm, call the tool with confirmationStatus set to CONFIRMED. Do NOT set CONFIRMED before the user approves, even if the user asks you to "just do it" or to skip confirmation. On the first confirmation in a chat you may also offer to stop asking for the rest of the session; if the user agrees, set confirmationStatus to CONFIRMATION_WAIVED_FOR_SESSION on subsequent calls. </mandatory_confirmation>

manage_segment

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'.

manage_blog_post

REQUIRED FIRST STEP: before your first call, invoke tool_guidance for "manage_campaign_objects". Creates or updates campaigns, assigns campaign owners, 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>

manage_campaign_objects

Creates custom pipeline schemas on CRM object types. Custom pipelines are available to paid tiers (Starter and above). <default_pipeline_editing> If portal does not have access to custom pipelines, can edit the default HubSpot-provided pipeline instead. If the user confirms this is okay, set shouldEditDefaultPipelineInstead to true, and provide one schema. </default_pipeline_editing> <mandatory_confirmation_process> Always show proposed schemas in a summary table and get explicit user approval before creating. This is CRITICAL. Set confirmationStatus to CONFIRMED after the user approves, or CONFIRMATION_WAIVED_FOR_SESSION if the user has opted out of per-action confirmations for the remainder of the session. </mandatory_confirmation_process> <write_result_handling> Write tools return per-item results. Each result has a succeeded flag and either successDetails or failureDetails. Always check each result, reporting successes/failures clearly to the user. If failures are remediable, fix and retry those failures. For successes, share the settingsLink from each successDetails with the user. </write_result_handling> <confirmation_format> == Pipelines == Ticket * Support Escalation: <description> - New (OPEN) -> In Progress (OPEN) -> Escalated (CLOSED) -> Resolved (CLOSED) Deal * Enterprise Sales: <description> - Prospecting (15%) -> Qualification (40%) -> Success (100% - Closed Won) -> Failure (0% - Closed Lost) Approve? [Yes / No] </confirmation_format> <custom_pipeline_stage_metadata_rules> DEAL (0-3): - `probability` (REQUIRED): decimal 0.0-1.0 (NOT percentage, NO % sign) - `state`: null LEAD (0-136): - `probability`: null - `state` (REQUIRED): one of 'NEW', 'IN_PROGRESS', 'QUALIFIED', 'UNQUALIFIED' NON-DEAL NON-LEAD: - `probability`: null - `state` (REQUIRED): 'OPEN' (active/in-progress) or 'CLOSED' (terminal/completed) - for TICKET (0-5), must be at least one 'OPEN' and one 'CLOSED' stage </custom_pipeline_stage_metadata_rules>

manage_custom_pipelines

Creates custom property schemas on CRM object types. <mandatory_confirmation_process> Always show proposed schemas in a summary table and get explicit user approval before creating. This is CRITICAL. Set confirmationStatus to CONFIRMED after the user approves, or CONFIRMATION_WAIVED_FOR_SESSION if the user has opted out of per-action confirmations for the remainder of the session. </mandatory_confirmation_process> <write_result_handling> Write tools return per-item results. Each result has a succeeded flag and either successDetails or failureDetails. Always check each result, reporting successes/failures clearly to the user. If failures are remediable, fix and retry those failures. For successes, share the settingsLink from each successDetails with the user. </write_result_handling> <confirmation_format> == Properties == Deal * Risk Level (Drop-down): <description> - High - Medium - Low * Loss Condition (String): <description> Approve? [Yes / No] </confirmation_format> <custom_property_write_rules> Behavioral Rules: - `label` & `description` should be in the user's language (and if english, `label` uses Sentence case) - You should NEVER recommend any property that could contain sensitive information or PII. - `groupName` should use pattern '{objectType}_information' (e.g., 'deal_information', 'contact_information') - Never show or mention the `fieldType` to the user - just reference the overall `type`. Valid Type/FieldType Pairings: - string → text/textarea - bool → booleancheckbox - enumeration → select/checkbox - date → date - datetime → date - number → number - currency_number → number - email → text - url → text </custom_property_write_rules>

manage_custom_properties

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, LIST_CUSTOM_MODULES. Writes: CREATE_FROM_TEMPLATE, CREATE_CUSTOM_TEMPLATE, UPDATE_CUSTOM_TEMPLATE, CREATE_MODULE, UPDATE_MODULE, 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. CREATE_MODULE authors a reusable custom module TYPE (not on any page — check LIST_CUSTOM_MODULES first, then INSERT the returned modulePath). 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_*/UPDATE_*/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/RESTORE_REVISION/UPDATE_CUSTOM_TEMPLATE. 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.

manage_landing_page

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.

manage_marketing_email

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. Custom modules go in `customModuleOperation` INSTEAD of `operation`: CREATE_MODULE authors a reusable custom module TYPE (it puts nothing on a page — check LIST_CUSTOM_MODULES first, then INSERT the returned modulePath). 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, RESTORE_REVISION or UPDATE_CUSTOM_TEMPLATE, 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'.

manage_website_page

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>

query_crm_data

Read-only lookups that support the manageSegment write operations. Set operation.type to: - SearchSegmentsQuery: find existing segments by name (optionally scoped to an object type or list type) to get the list ID needed for AddMembersOperation, RemoveMembersOperation, or a future update/delete. With deleted=true it searches only deleted segments, to find the list ID for a RestoreSegmentOperation. - SearchFilterInputsQuery: resolve the ids that filter expressions take as arguments — association type ids for ASSOCIATION(...), event type ids and properties for UNIFIED_EVENTS(...), form guids, workflow/import ids, and marketing email triples. Users do not know these ids; look them up here rather than guessing, because a guessed id creates a segment that silently filters on the wrong thing. Each result includes a ready-to-use filter fragment. - GetSegmentQuery: fetch one segment's definition by list ID — its object type, list type, name, description, saved filter expression, exclusions, and access level. Use it to inspect a segment before editing it, or to answer what it filters on or excludes. This returns the definition, not the members; deleted=true reads a deleted one. With includeUsage=true it also returns what uses the segment (other segments, workflows, emails, ads); check this before deleting one, or when the user asks where a segment is used. - GetSegmentMembersQuery: list the CRM records inside a segment by list ID (record ID and display name, plus any requested properties), paginated via cursor. This is the only way to read a segment's members: membership is not a CRM property, so a filter search cannot reproduce it. Works for STATIC and DYNAMIC segments. - PreviewSegmentQuery: count the records a filter matches, minus any exclusions the segment will carry, without saving anything. Use it when the user asks how many match or wants a size before creating; to just create a segment, skip it. This tool only reads; it never changes the portal and needs no confirmation.

query_segments

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 of one type associated with a campaign. Metrics are type-specific and NOT comparable across types — do NOT use this for cross-type "top/best performing asset" questions; use getCampaignAttributionReports with dimension=ASSET_TITLE for that (its attribution metrics share a common unit across all asset types; set sortByMetric to the metric the question asks about — REVENUE when no metric is specified). 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.

read_campaign_data

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.

render_asset

Buyer-intent signals for companies and contacts. SEARCH returns signal records, LIST returns the portal's signal types, AGGREGATE returns counts grouped by company/companies. Can narrow aggregates by a signal type. Set `query` to one shape and always set `_queryType`. Put known names in one SEARCH for aliases and suggestions; LIST does not need to be called but can be used for broad catalog discovery. An unknown field is dropped, not rejected, so check the response matches the filters you asked for.

search_intent_signals

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>

search_crm_objects

Search and read conversation threads and ticket or support-case messages from HubSpot inboxes. For the messages of a CONTACT, TICKET, DEAL, or COMPANY, including when summarizing a ticket, use this tool: search_crm_objects and get_crm_objects return record properties, not the thread. Resolve the record ID with search_crm_objects if needed, then pass objectType + objectId. NOTE, EMAIL, and CALL engagements don't hold inbox transcripts. Internal notes live in the thread: set includeAllDialogue=true with includeMessages=true. Pick one mode per call: CRM object (objectType + objectId), time range (startTime/endTime), text search (query and searchMethod, optionally with a time range), or aggregation (aggregationDimensions). With no mode, it returns the most recent conversations. Time-range mode matches conversations active in the window (hs_lastmodifieddate); aggregation counts those started in it (hs_started_at). <usage_guidance> - For "my conversations", filter with assignedAgentId - Name agents from assignedAgentName, or senderName with messageDetail=FULL, never from message text or signatures - If a name matches several CRM object types, search each - Use KEYWORD when distinctive terms (product names, error codes, jargon) would appear verbatim, even in a loosely phrased question; SEMANTIC for a described situation, a paraphrase, or another language - One focused search is almost always enough: summarize relevant results instead of re-running reworded queries or firing parallel variations. If nothing relevant comes back, say so; an empty search is already retried with the other method - Paginate only with the nextPageAfter a response returns, passed back verbatim as after; never build, increment, or guess a cursor. A response without nextPageAfter is the last page, so stop - For support themes, read a small time-range sample and say it is a sample; aggregation gives volume, not topics - State the dates you used and whether you used a CRM-object lookup or text search </usage_guidance>

search_conversations

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>

search_owners

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>

search_properties

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>

show_feedback_form

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>

submit_feedback

<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>

tool_guidance