Problem
The README describes OpenSEO as "All-in-one SEO tool for you and your AI agent" and claims "Best in class MCP and AI Skills". Both parts exist in the repo. Neither is discoverable from the domain. An agent that knows only openseo.so can't find the MCP server or the skills without a human reading the docs first and telling it where to look.
An independent agent readiness scan of https://openseo.so on 2026-07-30 returns level 1 of 5. Two of the failing checks are the two above:
- No MCP Server Card at
/.well-known/mcp/server-card.json, the surface SEP-1649 defines, while the server itself is real: src/server/mcp/server.ts, OAuth in oauth-provider.ts, streamable HTTP in transport.ts.
- No skills index at
/.well-known/agent-skills/index.json, the surface the Agent Skills Discovery RFC defines, while 15 skills ship in .agents/skills/, eight of them user facing SEO workflows: keyword-research, keyword-clustering, competitor-analysis, competitive-landscape, link-prospecting, seo-audit, seo-coach, seo-project-setup.
The install path for those skills today is prose at openseo.so/docs/skills/setup. An agent has to be told the location, and it has no digest to verify what it downloaded.
Implementation check
Checked main at 9d19e43.
src/routes/[.well-known]/openai-apps-challenge.ts already sets the pattern: one createFileRoute per well known path, a server.handlers.GET returning a Response with an explicit content type. Two more files follow it directly.src/server/mcp/public-origin.ts and urls.ts already resolve the public origin, so the card's transport endpoint doesn't need a new config value.skills-lock.json is a consumer side lockfile for the anthropics/skills webapp-testing skill, not a publish manifest, so the index digests have to be computed from .agents/skills/*/SKILL.md instead of read from it.
Scope
Two static unauthenticated GET routes. No DataForSEO calls, no schema change, no UI. The skills index needs its sha256 digests kept honest as the skill files change, so I'd add a test for that rather than hand maintain them. I may have missed a place where the index is already generated, in which case this is only a routing gap and the diff gets smaller.
Two findings I left out
The same scan reported /.well-known/api-catalog as status 500. I couldn't reproduce that status from a second source, only that the path renders the app's HTML 404 page, so the number stays out of this issue.
OAuth discovery metadata is also reported absent at the apex, but #47 shows Cloudflare Access serving resource_metadata at its own path on a hosted deployment. That one needs a maintainer's view of the deployment before it is worth filing.
Offer
I run a Cloudflare Workers site that serves both surfaces, a signed MCP server card and a skills index with digests, plus an MCP server on the current spec revision, so the specs are familiar ground. I can open a focused PR for both routes, or the skills index alone if you'd rather take them one at a time. Tell me which of the two you prefer and I'll open it against main.
Problem
The README describes OpenSEO as "All-in-one SEO tool for you and your AI agent" and claims "Best in class MCP and AI Skills". Both parts exist in the repo. Neither is discoverable from the domain. An agent that knows only openseo.so can't find the MCP server or the skills without a human reading the docs first and telling it where to look.
An independent agent readiness scan of https://openseo.so on 2026-07-30 returns level 1 of 5. Two of the failing checks are the two above:
/.well-known/mcp/server-card.json, the surface SEP-1649 defines, while the server itself is real:src/server/mcp/server.ts, OAuth inoauth-provider.ts, streamable HTTP intransport.ts./.well-known/agent-skills/index.json, the surface the Agent Skills Discovery RFC defines, while 15 skills ship in.agents/skills/, eight of them user facing SEO workflows:keyword-research,keyword-clustering,competitor-analysis,competitive-landscape,link-prospecting,seo-audit,seo-coach,seo-project-setup.The install path for those skills today is prose at openseo.so/docs/skills/setup. An agent has to be told the location, and it has no digest to verify what it downloaded.
Implementation check
Checked
mainat 9d19e43.src/routes/[.well-known]/openai-apps-challenge.tsalready sets the pattern: onecreateFileRouteper well known path, aserver.handlers.GETreturning aResponsewith an explicit content type. Two more files follow it directly.src/server/mcp/public-origin.tsandurls.tsalready resolve the public origin, so the card's transport endpoint doesn't need a new config value.skills-lock.jsonis a consumer side lockfile for theanthropics/skillswebapp-testingskill, not a publish manifest, so the index digests have to be computed from.agents/skills/*/SKILL.mdinstead of read from it.Scope
Two static unauthenticated GET routes. No DataForSEO calls, no schema change, no UI. The skills index needs its sha256 digests kept honest as the skill files change, so I'd add a test for that rather than hand maintain them. I may have missed a place where the index is already generated, in which case this is only a routing gap and the diff gets smaller.
Two findings I left out
The same scan reported
/.well-known/api-catalogas status 500. I couldn't reproduce that status from a second source, only that the path renders the app's HTML 404 page, so the number stays out of this issue.OAuth discovery metadata is also reported absent at the apex, but #47 shows Cloudflare Access serving
resource_metadataat its own path on a hosted deployment. That one needs a maintainer's view of the deployment before it is worth filing.Offer
I run a Cloudflare Workers site that serves both surfaces, a signed MCP server card and a skills index with digests, plus an MCP server on the current spec revision, so the specs are familiar ground. I can open a focused PR for both routes, or the skills index alone if you'd rather take them one at a time. Tell me which of the two you prefer and I'll open it against main.