Dashform is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Dashform 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 · 57/100Comprehension
55% of score · 87/100What we found
- The scan target dashform.co does not resolve (connection timeout) — the live product, docs, and API all live at getaiform.com. An agent given only 'dashform.co' would hit a dead domain; the canonical entry point is getaiform.com.
- Dashform is built agent-first: a complete .well-known/mcp.json declares 8 tools with OAuth2 auth and one-click install snippets for Cursor, Claude Code, and Claude Desktop, and a rich 8KB llms.txt includes a numbered end-to-end agent workflow. An agent can discover, understand, and transact without ever touching a GUI.
- Discovery is dragged down by the absence of a traditional OpenAPI/Swagger spec (the highest-weighted check) — Dashform is MCP-native, not REST-first, so the machine-readable contract lives in mcp.json rather than an OpenAPI document the rubric looks for.
- No AGENTS.md exists in any public repo, and llms-full.txt returns HTTP 500 — two easy discovery wins are being left on the table by a company whose own product markets an 'AX Audit' agent-readiness scanner.
- Comprehension is strong (87/B): task-oriented tool descriptions, realistic copy-pasteable CLI examples with plausible IDs and ISO timestamps, clean markdown, and multiple multi-step workflow guides. An agent reading the docs would know exactly how to chain search → qualify → book.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Fix llms-full.txt — it currently returns HTTP 500. Serving valid comprehensive markdown here is a zero-cost discovery win (weight 1) and improves agent comprehension depth.
- 02Publish an OpenAPI 3.x spec for the webhook/CLI REST surface at a stable path (e.g. getaiform.com/openapi.json). This is the single highest-weighted discovery check (5) and would lift the Discovery score materially; the MCP tool schema already exists, so authoring an OpenAPI document is largely mechanical.
- 03Add an AGENTS.md to the primary public repos (mcp-server-dashform, dashform-cli-docs) with build/run/auth context for coding agents — a rising standard (weight 3) and trivial to author from existing README content.
- 04Redirect dashform.co (301) to getaiform.com so agents handed the brand domain don't hit a dead host. Currently the registered brand domain silently times out.
- 05Document the API error response format and rate limits explicitly — an error-code → recovery-step table (e.g. what to do on 401, 429, schema-validation failure) would turn the currently partial error-recovery and capability-boundary checks into passes.
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.
Authentication is well-documented for both surfaces — OAuth 2.1 with dynamic client registration for the MCP server, and x-api-key header for the CLI/webhook API. Error response format, rate limits, pagination, and idempotency are not documented; an agent would discover these behaviors only by calling the API. Plan-level quotas (responses/month, funnel counts) are documented in pricing but are not per-request rate limits.