# Localhost Direct — API Agent Score

> Score: 55/100 (Grade: D) | Domain: localhost.direct | Rubric: 1.0.0 | Checked: November 10, 2026

Localhost Direct scored 55/100 (D), classified "not-ai-ready".

[View full report](https://www.postman.com/ai/ai-ready-apis/company/localhost)
[All organizations](https://www.postman.com/ai/ai-ready-apis/llms.txt)

## Summary

- Overall: 55/100 (D)
- Classification: not-ai-ready

## Category Scores

- API Design: 79/100 (B)
- Developer Experience: 43/100 (F)
- Agent Discovery: 71/100 (B)
- Agent Understanding: 54/100 (D)
- Agent Usability: 41/100 (F)

## Check Results

### API Design

- [pass] Auth declared & discoverable — Authentication is required across the API (declared globally or on every operation), so an agent knows credentials are needed. Investigated: spec 100%, docs 100%.
- [warn] Machine-readable, versioned contract — The API sets a version ("1.0.0") but exposes no versioning scheme in the URL, a header, or the media type, so an agent can't pin to a specific version. Investigated: spec 75%, docs 50%.
- [warn] Schema coverage & depth — Only 0% of the 3 operations document request and response schemas, so an agent can't do function-calling against most endpoints. Investigated: spec 67%.
- [pass] Security & governance hygiene — No credential-shaped strings detected in spec. Investigated: spec 100%, wellknown 0%.
- [fail] Example coverage — No parameters or responses are defined to attach examples to, so example coverage can't be measured. Investigated: spec 0%, docs 0%.

### Developer Experience

- [pass] Description completeness — Only 83% of operations and parameters have substantive descriptions (2 of 3 ops, 0 of 0 params; target 90%+). Investigated: spec 100%.
- [fail] Self-service developer portal — No self-service signup detected — no signup link on the homepage or docs, and no conventional signup path (/signup, /sign-up, /register, /get-started, /console/signup, /dashboard/signup, /try, /try-free, /free, /free-trial, /start, /start-free, /join, /create-account, /account/signup, /auth/signup, /users/sign_up) resolved — so an agent can't onboard on its own. Investigated: docs 0%.
- [fail] Quickstart present — No quickstart or getting-started page found at the conventional docs paths, so new developers and agents have no obvious first step. Investigated: docs 0%.
- [fail] Code samples in docs — No code samples detected across 1 sampled docs pages, so a coding agent gets no ready-to-use examples. Investigated: docs 0%.
- [fail] Changelog published — No changelog link or mention appears in the spec, so an agent can't tell what changed before something breaks. Investigated: spec 0%, docs 0%.

### Agent Discovery

- [pass] Docs reachable, not hard auth-gated — All 1 pages are publicly accessible. Investigated: docs 100%.
- [pass] Registry & SDK presence — Indexed on Context7 (openai/tunnel-client, 1687 snippets). Investigated: docs 100%, sdk 100%, cli 0%.
- [warn] Crawlable / AEO — No sitemap found via robots.txt or /sitemap.xml on the docs host, so AI search engines have no crawl map for your docs. Investigated: wellknown 50%.
- [fail] llms.txt present, valid & comprehensive — No llms.txt found at any candidate location (https://get.localhost.direct/llms.txt, https://get.localhost.direct/docs/llms.txt). Investigated: docs 0%.

### Agent Understanding

- [pass] Agent-navigable, token-efficient docs — All 1 pages contain server-rendered content. Investigated: docs 100%.
- [warn] Operation purpose clarity — Only 67% of operations (2 of 3) have both a clear summary and a descriptive name (target 90%+), so an agent may pick the wrong endpoint for the rest. Investigated: spec 50%.
- [fail] Machine-readable errors (RFC 9457) — No error responses (4xx/5xx or a catch-all default) are documented anywhere in the spec, so an agent can't anticipate or handle failures. Investigated: spec 0%, docs 0%.
- [fail] Agent instructions file (AGENTS.md) — No AGENTS.md at the site root or /.well-known/, so coding agents have no ready-made setup and usage instructions. Investigated: wellknown 0%.
- [fail] Docs structured data — No JSON-LD or OpenGraph/meta tags found across 1 assessed pages (1 JS-rendered), so answer engines have nothing to cite. Investigated: docs 0%.
- [skip] Description consistency across surfaces — Only 1 surface description(s) with ≥6 tokens available; need at least 2 to compare.

### Agent Usability

- [warn] Runnable collection with test scripts — No test scripts found in the workspace's public collections, so an agent can't use them to verify API behavior. Investigated: platform 50%.
- [fail] Idempotency documented — Only 0% of mutating operations (0 of 1) document idempotency, so an agent's retries can create duplicate writes. Investigated: spec 0%, docs 0%.
- [fail] Rate-limit signaling — No rate-limit response headers are documented, so an agent can't tell when it is approaching a limit and will get throttled. Investigated: spec 0%, docs 0%.
- [fail] Sandbox separation — None of the 1 declared server(s) is a sandbox/test host, and no test-key prefixes are documented, so agents can only hit production. Investigated: spec 0%, docs 0%.
- [skip] Pagination documented & consistent — No surface produced evidence for this capability in this run.

## Executive Summary

Localhost's API program has a solid machine-readable contract and crawlability foundation, but partners and their agents currently have no self-service path to get started — no portal, no quickstart, no code samples, and no sandbox — making onboarding dependent on direct engagement rather than self-service discovery. Agent usability is equally urgent: missing error semantics, idempotency guidance, rate-limit signaling, and sandbox separation mean any agent attempting real workflows risks silent failures and duplicate writes. Prioritize standing up a discoverable, runnable developer experience first, then close the agent-understanding gaps so partners and their agents can operate confidently without hand-holding.