Arcade.dev

PASS consensus from 3 PASS.

The quickstart covers account and API-key prerequisites, Python installation, authorization waiting, execution, and `uv run main.py`. One page carries the whole path in Python, TypeScript, and Java: account signup, API key, uv add arcadepy, client construction, client.tools.authorize, client.auth.wait_for_completion, client.tools.execute, uv run main.py, and the expected terminal output. The quickstart provides a complete from-zero path: sign up, get API key via the linked page, install arcadepy, and call any Arcade-hosted tool via authorize/wait_for_completion/execute with a full working example.

FAIL consensus from 1 PARTIAL, 2 FAIL.

The docs mention shared provider limits but give no exact API or plan numbers, and `llms-full.txt` returned 404. No page on docs.arcade.dev states a rate-limit number or a plan quota: the Arcade API Reference is three sentences with no limits section, api.arcade.dev/v1/swagger defines no 429 response for /v1/tools/execute or /v1/tools/authorize, and the only published figure (1,000 API calls per minute) lives on the marketing blog, whose free-tier quotas contradict the current pricing page. Only the audit-logs API rate limit (100 req/60s/IP) and MCP notification rate limit (60/min/client configurable 1-1000) are documented in the docs. No general tool-execution API rate limit or plan-level quotas appear anywhere in the docs; plan quotas are on the marketing site only.

PASS consensus from 3 PASS.

The example identifies the error, converts `retry_after_ms` from milliseconds to seconds, and tells the caller to wait and retry. The error kind, the retry_after_ms field, the millisecond-to-second conversion, and the retry action are all on one page in three languages, though retry_after_ms is optional in the tool.Error schema and only the Java sample guards against its absence. The error-handling docs document UPSTREAM_RUNTIME_RATE_LIMIT as an OutputError.Kind enum value and show how to use retry_after_ms to wait before retrying, with code examples in Python, TypeScript, and Java.

PASS consensus from 2 PASS, 1 PARTIAL.

The dashboard guide creates the extension and hook configuration, while the webhook contract defines `POST /access` and both auth forms. Endpoints, payload tables, response codes, failure modes, and retry rules are fully specified and the bearer-token path is usable, but mTLS is one sentence with no certificate issuance, trust, or rotation detail, the canonical OpenAPI spec declares only bearerAuth, and the two setup pages name the dashboard location differently (Contextual Access versus Logic Extensions → Hook Points). The contextual access documentation covers the complete webhook extension lifecycle: OpenAPI spec, endpoint implementation (POST /access, /pre, /post), bearer token or mTLS authentication configurable in the Dashboard, hook configurations with scoping and failure modes, and runnable Go example servers.

PASS consensus from 2 PASS, 1 PARTIAL.

The quickstart and OpenAPI agree on `tool_name`, `input`, and `user_id`; tested `.md` variants returned HTML fallbacks. The official Python client is arcadepy (pip install arcadepy on the References page) and its tool_name/input/user_id arguments match the REST schemas.ExecuteToolRequest and schemas.AuthorizeToolRequest exactly, but the quickstart passes auth_response.id to wait_for_completion while the Authorized Tool Calling, FAQ, and error-handling pages pass the auth_response object, and no page says which is correct. The Python SDK (arcadepy) is documented with an install command (uv add arcadepy), import example, and a complete authorize-and-execute flow that matches the tool API form used consistently throughout the docs.