execute-thoughtspot-code
ChatGPTExecute 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.





