ThoughtSpot SpotterCode

Execute JavaScript against the connected ThoughtSpot cluster's REST API, server-side. This tool does not just describe operations — it PERFORMS them against the live cluster. When the user wants to actually DO something on their ThoughtSpot cluster — create/update/delete a user, group, org, connection, tag, or any other object; run a query and get real data back; or any concrete action rather than a "how does X work" explanation — use this tool to carry it out. Do not stop at explaining the steps or printing example code: after looking up the correct endpoint with get-rest-api-reference, offer to perform the action and, on the user's go-ahead, run it here. A how-to question ("how do I create a user?") is a good moment to answer AND offer to do it for them ("I can create it now — want me to?"). It is also ideal for multi-step API workflows (fetch several resources, cross-reference, aggregate, return a summary) that would otherwise take many tool round-trips. The code you pass is a self-contained async function BODY (not a full function): it can use `await` at the top level and must `return` the final value. A `ts` helper is provided for calling the cluster. Each returns { status, body }, where body is parsed JSON when the response is JSON (an object/array you can index directly), otherwise the raw response text: - await ts.get(path, query?) → { status, body } - await ts.post(path, body?) → { status, body } - await ts.request({ method, path, query?, body?, headers? }) → { status, body } Example — liveboards whose name mentions "sales": const res = await ts.post('/api/rest/2.0/metadata/search', { metadata: [{ type: 'LIVEBOARD' }], record_size: 100 }); const hits = res.body.filter((m) => m.metadata_name.toLowerCase().includes('sales')); console.log('matched', hits.length); return { count: hits.length, names: hits.map((m) => m.metadata_name) }; Rules: - Read operations always run. Each call is matched against an allowlist of known read-only ThoughtSpot endpoints; anything not on it counts as a write. That includes endpoints that only fetch data but are not recognised — e.g. one added in a newer cluster version — so a blocked call is not necessarily a mutation. - Write operations are blocked: the run aborts with status "confirmation_required", naming one blocked call as an example. Show the user the exact code, get their explicit approval, then re-invoke with confirm_write_operations: true — that approves ALL write calls the code makes, not just the named one. Never set confirm_write_operations: true without the user's explicit approval. - Note that creating a Spotter conversation or answer (/ai/**/create, /converse, /send) counts as a write, because it creates conversation state on the cluster. So does minting a token (/auth/token/**). - Raw fetch() is allowed but restricted to the connected cluster's origin; all other network access is blocked. - console.log/info/warn/error output is captured and returned in `logs` — use it to debug. - The returned value is JSON-stringified and truncated beyond a size cap; return small, specific values rather than raw API payloads. - Do not guess endpoint paths or schemas — look them up with get-rest-api-reference first.

Search ThoughtSpot Developer Docs and Developer Examples for embedding, Visual Embed SDK, theming, authentication concepts, configuration, deployment, and troubleshooting. IMPORTANT: Always call this tool before writing any ThoughtSpot embed or Visual Embed SDK code. Do not read node_modules, local SDK files, or rely on training data for SDK class names, config options, interface shapes, or property names — they may be outdated or lead to hallucinated properties. SDK enums, interfaces, and classes have exact, finite members — never guess them. Before writing code that uses a type's member, value, or property, call this tool with the `symbol` parameter (the bare type name, e.g. symbol: "Action") to fetch its authoritative definition and confirm the value exists. Use this tool whenever the user's question involves embedding ThoughtSpot or the Visual Embed SDK. This includes but is not limited to: - Embedding any ThoughtSpot component: LiveboardEmbed, SpotterEmbed, SearchEmbed, AppEmbed, SearchBarEmbed, or any other embed type - Working with Liveboards or Spotter in an embed context - Initializing or configuring any ThoughtSpot embed (init(), EmbedConfig, AuthType, etc.) - Customizing embed appearance — CSS, theming, hiding/showing UI elements, layout, or branding - Embed events, callbacks, listeners, or host-app communication (on(), EmbedEvent, HostEvent) - Authentication for embeds — AuthType, SSO, trusted auth, or token-based auth - Looking up any SDK type, interface, enum, config option, or prop - Custom actions — CustomAction, CustomActionsPosition, CustomActionTarget - Troubleshooting embeds — not rendering, auth failures, events not firing, styling problems - Embed patterns, auth flows, security concepts, configuration, theming, deployment For REST API endpoint paths, request/response schemas, REST API SDK methods, or REST API code examples, call get-rest-api-reference instead. If get-rest-api-reference is insufficient or the question spans REST API plus embedding/concepts, follow up with this tool.

Search ThoughtSpot REST API v2 documentation. Returns endpoint specs, request/response schemas, authentication details, and code examples for backend and server-side integration. IMPORTANT: Always call this tool before writing any ThoughtSpot REST API code. Do not rely on training data for endpoint paths, request body shapes, or auth mechanisms — they may be outdated or incorrect. Use this tool whenever the user's question involves the ThoughtSpot REST API or programmatic access to ThoughtSpot. This includes but is not limited to: - Calling any ThoughtSpot REST API endpoint (e.g., creating users, exporting Liveboards, fetching metadata, managing orgs) - REST API authentication — tokens, sessions, login, or any API auth mechanism - Any CRUD or management operation on ThoughtSpot objects via API — users, groups, orgs, tags, connections, data sources, or any other resource - Searching, querying, or extracting data from ThoughtSpot programmatically - Understanding request/response schemas, error codes, permissions, or rate limits for any endpoint - Using the ThoughtSpot REST API SDK in Java or TypeScript - Any question mentioning "API", "endpoint", "REST", or "programmatic" in the context of ThoughtSpot Pass 'apiName' to get the exact spec for a specific endpoint (e.g., apiName: "createUser"). Pass 'additionalDocs' as "java" or "typescript" to include SDK setup guides. Calling this once is usually sufficient — it returns the same docs each call. Use 'query' for semantic search when you don't know the exact endpoint name. If this tool returns no results or insufficient information, follow up with get-developer-docs-reference using the same query — it may have broader coverage on the topic. For frontend embed SDK code, use get-developer-docs-reference.