OctagonAI is Good to agents.
Discry independently scored how well an AI agent can discover and understand the OctagonAI 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 · 62/100Comprehension
55% of score · 91/100What we found
- An agent that finds Octagon lands in strong shape: the API is OpenAI-compatible, so any agent already fluent in the OpenAI SDK can call Octagon's specialized financial-research agents by swapping only the base_url — comprehension scored 91/100 (A).
- Discovery drags the overall to a B (62/100, C): there is no publicly accessible OpenAPI/Swagger spec — the single highest-weighted discovery signal — so an agent cannot machine-generate a typed client and must infer the surface from prose docs.
- The docs domain (docs.octagonai.co) ships a genuinely API-focused llms.txt (~21KB) with runnable Python/JS/cURL examples, and its robots.txt explicitly allows GPTBot and OAI-SearchBot — an agent crawler is welcomed rather than blocked.
- The Kalshi REST reference is a standout for agents: task-oriented endpoint descriptions, parameter tables with defaults/min/max, base64 cursor pagination, and an explicit error Status/Cause table — so an agent can compose calls and interpret failures without guessing.
- Octagon is MCP-native: official first-party octagon-mcp-server and octagon-deep-research-mcp repos are listed across multiple MCP registries (mcpmarket, FlowHunt, AgentX, Metorial), so agents can discover and wire up Octagon from inside an MCP session — but no substantive AGENTS.md exists in those repos (the hosted CLAUDE.md is a one-line placeholder).
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a public OpenAPI/Swagger spec at a stable path (e.g. docs.octagonai.co/openapi.json) and link it from the docs — the single highest-impact discovery fix, moving the heaviest-weighted check (weight 5) from fail toward pass and letting agents auto-generate typed clients.
- 02Add a real AGENTS.md to the octagon-mcp-server and octagon-deep-research-mcp repos (agents, model IDs, auth, safe usage), replacing the trivial hosted CLAUDE.md — a rising standard that coding agents look for first.
- 03Document rate limits and 429/Retry-After behavior; today an agent would only discover throttling by failing at runtime with no recovery guidance.
- 04Extend the existing error Status/Cause table with explicit per-error recovery steps (e.g. 'on 503, retry after nightly sync populates the table'; 'on 422, correct the named field') to move error handling from human-readable to agent-actionable.
- 05Add a dedicated capability-boundaries/limits page (max page sizes, data freshness/coverage, unsupported query combinations) so agents can plan within constraints rather than probing them by failing.
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.
Auth is a single API-key Bearer token, documented cleanly via the OpenAI-compatible SDK pattern (swap base_url to https://api.octagonai.co/v1). The REST surface (Kalshi search/baskets, events) documents a machine-parseable error model with an explicit Status/Cause table (400 bad params, 401 auth, 422 Pydantic validation, 502 upstream, 503 unavailable) and base64 cursor pagination with limit/cursor/next_cursor and documented min/max/default page sizes. No rate limits or 429/Retry-After semantics are documented anywhere, and idempotency keys are not mentioned. Execution characteristics were assessed from documentation only, not live-tested.