ThoughtSpot is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the ThoughtSpot API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.
SCORED UNDER RUBRIC 1.2 · A full re-launch under Discry Score 2.5 — a new behavioral instrument, not comparable to these scores — is in progress.
Discovery
45% of score · 45/100Comprehension
55% of score · 85/100What we found
- An agent evaluating ThoughtSpot's REST API v2 would find genuinely agent-friendly reference docs: endpoint descriptions are task-oriented ('Provides a token to access a specific metadata object'), examples use realistic values (real GUIDs, token payloads, snake_case fields), and every top HTTP error code ships with an explicit recovery action — the comprehension layer scores a B (85/100).
- A publicly accessible OpenAPI spec exists in the official github.com/thoughtspot/rest-api-sdk repo (api-spec directory) alongside a hosted REST v2 Playground, so an agent can retrieve a machine-readable contract without an account.
- ThoughtSpot ships an official MCP server (github.com/thoughtspot/mcp-server, listed on Glama) plus a 'SpotterCode' docs-MCP plugin for Claude Code/Cursor — strong signals that agent-based access is a first-class use case.
- Discovery is the weak spot (D, 45/100): there is no llms.txt, no llms-full.txt, no .well-known/mcp.json, and no AGENTS.md in any primary repo. The developer-docs subdomain also serves no robots.txt of its own, so an agent gets no LLM-optimized entry point despite the good underlying docs.
- Docs are Gatsby JS-rendered with no markdown content-negotiation or llms.txt, so an agent must render/scrape HTML to extract the (otherwise clean) content — it converts well, but nothing is pre-optimized for machine consumption.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an llms.txt at developers.thoughtspot.com/llms.txt with a title, description, and curated links to the REST v2 getting-started, reference, authentication, and pagination pages — the single highest-impact discovery fix given the docs quality already present.
- 02Add an AGENTS.md to the primary public repos (mcp-server, rest-api-sdk, visual-embed-sdk) pointing coding agents at the REST v2 spec, auth flow, and SDK entry points.
- 03Surface the OpenAPI spec at a stable, discoverable URL (e.g. developers.thoughtspot.com/openapi.json) and link it from the docs, rather than requiring agents to locate it inside a GitHub SDK repo.
- 04Publish concrete rate-limit numbers and the associated response header names (and any Retry-After behavior) so agents can back off correctly instead of discovering limits only by failing.
- 05Add a .well-known/mcp.json (and/or an llms-full.txt) to formalize the already-existing MCP offering as a machine-discoverable capability declaration.
Execution coverage · INFORMATIONAL, UNSCORED
Whether an agent can actually complete a call and recover from errors is the deeper Audit layer — documented here, but not part of the Discry Score.
Execution characteristics are well documented: token-based auth (with OAuth 2.0, trusted-auth, and basic-auth options), standard HTTP status codes, and a machine-parseable JSON error object (root > error > message > debug). Pagination is documented via record_offset/record_size with a stated 100,000-row ceiling. Rate limiting is acknowledged but specific numeric limits and header names are not published. No idempotency-key support is mentioned.