[aezell]

Summary

We are transitioning from the Sprites MCP at https://sprites.dev/mcp to the new Fly MCP server at https://mcp.fly.io. This moves the plugin to the new endpoint.

Part of superfly/sprites-ecosystem#184

What changed:

• .mcp.json: url is now https://mcp.fly.io; oauth.authorization_server_url is now https://fly.io/mcp/oauth. The server key (sprites), client_name, timeout, and scope (sprites:read sprites:write) are unchanged, so the mcp__sprites__* hook matcher, agent allowlist, and skill text keep working. Tool names are identical on both servers.
• scripts/check_repository.py and tests/test_repository.py: assert the new URL and authorization server.
• README.md, skills/sprites/references/auth-and-setup.md: new endpoint, an upgrade note, and updated allowlist guidance. The stale claim that the 401 omits WWW-Authenticate is replaced.
• docs/release-checklist.md: OAuth discovery steps rewritten for the new endpoint, plus a step to confirm Cortex accepts the pinned issuer.
• CHANGELOG.md: Unreleased entry.

Where the OAuth values come from (fetched 2026-11-13, not guessed):

• https://mcp.fly.io/.well-known/oauth-protected-resource returns resource: https://mcp.fly.io and authorization_servers: ["https://fly.io/mcp/oauth"]; scopes_supported includes sprites:read and sprites:write alongside fly:* scopes.
• https://fly.io/.well-known/oauth-authorization-server/mcp/oauth returns issuer https://fly.io/mcp/oauth, PKCE S256, and authorize, token, register, and revoke endpoints under https://fly.io/mcp/oauth/.
• An unauthenticated request to https://mcp.fly.io returns 401 with WWW-Authenticate: Bearer resource_metadata="https://mcp.fly.io/.well-known/oauth-protected-resource".

The plugin still requests only the two Sprites scopes. The Fly MCP can expose other Fly.io tools when broader scopes are granted; this plugin does not ask for them.

Action required outside this repository

• Snowflake administrators must allowlist the new URLs before users update. Managed environments that allow https://sprites.dev/mcp need https://mcp.fly.io (MCP endpoint) and https://fly.io/mcp/oauth (authorization, token, and registration endpoints) added. This applies to managed URL allowlists, connection profiles, and any network rule that restricts Cortex Code's outbound hosts. The README's Enterprise deployment section and the skill's troubleshooting reference now say so.
• Every existing user must re-authorize once. The two endpoints have separate OAuth grants; after updating, open /mcp and authorize sprites again.
• A release is still needed. The manifest version is left at 0.1.2 and the changelog entry is under Unreleased, because nothing in the validators requires them to agree. Cutting the release (version bump, tag, release-checklist run) is not part of this PR.

Verification

Ran locally:

• python3 scripts/check_repository.py: passed ("Validated 33 repository files and plugin semantics").
• python3 -m unittest discover -s tests: 11 tests, OK.
• python3 -m compileall -q scripts tests: OK.
• cortex plugin validate (Cortex Code v1.1.60): "Plugin 'sprites' is valid."
• The three live OAuth discovery requests listed above.

Not run, needs a manual test by a reviewer with a Cortex Code session:

1. Browser OAuth through Cortex with the pinned issuer. This is the main risk. The new issuer has a path (https://fly.io/mcp/oauth), and its metadata is served only at the RFC 8414 path-inserted location. https://fly.io/mcp/oauth/.well-known/oauth-authorization-server returns 404. If Cortex builds the metadata URL by appending /.well-known/... to authorization_server_url, authorization will fail. In that case the likely fix is to drop authorization_server_url and let Cortex follow the 401 challenge, which the new endpoint does send; that would also need the validator and test relaxed. I could not determine Cortex's behavior from this repository.
2. Whether Cortex's dynamic client registration is accepted by https://fly.io/mcp/oauth/register with client_name: "Cortex Code".
3. That the consent screen offers and grants sprites:read sprites:write only, and what restrictions it shows. The README and skill still describe the name-prefix and creation-cap restrictions from the previous connector; I softened the wording but did not verify the Fly consent screen.
4. /sprites-status and /sprites-smoke against a restricted grant in a non-production organization, and the hook gate on destroy_sprite (release checklist, "Safe end-to-end checks").
5. The tool list exposed in /mcp against the tool map in skills/sprites/SKILL.md and the release checklist. Both list 18 names dated 2026-08-12; I left them alone because I could not list tools without an authorized session. The hook matches every mcp__sprites__* call, so unlisted tools are still gated.

Left unchanged on purpose:

• Links to https://sprites.dev (product) and https://docs.sprites.dev/... (documentation, including the Remote MCP page). They are not the MCP endpoint. The Remote MCP documentation page may itself need updating; https://mcp.fly.io/guide.md is the public guide for the new endpoint.
• No headers were added to .mcp.json. Other Fly plugins send Fly-Client-Agent and Fly-Client-Interactive headers, but this repository's validator rejects any headers key on the server.

Checklist

• I kept this change focused and updated relevant documentation.
• I added or updated semantic tests where behavior changed.
• python3 scripts/check_repository.py passes.
• python3 -m unittest discover -s tests -v passes.
• cortex plugin validate passes, or I explained why it could not run.
• I did not include credentials, tokens, private data, or unredacted sensitive logs.
• I completed the relevant release-checklist steps for MCP, OAuth, hook, agent, command, or safety changes. (OAuth discovery steps 1-3 done; the Cortex runtime and end-to-end steps are not.)

🤖 Generated with Claude Code