Sampled via API fromChatGPTGoogle AI OverviewEach engine is shown on its own.
Demo with sample data
Sample result: a real scan of moatlight.com recorded on 5 Nov 2026, so you can see what the pass shows. Your scan will show your own site.
95of 100
Grade A+Scanned
Moatlight offers zero-auth API access and strong usability, and surfacing its official API docs and MCP server in search would round out agent discovery.
Essentials
100
The score for content sites, which skips API and payment checks.
Checks passing
103 of 113
33 not applicable to this site
Fixes to make
10
5 failing
Points available
+5.6
Ora's estimate, can change.
16of 20
14 of 17 raw points
30of 30
67 of 67 raw points
39of 40
128 of 130 raw points
Not scored for this site. It does not lower your score.
Why it matters
Can an agent find your developer resources with the searches it would really run? We search for your API docs and expect your own docs page among the results, then for your MCP server, SDK or CLI and, when you have one, expect your own page for it. Pages on other sites, including other companies with a similar name, don't count, unless your homepage or llms.txt links that site's docs, or your homepage redirects to a parent company's site and the page's address names your product. GitHub repos count only in an org your site links to.
What we found
In a search for your API docs, none of the 10 results is your official docs. In a search for your MCP server, SDK or CLI, none of the 10 results is your own, although the scan found one on your site
How to fix it
Make sure a web search for your product's API docs returns your own docs page, and a search for your MCP server, SDK or CLI returns your own pages for those tools. Keep docs on your own domain or a subdomain, or link your docs site from your homepage or llms.txt, give each tool its own page (for example /mcp) with the tool name in the title, put your product name and "API" in the docs title and main heading, and link your GitHub org from your homepage.
Why it matters
Can an agent go from discovering you to a first successful API call with no human in the loop? Every manual step is a place automated integrations quietly die.
What we found
Verified live: GET https://www.moatlight.com/api/v1/product answered 200 without credentials (zero-auth access). Described but not verified live: free tier available, self-serve key generation, sandbox/test environment
How to fix it
Offer a free tier or trial, self-serve API key generation, and a sandbox environment. Agents can't fill out 'contact sales' forms.
Why it matters
Official SDKs across ecosystems (npm, PyPI, Go). Each one is an integration an agent does not have to hand-roll, in the language it is already working in.
What we found
SDK packages found in npm, pypi
How to fix it
Publish official SDK packages across multiple language ecosystems (npm, PyPI, Go modules, RubyGems). Auto-generate them from your OpenAPI spec using tools like openapi-generator. For each package set the project URL or homepage to your product domain (package.json `repository`/`homepage`, PyPI `Home-Page` or `project_urls`, RubyGems `homepage_uri`) - this is how agents verify the package is your official SDK.
Why it matters
Official skills published on skills.sh, the public directory where agents and developers browse for ready-made capabilities.
What we found
No official skills self-published on skills.sh (69 community skills with potential relation to this domain found, but only self-published official skills count)
How to fix it
Publish agent skills on skills.sh so AI agents can discover your product's capabilities. Create a SKILL.md in your GitHub repo and register it with 'npx skills add'. See skills.sh/docs.
Why it matters
Not just listed on skills.sh, but worth installing: multiple skills, descriptive names, and real adoption.
What we found
No official skills on skills.sh to evaluate
How to fix it
Expand your skills.sh presence with multiple skill repos covering different use cases. Add descriptive skill names, clear SKILL.md files, and organize by capability area.
Why it matters
A Wikipedia article and Wikidata entry that link to your domain. Wikipedia is the largest single source of citations in AI answers (~48% of ChatGPT citations), so presence there decides whether AIs can verify who you are.
What we found
No Wikipedia article or Wikidata entity found for "moatlight" - creating a Wikipedia page and a Wikidata item with P856 = moatlight.com is the highest-impact step for AI search citation coverage
How to fix it
Establish a Wikipedia article and a Wikidata entity for your brand, with the domain set as the official website (Wikidata property P856) and a corresponding external link on Wikipedia. Wikipedia is the largest single source of citations in ChatGPT and a primary input to Knowledge Graphs across Google, Bing, and LLM training data. Earn third-party press coverage first to satisfy notability, then draft the article with cited references rather than self-promotion.
Why it matters
Listed in the ChatGPT app directory, where hundreds of millions of users can pull your product into a conversation by name. Upside-only: the directory is curated and gated, so absence never costs points.
What we found
Not found in ChatGPT app directory
How to fix it
Submit your app to the ChatGPT apps / connectors directory (the apps-in-ChatGPT surface) so ChatGPT users can discover and use your product.
Why it matters
A stripped-down, structured view of your site at ?mode=agent, built for machine readers: plain content and direct endpoint links.
What we found
Agent mode view found at ?mode=agent (6 signals: llms.txt, openapi, mcp, api, endpoint, agent)
How to fix it
Add a ?mode=agent query parameter to your homepage that returns a structured, machine-readable view with API endpoints, authentication info, and key capabilities instead of marketing HTML.
Why it matters
The machine-readable half of agent auth: discovery documents (RFC 9728 and 8414) with an agent_auth block that round-trips to your auth.md, so agents can look up the exact request shape for each supported identity type.
What we found
PRM + AS metadata cross-linked (AS metadata fetched from advertised origin https://www.moatlight.com) with agent_auth.identity_endpoint (https://www.moatlight.com/agent/identity) and identity_types_supported [service_auth] but agent_auth.skill (https://www.moatlight.com/auth.md) does not match the published /auth.md (https://moatlight.com/auth.md)
How to fix it
Publish RFC 9728 protected-resource metadata at /.well-known/oauth-protected-resource on your resource server (the host that actually serves the API, e.g. api.<apex>) with `resource` and `authorization_servers`. Publish RFC 8414 authorization-server metadata at /.well-known/oauth-authorization-server on the AS origin, and include the WorkOS auth.md `agent_auth` block with `identity_endpoint`, `identity_types_supported` drawn from the spec enum (`anonymous`, `identity_assertion`, `service_auth` - the assertion variant, the ID-JAG URN `urn:ietf:params:oauth:token-type:id-jag`, belongs inside `identity_assertion.assertion_types_supported`, not at the top level), and the `identity_assertion.assertion_types_supported` block when you advertise that type, so agents can check their assertion shape is accepted before minting. Cross-link by listing the AS origin in PRM `authorization_servers`, and point `agent_auth.skill` back at your published /auth.md. Spec: https://github.com/workos/auth.md.
Why it matters
A sandbox or test mode where agents can build an integration without touching production data. It lowers the stakes of every first call.
What we found
Sandbox/test environment mentioned at https://moatlight.com/auth.md but no sandbox surface verified
How to fix it
Provide a sandbox or test mode so agents can exercise your API without touching production data, and document how to reach it - this lowers the risk of a destructive call against live data.
ChatGPT
Google AI Overview