Highspot

Purpose: Get AI-powered content recommendations from Highspot based on a search query. Use when users ask for content suggestions, relevant materials, or documents related to a topic. The system returns a list of recommended content items with titles, file names, and a direct Highspot link for each item. Building query_string: A good recommendation depends on a well-formed query_string. It must include (1) the topic or use case and (2) the intended audience or buyer context. If either is missing from the conversation, ask the user before calling this tool. Do not infer or assume a topic from conversational filler. Deal-scoped requests: If the request is scoped to a specific CRM deal and get_deal_answer is available, resolve the deal first (call lookup_deal if no deal has been resolved yet in the conversation), call get_deal_answer, and use its output — including deal stage — to enrich query_string before calling this tool. If get_deal_answer is not available, or the request is not about a specific deal, proceed without it. User triggers: "recommend content," "suggest," "suggest documents," "content for," etc. System notes: Surface the provided item links directly to the user. Never invent links or item IDs.

get_content_recommendations

Purpose: Answer any question about a single specific CRM opportunity using the full Highspot Deal Agent. Read-only. It synthesizes insight and returns an answer with source links, but never creates or modifies anything. Covers deal status, stage, forecast, and next-action recommendations, MEDDPICC / deal-health analysis, stakeholder and risk analysis, deal-level meeting preparation and cross-deal meeting context (not transcript-grounded questions about one selected meeting — those route to get_meeting_answer), and content recommendations tied to deal stage / stakeholder concerns. Use when: The user is asking about ONE specific Salesforce/Dynamics opportunity AND a valid crm_opportunity_id (and crm_org_id) has already been resolved earlier in the conversation (e.g. lookup_deal returned one). Once a deal is resolved, keep reusing that same crm_opportunity_id/crm_org_id for all follow-ups about "this deal," "it," "the account," etc. Do not call lookup_deal again unless the user names a different deal. Routing boundary for meeting-related queries (only applies when lookup_meeting/get_meeting_answer are available in tools/list, gated by mcp_meeting_agent feature flag): - A natural-language reference identifying a meeting, call, or conversation routes to lookup_meeting. - A question about what happened inside one explicit or previously resolved meeting routes to get_meeting_answer. - A reference identifying an opportunity, account, or CRM record routes to lookup_deal. - Questions about opportunity status, health, risk, forecast, or stakeholders route to get_deal_answer, even when meeting activity is mentioned as part of the deal context. Example queries, with correct tool routing: - "What happened in the Acme Corp renewal meeting on August 15th?": lookup_meeting - "What happened in meeting with the ID 1234567890?": get_meeting_answer - "What happened in the renewal meeting for the opportunity with ID 1234567890?": lookup_meeting (lookup_meeting is used because the user is asking about a meeting, not an opportunity, even though the opportunity ID was mentioned) - "What's the status of the Acme Corp renewal opportunity that we discussed in the meeting on August 15th?": lookup_deal - "What's the status of the Acme Corp renewal opportunity that we discussed in the meeting with ID 1234567890?": lookup_deal (lookup_deal is used because the user is asking about an opportunity, not a meeting, even though the meeting ID was mentioned) - "What's the status of the Acme Corp deal with ID 1234567890 that we discussed in the meeting with ID 1234567890?": get_deal_answer (get_deal_answer is used because the user is asking about an opportunity, and provided a specific opportunity ID, even though the meeting ID was also mentioned) Routing: Prefer this tool over get_content_answer whenever the question is scoped to a single deal/opportunity/account. If no deal has been resolved yet in the conversation, call lookup_deal first. If the question is generic Highspot content unrelated to a specific deal, use get_content_answer instead. Multi-turn: a response may include a conversation_token. Passing it back on your next call about the same deal continues that conversation, so the agent remembers the earlier turns. Omitting it is always allowed and always safe: it simply starts a clean conversation with no memory of previous turns, and you never need permission to do so. Start a clean conversation whenever the user disputes or rejects an answer or asks to start over, whenever they bring new information that should be judged on its own, whenever they switch to a different deal or an unrelated line of questioning, and whenever you judge the earlier turns are no longer helping. Conversations also reset on their own after about 2 hours without use, and after roughly 12 hours in total in line with how often the underlying deal data refreshes. That is expected behaviour, not an error. User triggers: "deal," "opportunity," "account," "Salesforce," "CRM," "MEDDPICC," "stakeholders," "next steps," "deal health," "prep for my meeting with [X]," "recommend content," "meeting assessment," and follow-up pronouns referring to a deal already established in the conversation ("what's the status now," "any risks on it").

