diff --git a/modules/ROOT/pages/ai-integration-options.adoc b/modules/ROOT/pages/ai-integration-options.adoc new file mode 100644 index 000000000..5e67530b7 --- /dev/null +++ b/modules/ROOT/pages/ai-integration-options.adoc @@ -0,0 +1,61 @@ += ThoughtSpot AI analytics integration +:toc: true +:toclevels: 3 + +:page-title: AI integration options +:page-pageid: ai-analytics-integration +:page-description: Learn the different ways to integrate ThoughtSpot analytics and AI experiences into your applications and AI agents, including MCP Server, Spotter Embed, and Spotter APIs. + +ThoughtSpot provides several options to bring governed analytics and AI-powered experiences into your applications, AI agents, and workflows. + +== AI integration options + +The primary ways to integrate ThoughtSpot analytics and AI into your environment are: + +* xref:ai-integration-options.adoc#_thoughtspot_mcp_server[ThoughtSpot Model Context Protocol (MCP) Server] +* xref:ai-integration-options.adoc#_embedding_spotter_in_your_app[Embedding Spotter in your app] +* xref:ai-integration-options.adoc#_spotter_rest_apis[Spotter REST APIs] + +[NOTE] +==== +All options allow using your existing ThoughtSpot data models, Liveboards, Answers, row-level and column-level security, and governance. The main differences are where the UI or conversation layer exists and who orchestrates the analytics workflow. +==== + +=== ThoughtSpot MCP Server + +ThoughtSpot xref:mcp-integration.adoc[MCP Server] exposes governed analytics as MCP tools and resources to AI agents and clients. The MCP Server can be integrated with your MCP client, agent, LLM, or application UI, allowing your users to explore ThoughtSpot's agentic capabilities within the context of your application. + +ThoughtSpot recommends using the MCP Server in these scenarios: + +* When you want to plug ThoughtSpot into AI agents and clients that already support MCP, such as Claude, ChatGPT, Gemini, IDEs, and custom MCP clients. +* If you are building your own MCP-based chatbot or application, and want to call ThoughtSpot MCP tools behind a custom web experience. + +For more information, see the xref:mcp-integration.adoc[MCP Server] documentation. + +=== Embedding Spotter in your app + +Developers can embed ThoughtSpot's xref:embed-spotter.adoc[conversational UI experience and its agentic capabilities] directly into their applications using the Visual Embed SDK. + +If your business requires you to quickly integrate the Spotter experience into your applications and workflows, and provide a native AI search and analysis experience within your app, use this option. + +For more information, see the xref:embed-ai-analytics.adoc[Embed AI Search and Analytics] and xref:embed-spotter.adoc[Spotter embed] documentation. + +=== Spotter REST APIs + +Spotter REST APIs provide programmatic access to Spotter conversation sessions, analytics, and agentic workflows. REST API clients use these APIs to send questions and receive structured answers, charts, or get relevant questions for a specific data model. + +ThoughtSpot recommends using Spotter REST APIs in the following scenarios: + +* When you want your application, agent, or orchestration logic to interact with ThoughtSpot programmatically, without requiring MCP. +* If you need to integrate ThoughtSpot responses and workflows with other systems. +* For fine-grained control over the user experience. + +//* For fine-grained control over data context, query options, and prompt structure, and . + +For more information, see the xref:spotter-apis.adoc[Spotter AI API] documentation. + +== Additional resources + +* For information about MCP, see the link:https://modelcontextprotocol.io[Model Context Protocol specification, window=_blank]. +* For information about SDK libraries for embedding, see the link:https://github.com/thoughtspot/visual-embed-sdk[Visual Embed SDK GitHub repository, window=_blank]. +* To view Spotter APIs, visit the +++REST API v2.0 Playground+++ and navigate to the **AI** section. diff --git a/modules/ROOT/pages/api-changelog.adoc b/modules/ROOT/pages/api-changelog.adoc index 4d405eb7b..0e0cccee8 100644 --- a/modules/ROOT/pages/api-changelog.adoc +++ b/modules/ROOT/pages/api-changelog.adoc @@ -66,9 +66,9 @@ Use this enhanced configuration to override ThoughtSpot URLs on hover or when op [width="100%" cols="1,4"] |==== -|[tag greenBackground]#NEW FEATURE# a|**Spotter enhancements ** +|[tag greenBackground]#NEW FEATURE# a| **Spotter enhancements** -You can now embed the Spotter 3 experience in your application and use features such as Auto mode for automatic data model selection, Chat history, and a new chat prompt interface. +You can now embed the Spotter 3 experience in your application and use features such as Auto mode for automatic data model selection, chat history, and a new chat prompt interface. * To enable the new chat prompt interface, set `updatedSpotterChatPrompt` to `true`. * To use Auto mode, set the `worksheetId` to `auto_mode`. @@ -91,7 +91,7 @@ On Spotter embed deployments running version 26.2.0.cl or later, the *Add to Coa Styling and grouping:: -* The `isLiveboardStylingAndGrouping` attribute, used for enabling the Liveboard styling and grouping feature, is now replaced with `isLiveboardMasterpiecesEnabled`. While your existing configuration with the deprecated attribute, `isLiveboardStylingAndGrouping` continues to work, we recommend switching to the new configuration setting. +* The `isLiveboardStylingAndGrouping` attribute, used to enable the Liveboard styling and grouping feature, is now replaced with `isLiveboardMasterpiecesEnabled`. While your existing configuration with the deprecated `isLiveboardStylingAndGrouping` attribute continues to work, we recommend switching to the new configuration setting. * The following action IDs are now available to show, disable, or hide the grouping menu actions on a Liveboard: ** `Action.MoveToGroup` for the **Move to Group** menu action. ** `Action.MoveOutOfGroup` for the **Move out of Group** menu action. @@ -105,21 +105,21 @@ For more information, see link:https://docs.thoughtspot.com/cloud/latest/securit + The `showMaskedFilterChip` setting is also available in full application embedding. -|[tag greenBackground]#NEW FEATURE# a|**Publishing objects** +|[tag greenBackground]#NEW FEATURE# a| **Publishing objects** The following action IDs are available for the data publishing menu actions in the *Data workspace* page: * `Action.Publish` for *Publish* -* `Action.ManagePublishing` for *Manange publishing* -* `Action.Unpublish` foe *Unpublish* +* `Action.ManagePublishing` for *Manage publishing* +* `Action.Unpublish` for *Unpublish* * `Action.Parameterize` for *Parameterize* |[tag greenBackground]#NEW FEATURE# a| **Error handling improvements** To handle errors in the embedding workflows, the SDK includes the following features: -* `ErrorDetailsTypes` enum for categorizing error types, such as `API`, `VALIDATION_ERROR`, `NETWORK` error. -* `EmbedErrorCodes` enum with specific error codes for programmatic error handling -* `EmbedErrorDetailsEvent` interface for structured error event handling +* `ErrorDetailsTypes` enum for categorizing error types, such as `API`, `VALIDATION_ERROR`, and `NETWORK`. +* `EmbedErrorCodes` enum with specific error codes for programmatic error handling. +* `EmbedErrorDetailsEvent` interface for structured error event handling. For more information, see link:https://developers.thoughtspot.com/docs/Enumeration_EmbedErrorCodes[EmbedErrorCodes] and link:https://developers.thoughtspot.com/docs/Enumeration_ErrorDetailsTypes[ErrorDetailsTypes]. |==== @@ -129,7 +129,7 @@ For more information, see link:https://developers.thoughtspot.com/docs/Enumerati [width="100%" cols="1,4"] |==== -|[tag redBackground]#DEPRECATED# | ** Use `minimumHeight` instead of `defaultHeight` ** + +|[tag redBackground]#DEPRECATED# | **Use `minimumHeight` instead of `defaultHeight`** + The `defaultHeight` parameter is deprecated in Visual Embed SDK v1.44.2 and later. To set the minimum height of the embed container for ThoughtSpot components such as a Liveboard, use the `minimumHeight` attribute instead. @@ -144,7 +144,7 @@ Allows configuring which API calls to intercept. * `interceptTimeout` + Sets the timeout duration for handling interception. * `isOnBeforeGetVizDataInterceptEnabled` + -When set to true, it enables the use of `EmbedEvent.OnBeforeGetVizDataIntercept` event to emit and intercept search execution calls initiated by the users and implement custom logic or workflow to allow or restrict search execution. +When set to true, it enables use of `EmbedEvent.OnBeforeGetVizDataIntercept` to emit and intercept search execution calls initiated by users and implement custom logic or workflows to allow or restrict search execution. * `EmbedEvent.ApiIntercept` + Emits when an API call matching the conditions defined in `interceptUrls` is detected. @@ -157,7 +157,7 @@ For more information, see xref:api-intercept.adoc[Intercept API calls and search |==== |[tag greenBackground]#NEW FEATURE# a| *Code-based custom actions* -The following enumerations are available for code based custom actions: +The following enumerations are available for code-based custom actions: * `CustomActionTarget` + To define the target object for the custom action, such as on a Liveboard, visualization, Answer, or in Spotter. diff --git a/modules/ROOT/pages/common/nav.adoc b/modules/ROOT/pages/common/nav.adoc index e8301160f..b3bd8d0ee 100644 --- a/modules/ROOT/pages/common/nav.adoc +++ b/modules/ROOT/pages/common/nav.adoc @@ -219,7 +219,10 @@ include::generated/typedoc/CustomSideNav.adoc[] ** link:{{navprefix}}/SpotterCode[SpotterCode for IDEs] *** link:{{navprefix}}/integrate-SpotterCode[Integrating SpotterCode] *** link:{{navprefix}}/spottercode-prompting-guide[SpotterCode prompting guide] -** link:{{navprefix}}/mcp-integration[ThoughtSpot MCP server] +** link:{{navprefix}}/ai-analytics-integration[ThoughtSpot AI analytics integration] +*** link:{{navprefix}}/mcp-integration[ThoughtSpot MCP server] +*** link:{{navprefix}}/connect-mcp-server-to-clients[Connecting MCP Server to MCP clients] +*** link:{{navprefix}}/custom-chatbot-integration-mcp[Integrating MCP Server in a custom application or chatbot] * link:{{navprefix}}/development-and-deployment[Deployment and integration] ** link:{{navprefix}}/development-and-deployment[Development and deployment] diff --git a/modules/ROOT/pages/embed-events.adoc b/modules/ROOT/pages/embed-events.adoc index ba6616f20..b138f13ad 100644 --- a/modules/ROOT/pages/embed-events.adoc +++ b/modules/ROOT/pages/embed-events.adoc @@ -15,9 +15,11 @@ The SDK library includes the following event objects: [#embed-events] == Embed events -Developers can register event listeners to listen to application actions such as component loading or user interactions with the embedded component and fire events. Embed events are emitted by the embedded ThoughtSpot components and are part of the `EmbedEvent` object. +Embed events in the ThoughtSpot Visual Embed SDK are the events that the embedded component emits to the host application when application events such as loading, rendering, user interactions, or errors occur inside the embed. Developers can register listeners for these events and emit these events to the host application. -=== Register event listeners +Embed events are part of the `EmbedEvent` object and are identified as the members of the `EmbedEvent` enumeration. + +=== Registering event listeners To register event listeners, import the `EmbedEvent` library into your application setup. @@ -36,13 +38,13 @@ In the following example, the `EmbedEvent.Edit` is emitted and logged in the con [source,JavaScript] ---- liveboardEmbed.on(EmbedEvent.Edit, payload => { - console.log(`Liveboard edit', payload); + console.log('Liveboard edit', payload); }) ---- -=== Start and end specification +=== Specifying start and end -For some actions and events, you can register listeners to emit events when an action starts and ends. In this example, the `EmbedEvent.DownloadAsPdf` is emitted when the `DownloadAsPdf` starts and after the download is completed: +For some actions and events, you can register listeners to emit events when an action starts and ends. In this example, the `EmbedEvent.DownloadAsPdf` is emitted when `DownloadAsPdf` starts and after the download is completed: [source,JavaScript] ---- @@ -59,12 +61,12 @@ For some actions and events, you can register listeners to emit events when an a ---- [#use-cases] -=== Common Use cases +=== Common use cases Embed events can be used to trigger a specific response when the event is emitted, handle load and errors for embedded components, or modify a behavior in the embedded view. -==== Handle event response for embedded components +==== Handling event response for embedded components -To handle event response when the event emits, you can add a callback function. +To handle event response, you can add a callback function. In this example, a callback function is added to show the loader when the embedded Liveboard initializes: @@ -89,11 +91,11 @@ In this example, the `HostEvent.SetVisibleVizs` is triggered to set the visualiz }); ---- -==== Handle load and errors for embedded components +==== Handling load and errors for embedded components A common workflow is to use an overlay `div` element to hide the embed content until you know that SSO is completed, and the content is fully loaded. If an error occurs in the process, you may prefer to display your own custom message to the end user rather than showing embedded ThoughtSpot content in an error state. -Embed events fire at different points within the loading process. The following events are related to the load process: +Embed events fire at different points within the loading process. The following events are related to the load, initialization, and authentication process: . `Init` + Fires at the beginning of the loading process. @@ -103,8 +105,11 @@ Some browsers (Safari in particular) default to strict settings on cookie origin Fires if SSO does not complete and if the ThoughtSpot session times out at some point. Listen to the `AuthExpire` event in the load process to determine when it is safe to show the ThoughtSpot content and listen to it after loading to hide the ThoughtSpot login screen if the session expires for some reason. . `AuthInit` + Fires when the SSO process is completed correctly. The event does not fire when an SSO process fails. The logged-in user GUID is available in the `AuthInit` event response. ++ +[#errorType] . `Error` + -Fires when an error occurs in the embedded app. For information about error types, see xref:embed-events.adoc#errorType[Error types]. +Fires when an error occurs in the embedded app. + . `Load` + Fires as soon as the area for embedding is created, not when the content has begun or finished loading. . `LiveboardRendered` + @@ -146,8 +151,7 @@ embed .render() ---- -[#errorType] -===== Error types +==== Identifying and logging errors The `EmbedEvent.Error` is fired when the following types of errors occur. @@ -163,7 +167,7 @@ SearchEmbed.on(EmbedEvent.Error, (error) => { ---- * `FULLSCREEN` + -Error in presenting a Liveboard or visualization in the full screen mode. +Error in presenting a Liveboard or visualization in full-screen mode. + [source,JavaScript] @@ -177,7 +181,7 @@ LiveboardEmbed.on(EmbedEvent.Error, (error) => { ---- * `SINGLE_VALUE_FILTER` + -Error in updating filter values. This error occurs when a single value filter is applied on a Liveboard and the user tries to update this filter with multiple values. +Error in updating filter values. This error occurs when a single-value filter is applied on a Liveboard and the user tries to update this filter with multiple values. + [source,JavaScript] ---- @@ -203,7 +207,7 @@ LiveboardEmbed.on(EmbedEvent.Error, (error) => { ---- * `INVALID_DATE_VALUE` + -Error due to invalid date value in a filter. For example, if the column name is `Commit Date` and a correct date value is not specified, the `INVALID_DATE_VALUE` error event is fired. +Error due to an invalid date value in a filter. For example, if the column name is `Commit Date` and a correct date value is not specified, the `INVALID_DATE_VALUE` error event is fired. + [source,JavaScript] ---- @@ -228,12 +232,13 @@ LiveboardEmbed.on(EmbedEvent.Error, (error) => { }) ---- -==== Modify a behavior -Embed events can also be used to modify a specific behavior in the embedded app. For example, the `hideResults` parameter in the `SearchEmbed` constructor blocks the *GO* button from displaying the chart or table results. When this attribute is set to *true*, you can listen to the `QueryChanged` event to perform actions based on the user's interaction within the `SearchEmbed` component. +To identify and log errors, use the error types and error codes. For more information, see xref:EmbedErrorDetailsEvent.adoc[EmbedErrorDetailsEvent]. +=== Modifying default behavior +Embed events can also be used to modify a specific behavior in the embedded app. For example, the `hideResults` parameter in the `SearchEmbed` constructor blocks the *GO* button from displaying the chart or table results. When this attribute is set to *true*, you can listen to the `QueryChanged` event to perform actions based on the user's interaction within the `SearchEmbed` component. [#customAction] -==== Handle custom action events +==== Handling custom action events If you have added a xref:customize-actions-menu.adoc[custom action] set as a xref:custom-actions-callback.adoc[callback action], you must register an event handler to send data in a payload when the custom action is triggered: @@ -252,14 +257,15 @@ searchEmbed.on(EmbedEvent.customAction, payload => { liveboardEmbed.on(EmbedEvent.CustomAction, (payload) => { if (payload.data.id === 'show-data') { const showActionId = 'show-data'; - if (payload.id === showActionId \|\| payload.data.id === showActionId) { + if (payload.id === showActionId || payload.data.id === showActionId) { showData(payload); } - }) + } +}) ---- -=== Event configuration for React components -If you are using React components to embed, you can register to any `EmbedEvent` by using the `on` convention, for example,`onAlert`, `onCopyToClipboard`. +=== Event configuration for React embed components +If you are using React components to embed, you can register for any `EmbedEvent` by using the `on` convention, for example,`onAlert`, `onCopyToClipboard`. To trigger events on ThoughtSpot components embedded in a React app, import the `useEmbedRef` hook. @@ -282,7 +288,7 @@ const MyComponent = ({ dataSources }) => { }; ---- -=== Try out in Playground +=== Try it out in the Visual Embed Playground Try out the embed events in the +++< a href="{{previewPrefix}}/playground/liveboard"> Visual Embed Playground +++ and preview changes. [.widthAuto] @@ -294,75 +300,55 @@ For information about the supported event objects and examples, see xref:EmbedEv [#host-events] == Host events +Host events provide programmatic entry points to actions that your host or embedding application can trigger into the embedded ThoughtSpot iframe to perform the same operations a user can perform in the UI, such as opening filters, editing, saving, pinning, drilling, or navigating to an answer. -Host events are triggered by the host application in which ThoughtSpot components are embedded. Host events use the `.trigger()` method to send the event message to embedded ThoughtSpot components in the `.trigger(hostEvent, data)` format. The host events are part of the *HostEvent* object; for example, `HostEvent.SetVisibleVizs`. - -=== Register event listeners -To configure host events, import the `HostEvent` library into your application setup. - -[source,JavaScript] ----- -import { - //... - HostEvent -} from "@thoughtspot/visual-embed-sdk"; ----- +Host events use the `.trigger()` method to send the event message to embedded ThoughtSpot components in the `.trigger(hostEvent, data)` format. The host events are part of the *HostEvent* object; for example, `HostEvent.SetVisibleTabs`. -In the following example, the `HostEvent.SetVisibleTabs` triggers an action to display the tabs specified in the code on an embedded Liveboard. +=== Event categories -[source,JavaScript] ----- -liveboardEmbed.trigger(HostEvent.SetVisibleTabs, [ - '430496d6-6903-4601-937e-2c691821af3c', - 'f547ec54-2a37-4516-a222-2b06719af726']) ----- +Host events can be categorized based on their schema and what they do: -=== Event trigger and actions -Host events can be assigned to a custom button or action, on clicking which the event is triggered and initiates the specified action. +* Navigation events that can move the user to a different object or change what’s visible in their current view. For example, `HostEvent.SetVisibleTabs`, `HostEvent.Explore`. +* Filter events that can get, open, and update filters programmatically without relying on the user to open filter panels. For example, `HostEvent.UpdateRuntimeFilters`, `HostEvent.GetFilters`, `HostEvent.OpenFilter`. +* Query control events that can control the search string, prompt, or query that ThoughtSpot runs, instead of relying on the user to type or edit it in the UI. For example, `HostEvent.Search`, `HostEvent.EditLastPrompt`. +* Object creation and management events that trigger actions such as save, pin, copy, edit, present, delete, and more, either by opening a UI modal or executing directly via parameters. For example, `HostEvent.Pin`, `HostEvent.SaveAnswer`, `HostEvent.Present`. +* Data retrieval events that return information about the current state or objects, such as a Liveboard tab, answer session. This information can be sent as the response payload to the host application to drive custom workflows. For example, `HostEvent.GetTabs`, `HostEvent.GetAnswerSession`. `HostEvent.GetIframeUrl`. +* Other utility events that trigger workflows, such as `HostEvent.EditTML`, and `HostEvent.ExportTML` in the embed view. -xref:runtime-filters.adoc[Runtime filters] can be set programmatically before loading the embedded ThoughtSpot content. Runtime filters can also be updated after the load time using `HostEvent.UpdateRuntimeFilters`. You can add a UI option or button in your embedding app and assign the `HostEvent.UpdateRuntimeFilters` to trigger the `UpdateRuntimeFilters` event when that button is clicked. +=== Configuring host events +To configure a host event, use the `.trigger()`. -In this example, the host event is assigned to a button that updates runtime filters. When a user clicks this button, the `HostEvent.UpdateRuntimeFilters` is triggered and an action is initiated to update the filters with the attributes specified in the code. +The following example uses `HostEvent.SetVisibleTabs` to show specific tabs whose IDs are specified in the payload. Any tabs whose IDs are not included in this array are hidden. -[source,JavaScript] ----- - document.getElementById('updateFilters').addEventListener('click', e => { - liveboardEmbed.trigger(HostEvent.UpdateRuntimeFilters, [{ - columnName: "state", - operator: RuntimeFilterOp.EQ, - values: ["michigan"] - }, - { - columnName: "item type", - operator: RuntimeFilterOp.EQ, - values: ["Jackets"] - } - ]); - }); +[source,TypeScript] ---- +import { HostEvent } from '@thoughtspot/visual-embed-sdk'; -==== Filter from selection -Filtering from a selection on a chart or table can be implemented by combining the `EmbedEvent.VizPointClick` or `EmbedEvent.VizPointDoubleClick` events with the `HostEvent.UpdateRuntimeFilters` event. +// Example: show only specific tabs on a Liveboard +liveboardEmbed.trigger(HostEvent.SetVisibleTabs, [ + '430496d6-6903-4601-937e-2c691821af3c', + 'f547ec54-2a37-4516-a222-2b06719af726', +]); +---- -The callback function from the `VizPointClick` event will need to read the response, parse out the attributes from the response that will be sent to the Runtime Filters object, and then send the attributes and their target fields in the format used by `UpdateRuntimeFilters`. +When a host event is triggered, an event bridge inside the embed receives the event, finds matching handlers, and executes the action specified in the host event payload. Host events can also be assigned to a Call To Action (CTA) button or menu action in ThoughtSpot UI or a custom button to initiate the specified action. [#hostEventParameterization] -=== Trigger events and complete actions without modals +==== Using parameterized events to trigger actions without opening a UI modal +In your host events implementation, you can choose to trigger an action without a payload and let ThoughtSpot run the standard UI workflow, such as opening a modal or using the current selection. For events such as `HostEvent.Pin` and `HostEvent.SaveAnswer`, you can also pre-define the `vizId`, `liveboardId`, and `tabId` parameter values in the host event payload and trigger actions directly without relying on the UI workflow or modal. -To provide an uninterrupted experience for workflows such as pinning an Answer to a Liveboard or saving a search result as an Answer, you can pre-define parameter values in host event objects and trigger actions directly. For `HostEvent.Pin` and `HostEvent.SaveAnswer`, the SDK provides the option to define a set of parameters to complete the *Pin* or *Save* action without opening a modal or showing a prompt for user's input. +===== Parameters for HostEvent.Pin -==== Parameters for HostEvent.Pin +The *Pin* action is available on the charts and tables generated from a search query, saved Answers, and visualizations on a Liveboard. Generally, when a user initiates the pin action, the *Pin to Liveboard* modal opens, and the user is prompted to specify the Liveboard to pin the object. The modal also allows the user to add or edit the title text of the visualization and create a new Liveboard if required. -The *Pin* action is available on the charts and tables generated from a search query, saved Answers, and visualizations on a Liveboard. Generally, when a user initiates the pin action, the *Pin to Liveboard* modal opens and the user is prompted to specify the Liveboard to pin the object. The modal also allows the user to add or edit the title text of the visualization and create a new Liveboard if required. - -With `HostEvent.Pin`, you can automate the pin workflow to programmatically add an Answer or visualization to a Liveboard. For example, to pin an object to an existing Liveboard, use the following parameters to the host event object: +With `HostEvent.Pin`, you can automate the pin workflow to programmatically add an Answer or visualization to a Liveboard. For example, to pin an object to an existing Liveboard, use the following parameters in the host event object: * `vizId` + __String__. GUID of the saved Answer or visualization to pin to a Liveboard. Note that after you pin an Answer to a Liveboard, ThoughtSpot creates a copy of the Answer with a new GUID, which is independent of the original Answer object. Optional for pinning a new chart or table generated from a Search query. * `liveboardId` + __String__. GUID of the Liveboard to pin the Answer. If there is no Liveboard, you must specify the `newLiveboardName` to create a new Liveboard. * `newVizName` + -__String__. Name string for the Answer that will be added as visualization to the Liveboard. Note that each time the user clicks, a new visualization object with a new GUID is generated. +__String__. Name string for the Answer that will be added as a visualization to the Liveboard. Note that each time the user clicks, a new visualization object with a new GUID is generated. * `tabId` + __String__. GUID of the Liveboard tab. Adds the Answer to the Liveboard tab specified in the code. * `newLiveboardName` @@ -394,7 +380,7 @@ In this example, when the `HostEvent.Pin` is triggered, the *Pin* action is init }) ---- -In this example, when the `HostEvent.Pin` is triggered, the *Pin* action is initiated to create a new Liveboard with a tab and then pin the Answer or visualization to it. +In this example, when the `HostEvent.Pin` is triggered, the *Pin* action is initiated to create a new Liveboard with a tab, and then pin the Answer or visualization to it. [source,JavaScript] ---- @@ -405,41 +391,99 @@ In this example, when the `HostEvent.Pin` is triggered, the *Pin* action is init }) ---- -If no parameters are defined in the `HostEvent.Pin` object, the event triggers the *Pin* action and opens the *Pin to Liveboard* modal. +If `HostEvent.Pin` does not include any parameters, the event triggers the *Pin* action and opens the *Pin to Liveboard* modal. [source,JavaScript] ---- searchEmbed.trigger(HostEvent.Pin); ---- -==== Parameters for HostEvent.SaveAnswer +===== Parameters for HostEvent.SaveAnswer -For `HostEvent.SaveAnswer`, you can pass the pre-defined attributes such as name and description of the Answer to save the Answer programmatically without showing the *Describe your Answer* prompt to user. +For `HostEvent.SaveAnswer`, you can pass the pre-defined attributes such as name and description of the Answer to save the Answer programmatically without showing the *Describe your Answer* prompt to the user. * `name` + __String__. Name string for the Answer object. * `description` + __String__. Description text for the Answer - [source,JavaScript] ---- const saveAnswerResponse = await searchEmbed.trigger(HostEvent.SaveAnswer, { name: "Sales by states", - description: "Total sales by states in MidWest", + description: "Total sales by states in the Midwest region", }); ---- -If no parameters are defined in the `HostEvent.SaveAnswer` object, the event triggers the save action and opens the *Describe your Answer* modal. +If `HostEvent.SaveAnswer` does not include any parameters, the event triggers the *Save* action and opens the *Describe your Answer* modal. [source,JavaScript] ---- searchEmbed.trigger(HostEvent.SaveAnswer); ---- -=== Event configuration for React components +==== Using vizId to target a specific visualization +If a host event allows the `vizId` parameter, you can use it to target a specific visualization. For example, to trigger the *Edit* action on a specific visualization in an embedded Liveboard, you can specify the `vizId` parameter in the host event payload. + +In the following example, the host event triggers the **Edit** action on the specified visualization in a Liveboard embed: + +[source,JavaScript] +---- +// Import the HostEvent enum +import { HostEvent } from '@thoughtspot/visual-embed-sdk'; + +// Trigger the 'Edit' action on a specific visualization within the embedded Liveboard. +liveboardEmbed.trigger(HostEvent.Edit, { + vizId: '730496d6-6903-4601-937e-2c691821af3c' // The GUID of the visualization to edit. +}); +---- + +If `vizId` is not specified, the edit action is triggered at the Liveboard level, instead of the visualization layer. + +In Spotter embed, `vizId` is a required parameter for several host events. If it is not specified in the host event, the event execution fails and results in an error. + +===== Visibility of visualizations in the viewport +In a Liveboard embed, visualizations load incrementally as the user scrolls the Liveboard. Even if the Liveboard view is configured to load all visualizations simultaneously, the host events are triggered only on visualizations that are currently loaded and visible in the viewport. + +In the above example, if the visualization with the `730496d6-6903-4601-937e-2c691821af3c` `vizId` is not currently loaded and visible on the user’s screen, the host event will not trigger any action, indicating that the `vizId` is unknown or not currently loaded. + +==== Retrieving and updating filters + +The SDK provides the following events for filter retrieval and updates: + +* `HostEvent.GetFilters` to get the filters that are currently applied on an embedded Liveboard. You can use this event to inspect the current filter state or to retrieve filter values. +* `HostEvent.UpdateFilters` to update the filters applied on an embedded Liveboard. +* `HostEvent.OpenFilter` to open the filter panel for the specified column. +* `HostEvent.UpdateRuntimeFilters` to update xref:runtime-filters.adoc[Runtime filters]. + +Runtime filters are applied at runtime, that is, when loading the embedded ThoughtSpot content. Runtime filters can also be updated after the load time using `HostEvent.UpdateRuntimeFilters`. You can add a UI option or button in your embedding app and assign the `HostEvent.UpdateRuntimeFilters` to trigger the `UpdateRuntimeFilters` event when that button is clicked. ++ +In this example, the host event is assigned to a button that updates runtime filters when clicked. When `HostEvent.UpdateRuntimeFilters` is triggered, the filters are updated with the attributes specified in the code. ++ +[source,JavaScript] +---- + document.getElementById('updateFilters').addEventListener('click', e => { + liveboardEmbed.trigger(HostEvent.UpdateRuntimeFilters, [{ + columnName: "state", + operator: RuntimeFilterOp.EQ, + values: ["michigan"] + }, + { + columnName: "item type", + operator: RuntimeFilterOp.EQ, + values: ["Jackets"] + } + ]); + }); +---- + +==== Filtering from the selection +Filtering from a selection on a chart or table can be implemented by combining the `EmbedEvent.VizPointClick` or `EmbedEvent.VizPointDoubleClick` events with the `HostEvent.UpdateRuntimeFilters` event. + +The callback function from the `VizPointClick` event will need to read the response, parse out the attributes from the response that will be sent to the Runtime Filters object, and then send the attributes and their target fields in the format used by `UpdateRuntimeFilters`. -To trigger events on ThoughtSpot components embedded in a React app, use the `useEmbedRef` hook and set the ref to `embedRef` constructor prop with `.trigger` method. +=== Configuring host events for React components + +To trigger events on ThoughtSpot components embedded in a React app, use the `useEmbedRef` hook and set the ref to `embedRef` constructor prop with the `.trigger` method. [source,TypeScript] ---- @@ -463,7 +507,7 @@ const resetFilter = () => { }; ---- -=== Try out in Playground +=== Try it out in the Visual Embed Playground To explore the host event functionality in the Playground, follow these steps: @@ -475,7 +519,7 @@ To explore the host event functionality in the Playground, follow these steps: [source,JavaScript] ---- document.getElementById('tryBtn').addEventListener('click', e => { - embed.trigger((HostEvent.DownloadAsPng) + embed.trigger(HostEvent.DownloadAsPng) }); ---- * Click *Run*. @@ -496,7 +540,6 @@ video::./images/hostEvent.mp4[width=100%,options="autoplay,loop"] === Event enumerations and examples For information about the supported event objects and examples, see xref:HostEvent.adoc[HostEvent]. - //// Verify the text for accuracy. QueryChanged can be fired on SageEmbed and SpotterEmbed as well. diff --git a/modules/ROOT/pages/mcp-connect-custom-chatbot.adoc b/modules/ROOT/pages/mcp-connect-custom-chatbot.adoc new file mode 100644 index 000000000..fdf83129c --- /dev/null +++ b/modules/ROOT/pages/mcp-connect-custom-chatbot.adoc @@ -0,0 +1,355 @@ += Integrating MCP Server in a custom application or chatbot +:toc: true +:toclevels: 3 + +:page-title: Integrating MCP Server in a custom application or chatbot +:page-pageid: custom-chatbot-integration-mcp +:page-description: Learn how to build custom applications and chatbots that use ThoughtSpot MCP Server. + +If you are building a chatbot client with your own agent and orchestration logic, you can use the MCP Server to call MCP tools behind a custom web experience and integrate it with other systems or services as needed. + +When integrated, the agent in your custom application can: + +* Automatically discover ThoughtSpot MCP tools. +* Support natural language conversation sessions for data questions. +* Generate embeddable visualizations and programmatically create a Liveboard. + +[IMPORTANT] +==== +Currently, the MCP Server integration does not support link:https://docs.thoughtspot.com/cloud/latest/spotter-versions[Spotter 3 capabilities]. +==== + +== Before you begin +Before you begin, review the following prerequisites: + +* Node.js version 22 or later is installed and available in your environment. +* Ensure that your setup has access to a ThoughtSpot application instance with 10.11.0.cl or a later release version. +* Ensure that the users have the necessary permissions to view data from relevant models and tables in ThoughtSpot. Existing RLS/CLS rules on tables are enforced automatically in data source responses. To create charts or Liveboards from a conversation session, data download and content creation privileges are required. + +== Authenticating users +If your own application or backend service manages user identities, and you want to implement a seamless authentication experience without redirecting users to an external OAuth flow from the chatbot host, use the trusted authentication method. + +=== Trusted authentication flow +In a typical trusted authentication flow, your backend service calls the `/api/rest/2.0/auth/token/full` REST API endpoint to obtain a full access token (`TS_AUTH_TOKEN`) for a ThoughtSpot user or service account. + +The token generated for the user session is used as a bearer token when your backend calls ThoughtSpot APIs or when it brokers MCP tool calls. + +== Connecting clients +If your custom chatbot implementation uses Claude, OpenAI, or Gemini LLM APIs to call MCP tools, ensure that your MCP Server endpoint, authentication token, and ThoughtSpot host are included in the API request. + +=== Claude MCP connector +If your application uses Claude MCP connector, use the following API request format to connect Claude to the MCP Server: + +[source,bash] +---- +curl https://api.anthropic.com/v1/messages \ + -H "Content-Type: application/json" \ + -H "X-API-Key: $ANTHROPIC_API_KEY" \ + -H "anthropic-version: 2023-06-01" \ + -H "anthropic-beta: mcp-client-2025-04-04" \ + -d '{ + "model": "claude-3-5-sonnet-latest", + "max_tokens": 1000, + "messages": [{ + "role": "user", + "content": "How do I increase my sales?" + }], + "mcp_servers": [ + { + "type": "url", + "url": "https://agent.thoughtspot.app/bearer/mcp", + "name": "thoughtspot", + "authorization_token": "TS_AUTH_TOKEN@my-instance.thoughtspot.cloud" + } + ] + }' +---- + +In the above example, the API call includes: + +* The user’s message. +* ThoughtSpot’s MCP Server endpoint `https://agent.thoughtspot.app/bearer/mcp`. +* An `authorization_token` that encodes which ThoughtSpot instance and user/token to use. + +Claude uses the configured MCP Server to call ThoughtSpot MCP tools as needed, using the bearer-style token you provided. + +=== OpenAI Responses API +If your application uses an OpenAI LLM, use the following API request format to connect OpenAI to the MCP Server: + +[source,bash] +---- +curl https://api.openai.com/v1/responses \ + -H "Content-Type: application/json" \ + -H "Authorization: Bearer $OPENAI_API_KEY" \ + -d '{ + "model": "gpt-4.1", + "tools": [ + { + "type": "mcp", + "server_label": "thoughtspot", + "server_url": "https://agent.thoughtspot.app/bearer/mcp", + "headers": { + "Authorization": "Bearer TS_AUTH_TOKEN", + "x-ts-host": "my-instance.thoughtspot.cloud" + } + } + ], + "input": "How can I increase my sales?" + }' +---- + +In the above example, the API call includes the following parameters: + +* MCP as the tool type. +* ThoughtSpot MCP Server URL. +* Authentication token and ThoughtSpot host URL. + +The OpenAI LLM model uses the configured MCP Server, sends the provided headers on each MCP tool call, and gets the requested data from your ThoughtSpot instance under that token's identity. + +=== Gemini API + +If your application is the MCP host and Gemini is the LLM provider, use the following code example to connect Gemini to the ThoughtSpot MCP Server. + +[source,typescript] +---- +import { + GoogleGenAI, + mcpToTool, +} from '@google/genai'; +import { Client } from "@modelcontextprotocol/sdk/client/index.js"; +import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js"; + +const transport = new StreamableHTTPClientTransport( + new URL("https://agent.thoughtspot.app/bearer/mcp"), + { + requestInit: { + headers: { + "Authorization": "Bearer TS_AUTH_TOKEN", + "x-ts-host": "my-instance.thoughtspot.cloud" + }, + } + } +); + +const mcpClient = new Client({ + name: "example-client", + version: "1.0.0", +}); + +await mcpClient.connect(transport); + +const ai = new GoogleGenAI({}); + +const response = await ai.models.generateContent({ + model: "gemini-2.5-flash", + contents: `Show me last quarter's sales by region`, + config: { + tools: [mcpToTool(mcpClient)], + }, +}); + +console.log(response.text); +await mcpClient.close(); +---- + +The above example: + +* Creates an MCP client and connects it to the ThoughtSpot MCP Server using `StreamableHTTPClientTransport`. +* Sends the required headers with the authentication token and ThoughtSpot host URL in MCP requests. +* Wraps the MCP client as a tool and passes it into `GoogleGenAI` so Gemini can call ThoughtSpot tools as part of answering a user's query. + +== Verifying the integration + +To verify the integration: + +. Start a chat session by asking a question and verify whether your chatbot's LLM is calling the ThoughtSpot MCP tools to generate a response. + +A typical agentic workflow follows this pattern: +* Calls `getRelevantQuestions` to break the request into sub-queries +* Calls `getAnswer` to run those questions in ThoughtSpot and receive structured data and visualization metadata +* Based on a user prompt, calls `createLiveboard` to save the results in a ThoughtSpot Liveboard. +. Verify whether the metadata in the output includes `frame_url` to embed a visualization in an iframe or HTML snippet. + +== Troubleshooting errors + +Cannot connect to MCP Server:: + +* Verify if the MCP Server is reachable. +* Ensure that the correct MCP Server URL is used in API requests. +* If the issue persists, verify the logs and contact ThoughtSpot Support for assistance. + +Authentication failure:: +* Ensure that the correct ThoughtSpot host URL and authentication token are in the API requests. +* Verify whether the token used for authorizing MCP requests has expired. If the token is invalid, generate a new token and retry the API calls. +* Verify whether the MCP Server and ThoughtSpot host are reachable. +* Verify whether the user has the necessary privileges to view data or create content. + +== MCP tool calls and response output +The following sections outline the MCP request input schema and data structure of the response. + +=== ping +Runs a basic health check to validate that the MCP Server is reachable. + +[source,ts] +---- +const tsPing = await callMCPTool("ping", {}); +---- + +=== getDataSourceSuggestions +Suggests appropriate ThoughtSpot data models for a given natural language question. + + +==== Example request + +[source,ts] +---- +const dsSuggestions = await callMCPTool("getDataSourceSuggestions", { + query: "show me sales by region" // user's query +}); +---- + +==== Response format + +Returns an object containing an array of suggestions: + +[source,json] +---- +{ + "suggestions": [ + { + "header": { + "guid": "worksheet-guid-123", + "displayName": "Sales Analytics", + "description": "Sales performance by region, product, and channel" + }, + "confidence": 0.92, + "llmReasoning": "This worksheet contains sales metrics and regional dimensions relevant to the query." + } + ] +} +---- + +Key fields are: + +* `header.guid`: Unique ID for the datasource. The `datasourceId` is used in `getRelevantQuestions` and `getAnswer` calls. +* `header.displayName`: Name of the data source. +* `header.description`: Optional description of the data source. +* `confidence`: Numeric score indicating the confidence of the system about a data model being the right match for the user’s query. +* `llmReasoning`: LLM's reasoning for the suggestion. + +=== getRelevantQuestions +Uses ThoughtSpot’s reasoning engine to generate AI-suggested sub-queries that help generate specific answers for a given data context. + +==== Example call + +[source,ts] +---- +const result = await callMCPTool("getRelevantQuestions", { + query: "show me sales data", // User's natural language query + datasourceIds: ["model-guid-123"], // Array of worksheet/datasource GUIDs + additionalContext: "User is interested in the data for underperforming regions and products" +}); +---- + +==== Response example + +[source,json] +---- +{ + "questions": [ + "What is the total sales revenue by region?", + "Which products have the highest revenue?", + "What are the top selling categories?" + ] +} +---- + +Each returned question can then be passed individually into `getAnswer`. + +=== getAnswer +Executes a natural language question for a given data context and returns the resulting data and visualization metadata. Clients can use this data and frame URL to render visualizations. + +==== Example call + +[source,ts] +---- +const result = await callMCPTool("getAnswer", { + question: "Total sales by region", // Natural language question + datasourceId: "model-guid-123" // Worksheet/datasource GUID +}); +---- + +==== Response example + +[source,json] +---- +{ + "question": "Total sales by region", + "session_identifier": "abc-123-def-456", + "generation_number": 2, + "data": "\"Region\",\"Total Sales\"\n\"East\",100000\n...", + "frame_url": "https://...", + "fields_info": "..." +} +---- + +Key fields are: + +* `session_identifier`: Unique session ID used to group answers. Required when creating a Liveboard from this answer using the `createLiveboard` MCP tool. +* `generation_number`: Version number for this answer. Required for Liveboard creation. +* `question`: The executed question; useful for display and to pass it into the `createLiveboard` request. +* `data`: Data returned in encoded format. Contains column headers and all returned rows in comma-separated format, which can be parsed to render tables or charts in your application. +* `frame_url`: Optional iframe URL for embedding the visualization in your UI. +* `fields_info`: Descriptive metadata about the fields and chart, useful for explanations. + +=== createLiveboard + +Creates a ThoughtSpot Liveboard with one or more answers from the results. This is a two-step process and includes the following calls: + +. Call `getAnswer` to generate visualizations and obtain `session_identifier` and `generation_number`. +. Call `createLiveboard` with those values to create the Liveboard. + +==== Example call + +[source,ts] +---- +const answerData = JSON.parse(answerResult.result.content); + +const liveboardResult = await callMCPTool("createLiveboard", { + name: "My Sales Dashboard", + noteTile: "My Sales Dashboard was created by TS MCP Chat", // Description text for the Liveboard + answers: [{ + question: answerData.question, // Display name for the Liveboard + session_identifier: answerData.session_identifier, + generation_number: answerData.generation_number + }] +}); +---- + +Required attributes are: + +* `noteTile`: Use this field for any Liveboard description or notes; a separate description field is not supported. +* `answers`: Required array. Each item must include `question`, `session_identifier`, and `generation_number` from a prior `getAnswer` call. + +==== Response example + +[source,json] +---- +{ + "liveboardId": "liveboard-guid-here", + "name": "My Sales Dashboard", + "frame_url": "https://..." +} +---- + +Key fields are: + +* `liveboardId`: GUID of the created Liveboard. +* `name`: Name of the Liveboard. +* `frame_url`: URL that can be embedded to display the Liveboard. + +== Additional resources + +* To view the MCP Server code, go to the link:https://github.com/thoughtspot/mcp-server[MCP Server GitHub repository, window=_blank]. +* For a chat client example, see link:https://github.com/thoughtspot/developer-examples/tree/main/mcp/python-react-agent-simple-ui[Python Agent with Simple React UI]. + + diff --git a/modules/ROOT/pages/mcp-integration.adoc b/modules/ROOT/pages/mcp-integration.adoc index 35238d93c..19a630b1f 100644 --- a/modules/ROOT/pages/mcp-integration.adoc +++ b/modules/ROOT/pages/mcp-integration.adoc @@ -1,414 +1,140 @@ -= MCP server integration += ThoughtSpot MCP Server :toc: true :toclevels: 3 :page-title: MCP integration :page-pageid: mcp-integration -:page-description: Learn how to use the ThoughtSpot Model Context Protocol (MCP) server to interact with ThoughtSpot data via MCP tools and AI APIs and get relevant questions and answers for a given query and create Liveboards at runtime. +:page-description: Learn what ThoughtSpot MCP Server is, when to use it, and how it fits into your AI and analytics architecture. -ThoughtSpot’s Agentic Model Context Protocol (MCP) Server allows you to integrate ThoughtSpot analytics directly into any AI agent, custom chatbot, or LLM-based platforms that support MCP. It acts as a connector between the ThoughtSpot instance and external AI client, and provides a set of tools for interacting with ThoughtSpot’s data and its analytics capabilities programmatically. - -The ThoughtSpot MCP Server is an add-on feature available with the link:https://www.thoughtspot.com/pricing[ThoughtSpot Analytics and ThoughtSpot Embedded offerings, window=_blank]. + -To purchase the MCP Server subscription and enable the MCP Server in your environment, you must have an active subscription to one of the following ThoughtSpot license plans: +ThoughtSpot’s Agentic Model Context Protocol (MCP) Server allows you to integrate ThoughtSpot analytics into any AI-native application, custom chatbot, or LLM platform that supports MCP. Instead of rebuilding analytics logic yourself, you connect an LLM/AI agent to the ThoughtSpot MCP Server. -* Enterprise Edition of ThoughtSpot Analytics -* ThoughtSpot Embedded subscription +== Overview +ThoughtSpot MCP Server exposes ThoughtSpot analytics as tools and resources that MCP-compatible agents can discover and call. -To learn more about the MCP Server subscription options and to get started, please contact your ThoughtSpot Sales representative. +When integrated, the MCP Server equips your AI agent/LLM with the following capabilities: -== Integration overview +* Automatic discovery of ThoughtSpot MCP tools +* Natural language queries and responses +* Programmatic creation of Liveboards and visualizations +* Generating embeddable visualizations for custom chatbot workflows -The Agentic MCP Server integration requires the following core components and authentication framework: +=== Supported use cases -MCP Server:: -The MCP Server exposes a set of tools that can be invoked by an LLM or external AI. ThoughtSpot's MCP Server acts as a bridge between the LLM/agent and ThoughtSpot application backend. +ThoughtSpot supports MCP Server integration for the following use cases: -MCP tools and resources:: -MCP tools are the actions that the MCP Server exposes to the agent for interaction with ThoughtSpot. +* *Plug-and-play clients* + +If your application already has an AI chat interface, you can use the MCP Server to plug ThoughtSpot analytics into your application's agentic experience. This integration works with agents or LLMs that natively support MCP, such as Claude, OpenAI, Gemini, or custom MCP clients. It allows your AI agent to call tools and leverage ThoughtSpot’s governed analytics, business semantic layer, data context, and row-level/object-level security, so you don’t need to build your own analytics logic. -* Ask natural language questions and get data in a structured format from ThoughtSpot -* Retrieve relevant analytical questions based on user queries -* Create a Liveboard with the answers generated from the queries -//* Get data source recommendations based on a user's query and intent +* *Custom chatbot integration* + +If you are building an MCP-based chatbot or application with your own orchestration logic or LLM, and you want to call ThoughtSpot MCP tools behind a custom web experience, integrate the MCP Server into your application. This approach is recommended when you need fine-grained control over conversation flow, backend orchestration, and the analytics experience. -+ -Currently, the MCP Server supports the following tools: - -* `ping` to test connection to ThoughtSpot -* `getRelevantQuestions` to get relevant analytical questions + -The `getRelevantQuestions` tool to fetch relevant data questions for a given data context by breaking down a user's query. -* `getAnswer` to execute the queries and fetch data + -The `getAnswer` tool generates answers and insights for a given data context. -* `createLiveboard` to create a Liveboard in ThoughtSpot + - -The `createLiveboard` tool calls the Liveboard creation workflow and creates a Liveboard with the answers generated from the user's query. - -//// -* `getDataSourceSuggestions` to get data source suggestions + -Based on the type of data that users want to fetch, `getDataSourceSuggestions` gets a list of data source recommendations. Currently, `getDataSourceSuggestions` is not exposed as an MCP tool and is available as an MCP `resource`. To get data source suggestions, the user or MCP client must have at least view access to ThoughtSpot data sources. -//// - -MCP client/ LLM agent:: - -The external system or application environment with AI Agent, Claude, OpenAI, or a custom chatbot that acts as a user interface and orchestrates interaction with the ThoughtSpot MCP Server. -This is the model or system that processes the user’s natural language input, determines which tool to call, and integrates the tool results into its final output. +==== Choosing the right integration option -//// -Configuration settings to enable the integration:: -Integration requires configuration, typically via a config file, to specify server addresses, credentials, and other connection details. -//// +Your integration choice depends on where the conversational UI is presented to the user and whether your application relies on ThoughtSpot, a third-party AI agent, or your own agentic AI to orchestrate the analytics workflow. -Authentication and security settings:: +Regardless of the integration mode, you can leverage ThoughtSpot’s semantic layer, data context, object-level, row-level, and column-level security to ensure trusted, governed analytics for your users. -* Access to ThoughtSpot instance + -For MCP Server connection, users require access to a ThoughtSpot instance. For tool invocation, the MCP server must accept authenticated requests, and the LLM tool specification must carry those credentials or headers. + -ThoughtSpot administrators can use the SSO framework with SAML or OAuth token-based authentication methods to authenticate and sign in users. + +=== Architecture and roles +The MCP Server integration and orchestration layer includes the following core components: -* SAML redirect settings: + -For SAML SSO users, the SAML redirect domain configuration is required to ensure that users are redirected to an allowed and trusted domain after they are authenticated. + -* To get answers to their data queries, your application users require at least view access to ThoughtSpot data sources. To generate an Answer or to create a Liveboard, users require the data download privilege. +[width="100%" cols="2,4"] +[options='header'] +|====== +|Component|Role -//// -* CSP and CORS settings: + -To secure communication between the MCP client and the ThoughtSpot instance, administrators must add the MCP Server URL to CSP (Content Security Policy) and CORS (Cross-Origin Resource Sharing) allowlists in ThoughtSpot. -//// -* Client connection configuration: + -MCP Server integration also requires configuration on the client side, typically via a config file, to include the MCP Server addresses, credentials, and other details. +|*Client Interface* a| +User interface that renders chat, responses, and charts. For example, Claude AI web app, Claude Desktop, ChatGPT, OpenAI-based integrations, Gemini-based agents, custom web applications, or internal tools. +|*Agent or LLM* +a| Acts as orchestrator. + -=== How it works +- Receives the user’s prompt +- Discovers ThoughtSpot MCP tools +- Decides which tools to call and in what order. +- Combines ThoughtSpot results with other sources and generates the final answer. -The MCP Server integration with an agentic framework or LLM clients enables the following workflow: +|*ThoughtSpot MCP Server* a| +- Acts as a gateway between the agent and ThoughtSpot. +- Exposes analytics as MCP tools. +- Validates requests and forwards calls to ThoughtSpot. -. User sends a query to get data from a specific ThoughtSpot data model context. -. The LLM / AI agent receives the request and sends it to the MCP server endpoint with the user's query. -. The MCP server responds with the available tools. +|*ThoughtSpot instance* +| Your ThoughtSpot instance where data models, Liveboards, and security policies exist. + -. The LLM / AI Agent determines the appropriate MCP tool to call. Based on the user's query or prompt, the MCP tools are invoked. For example, to get information for a specific data context from ThoughtSpot, break down the user's query into relevant questions or programmatically create an artifact in ThoughtSpot. -. The MCP server processes the request and returns the result. -. The agent receives the response, constructs the output, and presents it to the user. -. User receives the response. The user can refine the analysis with follow-up queries for further exploration or ask a new question. + -For example, after receiving relevant questions and answers, the user can send follow-up questions or initiate a Liveboard creation request. +- Executes queries and generates visualizations +- Provides access to data +- Enforces data security with RLS and CLS rules. +|*End user* +|Interacts with an AI client or custom application, asks questions, and acts on results. +|====== -The following figure illustrates the sequence of workflows in a typical MCP Server integration setup: +The following figure illustrates the interaction between the user, agent, and MCP Server: [.widthAuto] -image::./images/mcp-integration.png[MCP integration] - -== Get started -To get started with the integration, complete the steps described in the following sections. In this article, we'll integrate ThoughtSpot MCP Server with Claude and enable agentic interaction and workflows. - -=== Before you begin +image::./images/agents-mcp-server-arch.png[MCP integration] -Before you begin, verify if your application setup has the following: +=== MCP tools and resources -* Node.js version 22 or later is installed. -* A ThoughtSpot instance with 10.11.0.cl or later release version. You'll need administrator credentials to configure security settings or set up token-based authentication for your application users. -* Your application users have at least view access to the data source objects to query data and get answers. -* Row-level and column-level security rules are configured for data security and access control. +ThoughtSpot MCP Server exposes the following tools and resources: -//// -To enable secure communication between the MCP Server and your ThoughtSpot instance, configure the following settings: +* `ping` + +Connectivity/health check. Used by the MCP host, such as Claude, Gemini, or ChatGPT, to verify whether it can reach the ThoughtSpot MCP Server and whether the server is available. -. On your ThoughtSpot instance, navigate to *Develop* > *Customizations* > *Security Settings*. -. Add the MCP Server domain to CSP and CORS allowlists. -. If your setup uses SAML SSO logins, add the MCP Server domain to the SAML redirect domain allowlist. +* `getDataSourceSuggestions` + +Suggests the most relevant ThoughtSpot data sources for a given query. +* `getRelevantQuestions` + +Uses ThoughtSpot’s reasoning engine to turn a broad or high‑level user query into a set of concrete analytical questions that should be asked of the data. -=== Configure security settings on ThoughtSpot +* `getAnswer` + +Executes those analytical questions and returns structured data and answers. -To allow secure communication between the MCP Server and your ThoughtSpot instance, configure the following settings: +* `createLiveboard` + +Creates a ThoughtSpot Liveboard from a list of answers/questions, typically at the end of a conversation. It turns the conversational analysis into a Liveboard with visualizations. -. On your ThoughtSpot instance, navigate to *Develop* > *Customizations* > *Security Settings*. -. Add the MCP Server domain to CSP and CORS allowlists. -. If your setup uses SAML SSO logins, add the MCP Server domain to the SAML redirect domain allowlist. -//// - -=== Connect your client to the MCP Server - -If using a client that supports remote MCPs natively, such as Claude AI, use the following MCP server URL: ----- -https://agent.thoughtspot.app/mcp ----- +=== How it works -For OpenAI ChatGPT Deep Research, use the following URL: ----- -https://agent.thoughtspot.app/openai/mcp ----- +The agentic interactions in an orchestrated environment typically include these steps: -For MCP clients that do not support a remote MCP Server, you must xref:mcp-integration.adoc#_connecting_other_mcp_clients_claude_desktop[add the MCP server configuration to your MCP client settings]. +. *User asks a question* + +A user sends a query in the chat interface to get data. For example, `What were the total sales of Jackets and Bags in the Northeast last year?`. + +Optionally, the user can specify the data context to generate a response. -=== Call MCP tools via LLM APIs +. *Agent calls `getDataSourceSuggestions` (optional)* + +If the user’s question doesn’t specify a data source, the agent can call `getDataSourceSuggestions`. +ThoughtSpot returns candidate data sources (models) with confidence scores and reasoning. -ThoughtSpot remote MCP Server acts as a wrapper over the ThoughtSpot APIs, making them available as tools for agent frameworks or LLMs such as Claude or OpenAI. It exposes specific tools that can be invoked by the LLMs in response to a user's query or prompt. +. *User's query is decomposed into sub-questions* + +To break the user’s query into smaller analytical questions, the agent calls `getRelevantQuestions`. + +In response to the agent's request, ThoughtSpot returns the AI-suggested, schema-aware questions that are easier to execute analytically. -To enable tool calling: +. *The query is processed for generating answers* + +For each suggested or chosen question, the agent calls `getAnswer`. ThoughtSpot returns the following: + +* Preview data for LLM reasoning. +* Visualization metadata, including an embeddable `frame_url`. +* `session_identifier` and `generation_number` for charts that are used as input for creating a Liveboard. -* Register the ThoughtSpot MCP Server endpoint as a tool provider in your LLM or agent framework. -* Provide an authentication (OAuth or token-based) token. + -You can generate an authentication token for a specific user from ThoughtSpot via a `POST` call to the `/api/rest/2.0/auth/token/full` REST API endpoint. + -Logged-in users can view the authentication token for their current session by using the `/api/rest/2.0/auth/session/token` REST API endpoint or by opening the following URL in a new tab on the web browser: +. *A Liveboard is generated from the results* (optional) + +The user can choose to save answers from the conversation in a ThoughtSpot Liveboard. For this workflow, the agent extracts `question`, `session_identifier`, and `generation_number` from each `getAnswer` response and calls `createLiveboard`. + +ThoughtSpot creates a Liveboard and returns identifiers and a `frame_url` for the Liveboard. + -`\https://{your-ts-instance}/api/rest/2.0/auth/session/token` - -For information about calling MCP tools using LLM APIs and methods, see these sections: - -* xref:mcp-integration.adoc#_claude_mcp_connector[Claude MCP connector] -* xref:mcp-integration.adoc#_openai_api_for_mcp_tool_calling[OpenAI API] -* xref:mcp-integration.adoc#_gemini_api[Gemini API and function calling] - -==== Claude MCP connector -The Claude’s MCP connector allows you to connect to remote MCP Servers directly from the Messages API. - -To connect to the ThoughtSpot remote MCP Server, specify the following properties in the API request: - -* `mcp_servers` + -In the `mcp_servers` array, include these parameters: + -** `type` + -__String__. Type. Specify the type as `url`. -** `url` + -__String__. The URL of the remote MCP Server endpoint. Must start with `https://`. -** `name` + -__String__. A unique identifier/label for the MCP Server. It will be used in the MCP tool call blocks to identify the server and to disambiguate tools to the LLM. -** `authorization_token` + -__String__. OAuth authorization token (`TS_AUTH_TOKEN`) along with the ThoughtSpot application instance URL. In the following example, the authorization token is added as a prefix, and the ThoughtSpot host URL is added with the `@` symbol. - -* `messages` + -In the `messages` array, specify a natural language question in `content` and the user role in `role`. - -* `model` + -LLM model to use for processing queries and interacting with tools. For example, claude-sonnet-4-20250514. - -[source,cURL] ----- -curl https://api.anthropic.com/v1/messages \ - -H "Content-Type: application/json" \ - -H "X-API-Key: $ANTHROPIC_API_KEY" \ - -H "anthropic-version: 2023-06-01" \ - -H "anthropic-beta: mcp-client-2025-04-04" \ - -d '{ - "model": "claude-sonnet-4-20250514", - "max_tokens": 1000, - "messages": [{ - "role": "user", - "content": "How do I increase my sales ?" - }], - "mcp_servers": [ - { - "type": "url", - "url": "https://agent.thoughtspot.app/bearer/mcp", - "name": "thoughtspot", - "authorization_token": "$TS_AUTH_TOKEN@my-thoughtspot-instance.thoughtspot.cloud" - } - ] - }' ----- - -//// -[source,TypeScript] ----- -import { Anthropic } from '@anthropic-ai/sdk'; - -const anthropic = new Anthropic(); - -const response = await anthropic.beta.messages.create({ - model: "claude-sonnet-4-5", - max_tokens: 1000, - messages: [ - { - role: "user", - content: "How do I increase my sales ?", - }, - ], - mcp_servers: [ - { - type: "url", - url: "https://agent.thoughtspot.app/bearer/mcp", - name: "thoughtspot", - authorization_token: "$TS_AUTH_TOKEN@my-thoughtspot-instance.thoughtspot.cloud", - }, - ], - betas: ["mcp-client-2025-04-04"], -}); ----- -//// - -The request uses Claude’s internal tool-calling mechanism to call the MCP endpoint with the provided token, discover the available tools, and retrieve data for the user's query. - -For more information, see the link:https://docs.claude.com/en/docs/agents-and-tools/mcp-connector[Claude MCP connector documentation, window=_blank]. - -==== OpenAI API for MCP tool calling -To enable tool calling and retrieve data from ThoughtSpot via OpenAI, you can use the Responses API endpoint. - -To connect to the ThoughtSpot remote MCP server, call the `\https://api.openai.com/v1/responses` API endpoint and specify the following properties in the API request: - -* `tools` + -In the `tools` array, include these parameters: - -** `server_url` + -The URL of the ThoughtSpot MCP Server. Use the full path of the MCP server URL. -** `server_label` + -Label of the ThoughtSpot MCP Server -** `type` + -Type of tool. For example, MCP. -** `headers` + -Additional headers needed for authentication, for example, the authentication token and URL of the ThoughtSpot host. - -* `input` + -Include the natural language query string as `input`. -* `model` + -LLM model to use for processing queries and interaction with tools. For example, GPT-5 or GPT 4.1. - -[source,cURL] ----- -curl https://api.openai.com/v1/responses \ - -H "Content-Type: application/json" \ - -H "Authorization: Bearer $OPENAI_API_KEY" \ - -d '{ - "model": "gpt-4.1", - "tools": [ - { - "type": "mcp", - "server_label": "thoughtspot", - "server_url": "https://agent.thoughtspot.app/bearer/mcp", - "headers": { - "Authorization": "Bearer $TS_AUTH_TOKEN", - "x-ts-host": "my-thoughtspot-instance.thoughtspot.cloud" - } - } - ], - "input": "How can I increase my sales ?" -}' ----- - -If the API request is successful, the LLM discovers the available MCP tools from the MCP Server endpoint. Once the model has access to these tools, it determines the tool to call depending on the user's query and what's in the model's context. - -For more information, see link:https://platform.openai.com/docs/guides/tools-connectors-mcp[Open AI Connectors and MCP Server Documentation]. - -==== Gemini API - -You can use the standard function calling mechanism provided in Gemini Python/Typescript SDK. The Gemini SDK supports MCP natively, and can pass tool definitions and call tools. - -In the following example, a session linked to the ThoughtSpot remote MCP Server is passed along with the authorization token and the ThoughtSpot host, so that the SDK can handle tool calling. - -[source,TypeScript] ----- -import { GoogleGenAI, FunctionCallingConfigMode , mcpToTool} from '@google/genai'; -import { Client } from "@modelcontextprotocol/sdk/client/index.js"; -import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js"; - -// Create server parameters for stdio connection -const serverParams = new StreamableHTTPClientTransport(new URL("https://agent.thoughtspot.app/bearer/mcp"), { - requestInit: { - headers: { - "Authorization": "Bearer $TS_AUTH_TOKEN", - "x-ts-host": "my-thoughtspot-instance.thoughtspot.cloud" - }, - } -}); - -const client = new Client( - { - name: "example-client", - version: "1.0.0" - } -); - -// Configure the client -const ai = new GoogleGenAI({}); - -// Initialize the connection between client and server -await client.connect(serverParams); - -// Send request to the model with MCP tools -const response = await ai.models.generateContent({ - model: "gemini-2.5-flash", - contents: `What is the weather in London in ${new Date().toLocaleDateString()}?`, - config: { - tools: [mcpToTool(client)], // uses the session, will automatically call the tool - // Uncomment if you **don't** want the sdk to automatically call the tool - // automaticFunctionCalling: { - // disable: true, - // }, - }, -}); -console.log(response.text) - -// Close the connection, -await client.close(); ----- - -For additional information, refer to the following resources: - -* For more information about Gemini API MCP tool calling, see link:https://ai.google.dev/gemini-api/docs/function-calling?example=meeting#mcp[Function calling with the Gemini API documentation, window=_blank]. -* A link:https://github.com/thoughtspot/developer-examples/tree/main/mcp/python-google-adk-trusted-auth[developer example with Google ADK and Python implementation] is also available in the link:https://github.com/thoughtspot/developer-examples[ThoughtSpot Developer Examples GitHub repository, window=_blank]. -* The ThoughtSpot MCP server can also be installed as a Gemini CLI extension. For more information, see link:https://github.com/google-gemini/gemini-cli[Gemini CLI, window=_blank]. - -=== For clients that do not support the remote MCP server - -For clients such as Claude Desktop, Windsurf, and Cursor, which do not support remote MCP servers, add the following configuration to your MCP client settings: - -[source,JSON] ----- -{ - "mcpServers": { - "ThoughtSpot": { - "command": "npx", - "args": [ - "mcp-remote", - "https://agent.thoughtspot.app/mcp" - ] - } - } -} ----- - -After updating the config file: - -. When prompted to connect your ThoughtSpot instance, add the URL of your application instance and complete authentication. -. Restart your MCP client to load the new configuration. +During this interaction, users typically see a natural-language summary. When a Liveboard is created, a link to open the corresponding Liveboard in ThoughtSpot is generated. + -If the connection is successful, you'll see an option to connect to ThoughtSpot and choose the data context. -+ -For example, the Claude Desktop shows the *Add to ThoughtSpot* as shown in the following figure: -+ -[.bordered] -[.widthAuto] -image::./images/claudeDesktop.png[Claude Desktop] +In custom applications, you can embed the visualizations generated from the interaction, load them inside iframe elements, and render interactive charts directly in your webpage. You can also add your own buttons or links, such as 'Save as Liveboard' or 'Pin this analysis', which call `createLiveboard` to create or persist a Liveboard that contains your current charts and analysis. -. Verify if the MCP tools are available. + -For example, on Claude Desktop, click the Search and tools icon to view the MCP tools. -+ -[.bordered] -[.widthAuto] -image::./images/mcp-tools-claude.png[Claude Desktop] +== Getting access to the MCP Server -. Select a data source to set the context of your query and verify the request and response flow. -+ -[.bordered] -[.widthAuto] -image::./images/query-response-claude.png[Claude query response] +ThoughtSpot MCP Server is available as an add-on with the following link:https://www.thoughtspot.com/pricing[license plans]: -. Try sending a query to create a Liveboard and verify if a Liveboard is created on your ThoughtSpot instance. -+ -[.bordered] -[.widthAuto] -image::./images/create-lb-claude.png[Liveboard creation] +* ThoughtSpot Enterprise Edition +* ThoughtSpot Embedded -== Configuration considerations and best practices +To learn more about subscription options, contact your ThoughtSpot Sales representative. -* Users must have at least view access to the data source. Otherwise, it may lead to empty results. -* Ensure that data is modeled. Large or complex data sources may impact response time. -* Streaming responses require client support for real-time updates. Ensure that your system is available to receive and process data. -* Each conversation is session-based. Ensure that session IDs are managed correctly in your integration. +== Next steps +* To learn how to connect existing MCP-aware tools such as Claude, ChatGPT, and Gemini, see xref:mcp-server-client-connection.adoc[Connecting MCP clients to ThoughtSpot MCP Server]. +* To learn how to integrate MCP Server with a custom chatbot or application, see xref:mcp-connect-custom-chatbot.adoc[Integrating MCP Server in a custom chatbot]. == Additional resources - -* Check the link:https://github.com/thoughtspot/mcp-server[MCP Server GitHub repo, window=_blank] for implementation instructions. -* Check your MCP client's documentation for instructions on how to connect to MCP Servers. -* In case of issues with connection or authentication, refer to the link:https://github.com/thoughtspot/mcp-server?tab=readme-ov-file#troubleshooting[troubleshooting steps^]. -* To understand ThoughtSpot's agentic analytics capabilities and AI APIs, refer to the following documentation: - -** link:https://docs.thoughtspot.com/cloud/latest/spotter[Spotter Documentation, window=_blank] -** link:https://docs.thoughtspot.com/cloud/latest/spotter-agent[Spotter Agent Documentation, window=_blank] -** xref:spotter-apis.adoc[Spotter AI APIs] +* For information about MCP, see link:https://modelcontextprotocol.io[Model Context Protocol specification, window=_blank]. +* For implementation details, see link:https://github.com/thoughtspot/mcp-server[MCP Server GitHub repository, window=_blank]. diff --git a/modules/ROOT/pages/mcp-server-client-connection.adoc b/modules/ROOT/pages/mcp-server-client-connection.adoc new file mode 100644 index 000000000..f1497b35c --- /dev/null +++ b/modules/ROOT/pages/mcp-server-client-connection.adoc @@ -0,0 +1,110 @@ += Connecting MCP Server to MCP clients +:toc: true +:toclevels: 3 + +:page-title: Connecting MCP Server to MCP clients +:page-pageid: connect-mcp-server-to-clients +:page-description: Learn how to connect Claude, ChatGPT, Gemini, and other MCP-aware clients to ThoughtSpot MCP Server with minimal configuration. + +If your application already has an AI-native experience or supports MCP-aware agents and LLMs, you can integrate ThoughtSpot analytics directly into your app's agentic experience by connecting the MCP Server to your client. + +In this plug-and-play integration, your application's chat interface and LLM orchestrate conversation sessions. The MCP Server exposes ThoughtSpot's analytics capabilities as tools, which your agent or LLM can invoke as needed. This approach allows you to bring ThoughtSpot analytics into your own AI-native experience and use it as a data and analytics provider through the MCP Server, while your system controls user interaction and orchestration logic. + +When your MCP client is connected to the ThoughtSpot MCP Server, the AI agent/LLM can: + +* Automatically discover ThoughtSpot MCP tools. +* Call the MCP tools to determine the data context and answer data questions. +* Create a Liveboard with the visualizations generated during the interaction. + + +[IMPORTANT] +==== +* Currently, the MCP Server integration does not support link:https://docs.thoughtspot.com/cloud/latest/spotter-versions[Spotter 3 capabilities]. +* In the plug-and-play integration mode, embedding visualizations is not supported. +==== + +== Before you begin +Before you begin, review the following prerequisites: + +* Ensure that your setup has access to a ThoughtSpot application instance with 10.11.0.cl or a later release version. +* Ensure that the users have the necessary permissions to view data from relevant models and tables in ThoughtSpot. Existing RLS/CLS rules on tables are enforced automatically in data source responses. To create charts or Liveboards from a conversation session, data download and content creation privileges are required. + +=== Connecting clients that support remote MCP servers +To connect to a client that supports remote MCP servers natively, add the MCP Server endpoint to your client's configuration settings. + +`https://agent.thoughtspot.app/mcp` + +For clients that require a bearer token for authentication, use the following URL format: + +`https://agent.thoughtspot.app/bearer/mcp` + +For OpenAI MCP and Responses API integration, use the following URL: + +`https://agent.thoughtspot.app/openai/mcp` + +For additional information about how to register a remote MCP Server, refer to your client's documentation. + +=== Connecting MCP Server to local MCP clients +For MCP clients that do not natively support configuring a remote MCP Server URL, you must use the `mcp-remote` component. For desktop clients that rely on local MCP components, ensure that Node.js version 22 or later is installed on your system. + +[source,json] +---- +{ + "mcpServers": { + "ThoughtSpot": { + "command": "npx", + "args": [ + "mcp-remote", + "https://agent.thoughtspot.app/mcp" + ] + } + } +} +---- + +== Authenticating users +In a plug-and-play integration, the most common way to authenticate users is through OAuth tokens. This method allows you to leverage your existing IdP or SSO configuration for ThoughtSpot login and rely on the platform to initiate a browser-based sign-in flow. + +=== OAuth flow +In a typical OAuth flow: + +* The ThoughtSpot MCP Server is configured as a connector/tool in the MCP client. +* When the user connects, the client redirects the user to ThoughtSpot to sign in. +* After successful login, the client stores the issued OAuth tokens and includes them with each MCP tool call to the ThoughtSpot MCP Server, which then calls ThoughtSpot on behalf of that user. + +=== OAuth client registration +OAuth clients can be registered in one of the following ways: + +* For MCP hosts that support Dynamic Client Registration (DCR), the OAuth client is registered automatically. +* For MCP hosts that do not support dynamic registration or that require static client credentials, you must manually register an OAuth client, obtain the OAuth client ID and OAuth client secret, and then configure these in the MCP host when adding ThoughtSpot as an MCP connector. The generated client details are only shown once and cannot be retrieved later. ++ +To register a client, visit link:https://agent.thoughtspot.app/clients[ThoughtSpot MCP OAuth Client Registration, window=_blank]. When registering the OAuth client, add your ThoughtSpot instance URL to the appropriate field. This ensures that users are not prompted to enter the instance URL during the OAuth flow, and the OAuth redirect returns correctly to your ThoughtSpot environment after login. + + +== Verifying integration +After the MCP Server is connected, some clients show *ThoughtSpot Data Sources* under a *Resources* or *Datasets* section. + +To verify the integration: + +. Start a chat session with the agent and verify the response. +. Verify that xref:mcp-integration.adoc#_mcp_tools_and_resources[MCP tools are being called] to generate responses. +. Prompt the agent to create a Liveboard from a query response and verify whether a Liveboard is added to your ThoughtSpot application. + +== Troubleshooting errors + +MCP Server is not connected:: + +* Verify if the MCP Server is reachable. +* Ensure that you have access to a ThoughtSpot instance. +* Ensure that there are no configuration errors. +* If the issue persists, verify the logs and contact ThoughtSpot Support for assistance. + +Authentication failure:: +If user authentication fails, or if the server returns HTTP 500, 401, or 403 status codes: +* Verify whether the MCP Server endpoint and ThoughtSpot host are correctly configured in your client and are reachable. +* Verify if the user session has expired. Log in to your ThoughtSpot application to start a new session. +* Verify whether the user has the necessary privileges to view data or create content. + +== Additional resources +* For information about the MCP Server features and architecture, see xref:mcp-integration.adoc[MCP Server integration]. +* To view the MCP Server code, go to the link:https://github.com/thoughtspot/mcp-server[MCP Server GitHub repository, window=_blank]. \ No newline at end of file diff --git a/modules/ROOT/pages/webhooks-lb-schedule.adoc b/modules/ROOT/pages/webhooks-lb-schedule.adoc index a291662c1..fa439c172 100644 --- a/modules/ROOT/pages/webhooks-lb-schedule.adoc +++ b/modules/ROOT/pages/webhooks-lb-schedule.adoc @@ -1,18 +1,20 @@ -= Webhooks for Liveboard schedule events [beta betaBackground]^Beta^ += Webhooks for Liveboard schedule events :toc: true :toclevels: 3 -:page-title: Webhooks for Liveboard Schedueld Jobs +:page-title: Webhooks for Liveboard Scheduled Jobs :page-pageid: webhooks-lb-schedule :page-description: Configure Webhooks and send alerts to specific communication channels +[beta betaBackground]^Beta^ + To provide flexibility and programmatic control for users who want to customize notifications and automate workflows based on Liveboard scheduling events, ThoughtSpot provides the ability to configure a webhook communication channel. By configuring a webhook, users can send notifications automatically to a target application whenever a scheduled Liveboard job is triggered in ThoughtSpot. Webhook support for Liveboard schedule events is available only on ThoughtSpot Cloud instances running 10.14.0.cl or later. This feature is currently in beta and is not enabled by default. To enable this feature on your instance, contact ThoughtSpot Support. == Overview -If you have scheduled a Liveboard job to receive a daily report via email, you can configure ThoughtSpot to send the report directly to a webhook endpoint and create your own custom emails or workflow. +If you have scheduled a Liveboard job to receive a daily report via email, you can configure ThoughtSpot to send the report directly to a webhook endpoint and create your own custom emails or workflows. To automate sending scheduled Liveboard notifications to a webhook endpoint, the following configuration is required: @@ -36,10 +38,10 @@ In the current release: ==== == Get started -The webhooks setup for Liveboard Schedule events involves the following steps: +The webhook setup for Liveboard schedule events includes the following steps: -* xref:webhooks-lb-schedule.adoc#_configure_webhook_communication_channel[Configuring a webhook communication channel at the cluster or Org level]. -* xref:webhooks-lb-schedule.adoc#_configure_a_webhook_for_liveboard_schedule_event[Creating a webhook to listen to the Liveboard schedule events]. +* xref:webhooks-lb-schedule.adoc#_configure_a_webhook_communication_channel[Configuring a webhook communication channel at the cluster or Org level]. +* xref:webhooks-lb-schedule.adoc#_configure_a_webhook[Creating a webhook to listen to Liveboard schedule events]. * xref:webhooks-lb-schedule.adoc#_verify_the_webhook_payload[Verifying the webhook payload]. === Before you begin @@ -51,14 +53,14 @@ If your instance has Role-based Access Control (RBAC) enabled, you need the foll ** `APPLICATION_ADMINISTRATION` (*Can Manage Application settings*) to create and view communication channels. ** `CAN_MANAGE_WEBHOOKS` (*Can manage webhooks*) to create and manage webhooks. * Ensure that the REST APIs for setting communication channel preference and configuring webhooks are enabled on your instance. If the APIs are not available on your instance, contact ThoughtSpot Support. -* To allow outbound traffic from the ThoughtSpot to the webhook endpoint, add the webhook destination URL to the xref:security-settings.adoc#csp-connect-src[CSP connect-src] allowlist in ThoughtSpot. +* To allow outbound traffic from ThoughtSpot to the webhook endpoint, add the webhook destination URL to the xref:security-settings.adoc#csp-connect-src[CSP connect-src] allowlist in ThoughtSpot. * Ensure that your destination application has a callback URL to accept HTTP POST requests from ThoughtSpot. * If you plan to use OAuth authentication, make sure you have the OAuth credentials and authorization URL of your application. * If you plan to use an API key for authentication, ensure that you have a valid API key. === Configure a webhook communication channel -To create a webhook communication channel for the Liveboard Schedule event, use the channel preference REST API. +To create a webhook communication channel for the Liveboard schedule event, use the channel preference REST API. ==== Create a webhook communication channel @@ -70,12 +72,12 @@ To create the webhook communication channel and set messaging preferences, send [options='header'] |===== |Parameter|Description | -.3+| `cluster_preferences` 2+|__Array of strings__. Sets default preferences for all Orgs in the instance. You must specify the following parameters: +.3+| `cluster_preferences` 2+|__Array of objects__. Sets default preferences for all Orgs in the instance. You must specify the following parameters: -|`event_type` +| `event_type` a|__String__. Type of the event for which communication channels are configured. For Liveboard schedule event, set the parameter value as `LIVEBOARD_SCHEDULE`. -|`channels` a| +| `channels` a| __Array of strings__. Communication channel for the event type specified in the request. Valid values are: + * `EMAIL` @@ -83,12 +85,12 @@ __Array of strings__. Communication channel for the event type specified in the To create a webhook channel for the Liveboard schedule event, specify `WEBHOOK`. -.5+| `org_preferences` 2+|__Array of strings__. By default, preferences configured at the cluster level will apply to all Orgs in the instance. To override the default preferences for your Org, set the Org-specific preferences: +.5+| `org_preferences` 2+|__Array of objects__. By default, preferences configured at the cluster level apply to all Orgs in the instance. To override the default preferences for your Org, set Org-specific preferences: | `org_identifier` a| __String__. Name or ID of the Org. | `preferences` a| -__Array of strings__. Define the following parameters to set communication channel preferences for the Org. If the preferences are not set, the Org will inherit the default preferences applied at the cluster level. +__Array of objects__. Define the following parameters to set communication channel preferences for the Org. If preferences are not set, the Org inherits the default preferences applied at the cluster level. * `event_type` + __String__. Type of the event for which communication channels are configured. For Liveboard schedule event, set the parameter value as `LIVEBOARD_SCHEDULE`. @@ -103,9 +105,9 @@ To set up a webhook channel for the Liveboard schedule event, specify `WEBHOOK`. | `operation` a|__String__. Type of operation. The following options are available: ** `REPLACE` - To replace default preferences. -** `RESET` - To restore default preferences. For reset operation, you'll also need to specify the event type. Note that this operation will remove any Org-specific overrides and restores the default preferences configured at the cluster level. +** `RESET` - To restore default preferences. For reset operation, you'll also need to specify the event type. Note that this operation removes any Org-specific overrides and restores the default preferences configured at the cluster level. -|`reset_events` a|__Array of strings__. For RESET operations, specify the event type to reset. Note that the reset operation removes Org-specific configuration for the events specified in `reset_events`. +| `reset_events` a|__Array of strings__. For `RESET` operations, specify the event type to reset. Note that the reset operation removes Org-specific configuration for the events specified in `reset_events`. ||| |===== @@ -313,11 +315,11 @@ To create a webhook for the Liveboard schedule event, send a `POST` request to t |Parameter|Description | `name` a|__String__. Name of the webhook. | `description` + -__Optional__ a|__String__. Description text for the webhook +__Optional__ a|__String__. Description text for the webhook. | `url` a|__String__. The fully qualified URL of the listening endpoint where the webhook payload will be sent. The webhook endpoint to which you want to send notifications. -|`url_params` a| A JSON map of key-value pairs of parameters to add as a GET query params in the webhook URL. +| `url_params` a| A JSON map of key-value pairs to append as query parameters in the webhook URL. | `events` a|__Array of strings__. List of events to subscribe to. Specify the event as `LIVEBOARD_SCHEDULE`. -|`authentication` a| +| `authentication` a| Defines authentication method and credentials that ThoughtSpot will use when sending HTTP requests to the webhook endpoint. @@ -331,8 +333,8 @@ Authentication methods with username and password. Authentication token to authenticate and authorize requests. * `OAUTH2` + OAuth credentials to authorize API requests. Specify client ID, client secret key, and authorization URL. -If the registered webhook has Oauth authentication enabled, `Authorization: Bearer ` is sent in the request header. -|`signature_verification` + +If the registered webhook has OAuth authentication enabled, `Authorization: Bearer ` is sent in the request header. +| `signature_verification` + __Optional__ a| Signature verification parameters for the webhook endpoint to verify the authenticity of incoming requests. This typically involves ThoughtSpot signing the webhook payload with a secret, and your webhook endpoint validating this signature using the shared secret. If using signature verification, specify the following parameters. @@ -366,7 +368,7 @@ curl -X POST \ ], "authentication": { "BEARER_TOKEN": "Bearer {AUTH_TOKEN}" - } + }, "description": "Webhook for Liveboard schedule" }' ---- @@ -390,7 +392,7 @@ If the webhook creation is successful, the API returns the following response: "events": [ "LIVEBOARD_SCHEDULE" ], - "authentication": BEARER_TOKEN, + "authentication": "BEARER_TOKEN", "signature_verification": null, "creation_time_in_millis": 1761050197164, "modification_time_in_millis": 1761050197164, @@ -406,7 +408,7 @@ If the webhook creation is successful, the API returns the following response: To view the properties of a webhook or get a list of webhooks configured on your ThoughtSpot instance, send a `POST` request to the `/api/rest/2.0/webhooks/search` API endpoint. -To get specific information, define the following parameters. If the API request is sent without any parameters in the request body, ThoughtSpot returns the webhooks configured for the Org contexts in ThoughtSpot. +To get specific information, define the following parameters. If the API request is sent without any parameters in the request body, ThoughtSpot returns the webhooks configured for the Org context in ThoughtSpot. ===== Request parameters @@ -418,7 +420,7 @@ To get specific information, define the following parameters. If the API request __Optional__ |__String__. ID or name of the Org. | `webhook_identifier` + __Optional__ | __String__. ID or name of the webhook. -|`event_type` + +| `event_type` + __Optional__| __String__. Type of webhook event to filter by. For Liveboard schedule events, specify `LIVEBOARD_SCHEDULE`. |Pagination settings a| If fetching multiple records, specify the following parameters to paginate API response: + @@ -427,7 +429,7 @@ __Integer__. Specifies the starting point (index) from which records should be r * `record_size` + __Integer__. Specifies the number of records to return in the response. Default is 50. | `sort_options` + -__Optional__| Enables sorting of the API response by a specific field in ascending or descending order. Specify the `field_name` and define the desired sort order. +__Optional__| Enables sorting of the API response by a specific field in ascending or descending order. Specify the `field_name` and define the desired sort order. | |===== @@ -515,7 +517,7 @@ Query parameters to append to the endpoint URL. * `events` + Events subscribed to the webhook. In the current release, ThoughtSpot supports only the `LIVEBOARD_SCHEDULE` event. * `authentication` + -Authentication method and credentials that ThoughtSpot will use when sending HTTP requests to the webhook endpoint +Authentication method and credentials that ThoughtSpot will use when sending HTTP requests to the webhook endpoint. * `signature_verification` + Signature verification parameters for the webhook endpoint to verify the authenticity of incoming requests. @@ -554,7 +556,7 @@ Specify the name or ID of the webhook to delete. [options='header'] |===== |Parameter|Description -|`webhook_identifiers` |__Array of strings__. ID of name of the webhooks to delete. +| `webhook_identifiers` |__Array of strings__. ID or name of the webhooks to delete. || |===== @@ -614,13 +616,13 @@ If the API request is successful, the webhook is deleted, and the API returns th === Verify the webhook payload -After a webhook channel is configured for Liveboard schedule events and a webhook is created for these events at the Org level, it's applied to all Liveboard schedules in an Org. +After a webhook channel is configured for Liveboard schedule events and a webhook is created for these events at the Org level, it is applied to all Liveboard schedules in an Org. When a Liveboard schedule event is triggered based on the conditions defined in the schedule, the webhook sends the payload with the following schema to the configured endpoint. Based on the Liveboard job settings, the payload includes metadata properties such as webhook communication channel ID, recipient details, Liveboard schedule details, event properties, and a link to the Liveboard. For testing purposes, you can use a URL from the link:https://webhook.site/[Webhook site, window=_blank] as a webhook endpoint and check the payload when the Liveboard schedule event is triggered. -==== Contents of the webhook playload +==== Contents of the webhook payload The Webhook payload uses a specific schema structure that determines the contents of the payload delivered to the webhook endpoint. The payload contains metadata about the event, the source, the actor, the target object, and event-specific data. The payload is typically sent as a form field named `payload` in a `multipart/form-data` request, with optional file attachments. @@ -652,16 +654,16 @@ The `WebhookPayload` schema defines the structure for webhook event notification | `timestamp` | string | Timestamp of when the event occurred. | Yes | `eventType` | string | Type of event that triggered the webhook payload. For example, `LIVEBOARD_SCHEDULE`. | Yes | `schemaVersion` | string | Schema version. | Yes -| `source` | object |Source endpoint that triggered the event. Includes the parameters defined in the xref:webhooks-lb-schedule.adoc#_webhooksourceinfo[WebhookSourceInfo] schema. | Yes +| `source` | object | Source endpoint that triggered the event. Includes the parameters defined in the xref:webhooks-lb-schedule.adoc#_webhooksourceinfo[WebhookSourceInfo] schema. | Yes | `actor` | object | Actor that initiated the event. For more information, see xref:webhooks-lb-schedule.adoc#_webhookactorinfo[WebhookActorInfo]. | Yes | `metadataObject` | object | Metadata object details. For more information, see xref:webhooks-lb-schedule.adoc#_webhooktargetobjectinfo[WebhookTargetObjectInfo]. | Yes -| `data` | object |Data specific to the Liveboard schedule event. For more information, see xref:webhooks-lb-schedule.adoc#_liveboardscheduledata[LiveboardScheduleData]. | Yes +| `data` | object | Data specific to the Liveboard schedule event. For more information, see xref:webhooks-lb-schedule.adoc#_liveboardscheduledata[LiveboardScheduleData]. | Yes |||| |===== ===== WebhookSourceInfo -The `WebhookSourceInfo` schema defines the properties of source application instance that triggered the webhook event. +The `WebhookSourceInfo` schema defines the properties of the source application instance that triggered the webhook event. [width="100%" cols="1,1,3,1"] [options='header'] @@ -685,9 +687,9 @@ The `WebhookActorInfo` schema defines the properties of the entity that initiate | Field | Type | Description | Required? | `actorType` | string | Initiator of the event such as the API client or user. The default actor type is `SYSTEM`. | Yes -| `id` | string a| Unique identifier such as GUID or object ID).For system-generated responses, the `id` will be set as `null`. | No -| `name` | string a| Name of the actor that initiated the event. For system-generated responses, the `name` will be set as `null`. | No -| `email` | string a| Email of the actor that initiated the event. For system-generated responses, the `name` will be set as `null`. | No +| `id` | string a| Unique identifier such as a GUID or object ID. For system-generated responses, the `id` is set to `null`. | No +| `name` | string a| Name of the actor that initiated the event. For system-generated responses, the `name` is set to `null`. | No +| `email` | string a| Email of the actor that initiated the event. For system-generated responses, the `email` is set to `null`. | No |||| |===== @@ -709,7 +711,7 @@ The `WebhookTargetObjectInfo` schema defines the object for which the event is g ===== LiveboardScheduleData -The `WebhookTargetObjectInfo` schema defines event-specific data for Liveboard schedule events, including schedule details, recipients, and additional context. +The `LiveboardScheduleData` schema defines event-specific data for Liveboard schedule events, including schedule details, recipients, and additional context. [width="100%" cols="1,1,3,1"] [options='header'] @@ -717,8 +719,8 @@ The `WebhookTargetObjectInfo` schema defines event-specific data for Liveboard s | Field | Type | Description | Required | `scheduleDetails` | object | Details of the Liveboard schedule that triggered the event. This includes the schedule ID, object type, and output format. For more information, see xref:webhooks-lb-schedule.adoc#_scheduledetails[ScheduleDetails]. | Yes -| `recipients` | array | Details of the ThoughtSpot users, groups, and email addresses of the external users who are configured as subscribers of the Liveboard schedule notifications and recipients of the webhook payload. For more information, xref:webhooks-lb-schedule.adoc#_recipientinfo[RecipientInfo]. | Yes -| `viewInfo` | object | Information about the Liveboard view. Applicable if the Liveboard Schedule event is triggered for a personalized view of the Liveboard. For more information, xref:webhooks-lb-schedule.adoc#_viewinfo[ViewInfo]. | No +| `recipients` | array | Details of ThoughtSpot users, groups, and email addresses of external users configured as subscribers to Liveboard schedule notifications and recipients of the webhook payload. For more information, see xref:webhooks-lb-schedule.adoc#_recipientinfo[RecipientInfo]. | Yes +| `viewInfo` | object | Information about the Liveboard view. Applicable if the Liveboard schedule event is triggered for a personalized view of the Liveboard. For more information, see xref:webhooks-lb-schedule.adoc#_viewinfo[ViewInfo]. | No | `aiHighlights` | string | AI Highlights information. Applicable if AI highlights feature is enabled for the visualizations on the Liveboard. | No | `msgUniqueId` | string | Unique message identifier. Unique ID of the webhook payload message. This ID can be used for traceability and deduplication on the receiving end. | No | `channelID` | string | The communication channel ID used for event dissemination. | No @@ -740,12 +742,12 @@ The `ScheduleDetails` schema defines the properties of the schedule that trigger | `creationTime` | string | Timestamp of when the schedule was created. | No | `description` | string | Description of the schedule. | No | `authorId` | string | ID of the user that scheduled the Liveboard job. | No -| `viewInfo` | object | Information about the Liveboard view. Applicable if the Liveboard Schedule event is triggered for a personalized view of the Liveboard. For more information, xref:webhooks-lb-schedule.adoc#_viewinfo[ViewInfo]. | No +| `viewInfo` | object | Information about the Liveboard view. Applicable if the Liveboard schedule event is triggered for a personalized view of the Liveboard. For more information, see xref:webhooks-lb-schedule.adoc#_viewinfo[ViewInfo]. | No | `userIds` | array | IDs of the ThoughtSpot users that are subscribed to the scheduled Liveboard notifications. | No | `groupIds` | array | IDs of the ThoughtSpot groups that are subscribed to the scheduled Liveboard notifications.| No | `runId` | string | Schedule run ID of the Liveboard job. | No | `exportRequest` | object | Details of the file export request. If the scheduled notification includes PDF attachment, the `exportRequest` includes details of the Liveboard and PDF page attributes. | No -| `fileFormat` | string | File format for export. The schedule notification generally include PDF attachments. | No +| `fileFormat` | string | File format for export. The schedule notification generally includes PDF attachments. | No | `status` | string | Status of the schedule. | No | `emailIds` | array | Email IDs of users subscribed to Liveboard job schedule. | No |||| @@ -765,7 +767,7 @@ The `RecipientInfo` schema defines the object properties of the recipients of th * `USER` - For ThoughtSpot users * `EXTERNAL_EMAIL` - For external recipients | Yes -| `id` | string | IDs of the ThoughtSpot user and groups that are subscribed to the Liveboard schedule. | No +| `id` | string | IDs of ThoughtSpot users and groups that are subscribed to the Liveboard schedule. | No | `name` | string | Name of the recipient. | No | `email` | string | Email address of the recipient. | Yes | `locale`| string | Locale of the recipient. For example, `en_US`. | No diff --git a/modules/ROOT/pages/whats-new.adoc b/modules/ROOT/pages/whats-new.adoc index ad3899546..de63695b2 100644 --- a/modules/ROOT/pages/whats-new.adoc +++ b/modules/ROOT/pages/whats-new.adoc @@ -16,7 +16,7 @@ The ThoughtSpot Cloud 26.3.0.cl version is now available for ThoughtSpot Embedde === SpotterCode extension for IDEs [earlyAccess eaBackground]#Early Access# -ThoughtSpot introduces SpotterCode, an AI-powered Model Context Protocol (MCP) extension for Integrated Development Environments (IDEs) such as Cursor, Visual Studio Code, and Claude Code. When integrated, SpotterCode enables the AI agent in the IDE to access ThoughtSpot SDKs and API documentation resources, and provide in-context coding assistance to developers embedding ThoughtSpot content within their applications. +ThoughtSpot introduces SpotterCode, an AI-powered Model Context Protocol (MCP) extension for Integrated Development Environments (IDEs) such as Cursor, Visual Studio Code, and Claude Code. When integrated, SpotterCode enables the AI agent in the IDE to access ThoughtSpot SDKs and API documentation resources and provide in-context coding assistance to developers embedding ThoughtSpot content within their applications. SpotterCode is available as an Early Access feature and can be integrated with development environments that support MCP servers and tools. For more information, see xref:spottercode.adoc[SpotterCode], xref:spottercode-integration.adoc[Integrating SpotterCode in IDEs], and xref:spottercode-prompt-guide.adoc[SpotterCode prompting guide]. @@ -32,7 +32,7 @@ To prevent excessive requests from reaching application servers and ensure API s For more information, see xref:about-rest-apis.adoc#_rate_limits_for_api_requests[Rate limits for REST APIs]. === Security settings via REST APIs -The security settings for ensuring data security and a seamless embedded user experience can now be done through REST APIs v2. Administrators and developers can configure allowlists for: +Security settings that ensure data security and a seamless embedded user experience can now be configured through REST APIs v2. Administrators and developers can configure allowlists for: * Content Security Policy (CSP) * Cross-origin Resource Sharing (CORS) @@ -59,14 +59,14 @@ For information about REST API v2 enhancements, see the xref:rest-apiv2-changelo === Theme Builder Theme Builder is now generally available (GA) and will be rolled out to all ThoughtSpot instances in customer deployments over the next few weeks. -When this feature is enabled on your instance, you can access it from the *Develop* page on your ThoughtSpot and use it to customize styles and UX themes directly within the product. +When this feature is enabled on your instance, you can access it from the *Develop* page in ThoughtSpot and use it to customize styles and UX themes directly within the product. For more information, see xref:theme-builder.adoc[Theme Builder]. === V3 navigation and home page experience The new V3 navigation and home page experience is now generally available (GA) and can be enabled on ThoughtSpot embedded instances. -The default UI experience in full application embedding remains classic (V1) experience until further notice. Developers embedding the full ThoughtSpot application can enable the V3 experience in their applications by setting the appropriate configuration options in their embed code. +The default UI experience in full application embedding remains the classic (V1) experience until further notice. Developers embedding the full ThoughtSpot application can enable the V3 experience in their applications by setting the appropriate configuration options in their embed code. For more information, see xref:full-app-customize.adoc[Customizing full application embedding]. @@ -79,9 +79,9 @@ For more information, see xref:abac_rls-variables.adoc[ABAC via RLS with variabl === Spotter APIs ThoughtSpot introduces new REST APIs for the following Spotter workflows: //* To get data source suggestions based on a user's query -* To send queries to a conversation session with Spotter agent -* To set natural language (NL) instructions on a Model to coach the Spotter system -* To fetch NL instructions configured on a Model +* To send queries to a conversation session with the Spotter agent +* To set natural language (NL) instructions on a model to coach the Spotter system +* To fetch NL instructions configured on a model For more information, see xref:spotter-apis.adoc[Spotter APIs]. @@ -106,7 +106,7 @@ For information about REST API v2 enhancements, see xref:rest-apiv2-changelog.ad == Version 10.14.0.cl === Code based custom actions -ThoughtSpot now enables developers to define custom action in their embed code through the Visual Embed SDK. This enhancement enables code based customization of actions for Liveboards, Visualizations, Answers, and Spotter. With this functionality, developers can add custom actions that show up as new menu options in one of the following UI elements: +ThoughtSpot now enables developers to define custom actions in their embed code through the Visual Embed SDK. This enhancement enables code-based customization of actions for Liveboards, Visualizations, Answers, and Spotter. With this functionality, developers can add custom actions that show up as new menu options in one of the following UI elements: * the primary menu bar * the **More** options menu image:./images/icon-more-10px.png[the more options menu] @@ -119,11 +119,11 @@ Key characteristics of code-based custom actions: * Can be assigned to Liveboards. * Can be conditionally displayed based on the presence of a specific column in a visualization. -For more information, see xref:code-based-custom-actions.adoc[Code based custom actions]. +For more information, see xref:code-based-custom-actions.adoc[Code-based custom actions]. === Webhooks for Liveboard schedule events [beta betaBackground]^Beta^ -You can now configure a xref:webhooks-lb-schedule.adoc[webhook for Liveboard schedule events] to automate notifications to external applications. This feature allows you to send Liveboard reports directly to a webhook endpoint and create your own custom emails or workflow. +You can now configure a xref:webhooks-lb-schedule.adoc[webhook for Liveboard schedule events] to automate notifications to external applications. This feature allows you to send Liveboard reports directly to a webhook endpoint and create your own custom emails or workflows. This feature is currently in beta and is not enabled by default. To enable it on your instance, contact ThoughtSpot Support. @@ -137,13 +137,13 @@ The `HostEvent.UpdateParameters` event in the Visual Embed SDK now includes the Before this enhancement, the Parameter chip display behavior was inconsistent across embed types when the Parameter values were updated via `HostEvent.UpdateParameters` requests. With the new change, the `isVisibleToUser` attribute in `HostEvent.UpdateParameters` is set to `false` by default for all embed types. -With the new enhancement, the embedded pages that previously kept the parameter chip visible after an override via `HostEvent.UpdateParameters` will now hide it unless the `isVisibleToUser` attribute is explicitly set to `true`. + +With the new enhancement, the embedded pages that previously kept the parameter chip visible after an override via `HostEvent.UpdateParameters` will now hide it unless the `isVisibleToUser` attribute is explicitly set to `true`. + This behavior may introduce a breaking change if your current implementation relies on the previous default chip visibility behavior. To retain chip visibility, developers must update their embedding implementation to pass `isVisibleToUser: true` in their `HostEvent.UpdateParameters` requests. For more information, see xref:runtime-parameters.adoc#_show_or_hide_parameter_chips_in_embedded_sessions[Runtime Parameter overrides]. === Pre-rendering enhancements -Pre-rendering now provides enhanced flexibility and granular control over for rendering embedded ThoughtSpot components. For more information, see xref:prerender.adoc[Pre-rendering ThoughtSpot Embed components]. +Pre-rendering now provides enhanced flexibility and granular control over rendering embedded ThoughtSpot components. For more information, see xref:prerender.adoc[Pre-rendering ThoughtSpot Embed components]. === Visual Embed SDK diff --git a/static/doc-images/images/agents-mcp-server-arch.png b/static/doc-images/images/agents-mcp-server-arch.png new file mode 100644 index 000000000..fc21c959c Binary files /dev/null and b/static/doc-images/images/agents-mcp-server-arch.png differ diff --git a/static/doc-images/images/rd-icon-chart-column.svg b/static/doc-images/images/rd-icon-chart-column.svg new file mode 100644 index 000000000..9f0cd2ecf --- /dev/null +++ b/static/doc-images/images/rd-icon-chart-column.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/static/doc-images/images/rd-icon-chart-type-settings.svg b/static/doc-images/images/rd-icon-chart-type-settings.svg new file mode 100644 index 000000000..40dc85ef4 --- /dev/null +++ b/static/doc-images/images/rd-icon-chart-type-settings.svg @@ -0,0 +1,3 @@ + + + \ No newline at end of file diff --git a/static/svgs/rd-icon-chart-column.svg b/static/svgs/rd-icon-chart-column.svg new file mode 100644 index 000000000..3258520ae --- /dev/null +++ b/static/svgs/rd-icon-chart-column.svg @@ -0,0 +1,7 @@ + + + + + + + \ No newline at end of file diff --git a/static/svgs/rd-icon-chart-type-settings.svg b/static/svgs/rd-icon-chart-type-settings.svg new file mode 100644 index 000000000..d04c6d8e0 --- /dev/null +++ b/static/svgs/rd-icon-chart-type-settings.svg @@ -0,0 +1,6 @@ + + + + + +