HubSpot

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.

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

manage_onboarding

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

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>

manage_campaign_objects

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.

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

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 ranges: BETWEEN with date strings (e.g. '2025-01-01'), not timestamps. "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

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.

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

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

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