get_deal_answer

Purpose: Create a Digital Sales Room (DSR) from a selected template and selected content items. Workflow requirement: When user asks to create a digital room, first call get_digital_room_templates, then capture the user-selected template, and finally call this tool with templateId + contentIds + roomName. Do not call this tool until the user has explicitly confirmed they are ready to create the Digital Room (for example, "Yes" after you show a summary of template, content, and room name). A maximum of 50 content items may be included. Do not attempt to add more than 50 items.

generate_digital_room

Purpose: Retrieve Digital Room templates for creating digital sales rooms. Default is recently used templates (top 10 on first call). Pagination: limit defaults to 10, max 20 per request. Use start from the Next page line when Can load more templates is Yes. When template_source is omitted or recently_used: first page (start=0) with no recently used templates falls back to company official templates. Set template_source to official to list only company templates. Response is formatted text including "Can load more templates: Yes/No". When Yes, follow the Next page line exactly (official source responses require template_source=official). Do not use API row counts or sum start/limit/next-page offsets to infer a global total—count only Template ID lines across all pages fetched. Display instruction: Always include the Source line (and fallback Note, if present) when presenting templates to the user. When Source is recently used, tell the user they can also browse company official templates (user can ask for "official templates" or "company templates" - call this tool with template_source=official). Show all templates returned on this page in the list (do not subset or hide entries). Refer users to Template ID, not list position. Never invent template names or IDs not in the tool output. User triggers: "digital room templates," "available templates," "company templates," "templates I used before." Context requirement: Before calling this tool or presenting templates, verify you know what the Digital Room is for (deal stage, buyer profile, or use case) OR that the user asked for a specific Digital Room Template by name. If that context is missing, ask exactly one clarifying question first (e.g. "What kind of scenario is this Digital Room for?"). Do not call this tool until you have enough context to choose relevant templates or the user asked to browse all templates. When a Salesforce/Dynamics deal is already resolved in this conversation (lookup_deal returned crm_opportunity_id and crm_org_id) and you still lack deal stage, buyer profile, or use case context, call get_deal_answer first (reuse the same CRM ids) to gather that context before calling this tool or recommending templates.

get_digital_room_templates

Purpose: Fetch the content-block structure of a specific Digital Room (block ids, friendly names, types, order, and item ids). Each block is labeled with the seller internal name when set, otherwise "Content block N" where N is its position in the returned list (1-based). Technical block names are not returned. Use the label when presenting choices. Use Block ID for update_digital_room_content. Workflow requirement: When the user wants to update a Digital Room, this is step 2—call after get_digital_rooms once the user has chosen a digital_room_id. Present blocks and items, have the user pick a block_id, then call update_digital_room_content (find content in Highspot first when adding new items). User triggers: "update digital room," "what is in this digital room," "show blocks in my DSR." Trigger keywords vary per surface.

get_digital_room_content_blocks

Purpose: List Digital Rooms the user owns or edits. Workflow requirement: When the user wants to update a Digital Room, this is step 1—call this tool first, show the numbered list (local 1..N on each page), and have the user pick a room. Then, call get_digital_room_content_blocks with the Digital Room ID from that row (never use list numbers from other pages as identifiers). Discovery: when the user ties the room to a CRM opportunity or deal, pass deal_id to return only Digital Rooms linked to that deal. Optional has_mutual_action_plan: true = only rooms with a mutual action plan (filtered by the server), false or omit = all rooms. Pagination: use start (default 0) and limit (default 10, max 200). For more results, call again with start equal to the previous start + number of rows returned. User triggers: "update digital room," "change my digital room," "edit DSR content," "digital room for this deal." Trigger keywords vary per surface.

get_digital_rooms

Purpose: Provide a direct answer to a specific question using Highspot content. Use when: Users ask for explanations or guidance or synthesis from Highspot content ("What is…," "How do…," "Why does…," "When should…"). AI synthesizes across content and includes source links. User triggers: "what," "how," "why," "when," "explain," "tell me about." System notes: Answers MUST be grounded in actual Highspot content. Must include clean, readable source links at the end.

get_content_answer

Purpose: Extract readable plain text from a Highspot document for lightweight analysis or summarization. Use when: A caller needs the readable body of a document without binary content. This is the preferred low-cost alternative to fetching raw file content — it returns pre-extracted text regardless of file type (PDF, PPTX, DOCX, etc.). Requires item_id from search_content. Use when: Users need to read or analyze the body of a specific Highspot document — to summarize it, extract key points, or inspect its content directly. User triggers: "what does this doc say", "summarize", "read", "extract", "what's in", "content of", "text from", "pull the document", "show me the document". Do not use for analytical or metrics questions about content performance — route those to get_gtm_insight. Respects item-level access permissions, will error on restricted items.

get_item_content

Purpose: Resolve a CRM opportunity record using opportunity_name, with optional account_name when explicitly provided. Returns the corresponding crm_opportunity_id and the crm_org_id. (Deal = Opportunity). User triggers: None — users will not invoke this directly. System triggers: Invoked internally when a tool (e.g., get_deal_answer) needs to map a natural-language reference ("Acme Corp renewal opportunity") to a CRM opportunity ID. Routing boundary for meeting-related queries (only applies when lookup_meeting/get_meeting_answer are available in tools/list, gated by mcp_meeting_agent feature flag): - A natural-language reference identifying a meeting, call, or conversation routes to lookup_meeting. - A question about what happened inside one explicit or previously resolved meeting routes to get_meeting_answer. - A reference identifying an opportunity, account, or CRM record routes to lookup_deal. - Questions about opportunity status, health, risk, forecast, or stakeholders route to get_deal_answer, even when meeting activity is mentioned as part of the deal context. Example queries, with correct tool routing: - "What happened in the Acme Corp renewal meeting on August 15th?": lookup_meeting - "What happened in meeting with the ID 1234567890?": get_meeting_answer - "What happened in the renewal meeting for the opportunity with ID 1234567890?": lookup_meeting (lookup_meeting is used because the user is asking about a meeting, not an opportunity, even though the opportunity ID was mentioned) - "What's the status of the Acme Corp renewal opportunity that we discussed in the meeting on August 15th?": lookup_deal - "What's the status of the Acme Corp renewal opportunity that we discussed in the meeting with ID 1234567890?": lookup_deal (lookup_deal is used because the user is asking about an opportunity, not a meeting, even though the meeting ID was mentioned) - "What's the status of the Acme Corp deal with ID 1234567890 that we discussed in the meeting with ID 1234567890?": get_deal_answer (get_deal_answer is used because the user is asking about an opportunity, and provided a specific opportunity ID, even though the meeting ID was also mentioned) Input rules: 1. FIRST ATTEMPT MUST USE MINIMAL PROCESSING. a. Allowed cleanup only: i. Trim whitespace. ii. Remove trailing punctuation. iii. Remove trailing "deal/opportunity/record". iv. Remove surrounding quotes. 2. DEAL MAPPING: a. When unsure: i. opportunity_name = full phrase (prefer more text, not less). b. If only a deal/opportunity name is provided, do NOT infer, derive, or pass any account_name from any part of that text. 3. NEVER perform "fancy parsing": a. No splitting into multiple guesses. b. No semantic shortening. c. No interpretation beyond literal structure. 4. OPTIONAL SECOND ATTEMPT: a. If lookup_deal returns no match: i. You may perform ONE simplified retry, using only cleanup that does not extract or infer account_name from opportunity_name. 5. IF STILL NO MATCH: a. I couldn't find a CRM opportunity matching '<deal phrase>'. b. Can you confirm: i. The exact opportunity name (e.g., '2025 Renewal', 'FY25 Expansion') ii. I can try again with updated details.

lookup_deal

Purpose: Resolve a natural-language reference to a past recorded meeting by returning one chronological candidate page for the client model to compare against the user's request. Use for meetings, calls, and conversations — not CRM opportunities, accounts, or deal records (those route to lookup_deal). Routing boundary for meeting-related queries (only applies when lookup_meeting/get_meeting_answer are available in tools/list, gated by mcp_meeting_agent feature flag): - A natural-language reference identifying a meeting, call, or conversation routes to lookup_meeting. - A question about what happened inside one explicit or previously resolved meeting routes to get_meeting_answer. - A reference identifying an opportunity, account, or CRM record routes to lookup_deal. - Questions about opportunity status, health, risk, forecast, or stakeholders route to get_deal_answer, even when meeting activity is mentioned as part of the deal context. Example queries, with correct tool routing: - "What happened in the Acme Corp renewal meeting on August 15th?": lookup_meeting - "What happened in meeting with the ID 1234567890?": get_meeting_answer - "What happened in the renewal meeting for the opportunity with ID 1234567890?": lookup_meeting (lookup_meeting is used because the user is asking about a meeting, not an opportunity, even though the opportunity ID was mentioned) - "What's the status of the Acme Corp renewal opportunity that we discussed in the meeting on August 15th?": lookup_deal - "What's the status of the Acme Corp renewal opportunity that we discussed in the meeting with ID 1234567890?": lookup_deal (lookup_deal is used because the user is asking about an opportunity, not a meeting, even though the meeting ID was mentioned) - "What's the status of the Acme Corp deal with ID 1234567890 that we discussed in the meeting with ID 1234567890?": get_deal_answer (get_deal_answer is used because the user is asking about an opportunity, and provided a specific opportunity ID, even though the meeting ID was also mentioned) Routing: - A natural-language reference identifying a meeting, call, or conversation routes here. - When the user already provides an explicit Meeting ID, or a meeting was previously resolved in this conversation, call get_meeting_answer directly with that Meeting ID instead of lookup_meeting. - Questions about opportunity status, health, risk, forecast, or stakeholders route to get_deal_answer even when meeting activity is mentioned as deal context. Lookup inputs: - query must contain the user's original natural-language meeting reference. It is shown in candidate-page context and used for logging and usage telemetry, but it does not filter candidates. - Set name_query only when the request identifies likely meeting-title text, such as an account, opportunity, or explicit title. Extract concise keywords, drop question framing and generic words such as "meeting", "call", or "what happened", and do not add Solr quotes. Omit name_query for participant-only or date-only references. - Set date_range only when the request contains a date or time constraint. Resolve relative dates such as "last Tuesday" into inclusive start and end boundaries using the user's IANA time zone, convert both boundaries to UTC, and pass ISO 8601 values ending in Z. Do not guess a time zone. Ask the user or omit date_range when it cannot be resolved reliably. - name_query and date_range are optional. When both are present, candidates must match both filters. When neither is present, lookup returns the existing unfiltered chronological page for client-side comparison. Behavior: - Returns one page of recorded past meetings matching any supplied structured filters, in reverse chronological order. You (the client) must show this page to the user, and allow them to select the meeting which matches their request. - Show exactly one returned page to the user and wait for the user before continuing. Never auto-select a candidate or auto-advance to the next page. - Page numbers are display-only. Always use Meeting ID for follow-up tool calls, not page-local numbering. - Reuse a resolved Meeting ID for follow-up questions about the same meeting. Pagination: - For "none of those," "keep looking," or "show more," call lookup_meeting again with the exact same query, name_query, and date_range values, and set start to the returned next_start value. - When the user refines or changes their meeting constraints, reset start to 0 and derive query, name_query, and date_range again from the updated request.

lookup_meeting