Why does mcp-publisher return 403 for a GitHub organization namespace?

If the 403 says you may publish only to io.github. /* while your server name is io.github. /*, the immediate failure is namespace authorization rather than server runtime behavior. Current MCP Registry documentation says GitHub auth can grant organization namespaces, but several open 2026 reports show interactive logins returning only the personal namespace even after public organization membership and fresh authentication.

What GitHub PAT permission does MCP Registry need for an organization namespace?

The current official GitHub Actions guide says a classic PAT needs read:org, while a fine-grained PAT needs Organization permissions > Members > Read-only and should be scoped to the organization being published for. A token without organization membership read access may grant only the personal namespace.

Can GitHub Actions publish an MCP server under an organization namespace?

Yes. The official publisher supports GitHub OIDC in Actions with id-token: write. The namespace is tied to the GitHub repository owner, so run the publishing workflow from a repository owned by the organization whose io.github. /* namespace you intend to use.

Should I switch to my personal MCP Registry namespace just to get past a 403?

Only if a personal namespace is the identity you actually want to maintain. Changing from io.github. /server to io.github. /server changes the public server identity; it is not merely an authentication retry and can create duplicate discovery records or migration work later.

Can I avoid GitHub authentication for an MCP Registry namespace?

Yes, for a custom-domain namespace. The official Registry supports DNS and HTTP ownership verification. Use that only when the domain-based namespace is the stable identity you want, rather than as a temporary way to publish the same server under a second name.

Editorial

Research guide · MCP Registry publishing

mcp-publisher 403: fix a missing GitHub organization namespace

If mcp-publisher publish validates your server but then says you can publish only under your personal io.github.<user>/* namespace, treat the permission list as the decisive clue. Do not burn time rewriting a valid server.json or create a second public identity just to get past the error.

Published and sources checked 13 September 2026

3 open reports

Independent 2026 org-namespace 403 reports remain open

1 decisive clue

The granted namespace list tells you whether auth is the blocker

0 identity shortcuts

Do not create a duplicate personal listing by accident

Error fingerprint

The 403 can tell you exactly what is missing

Multiple current Registry reports show the same shape: validation succeeds, publishing returns HTTP 403, and the error says the token can publish only to the user namespace while the requested name belongs to a GitHub organization. In that state, repeatedly editing package metadata is low-value because the authorization grant does not include the requested owner.

mcp-publisher validate
# passes

mcp-publisher publish
# 403 Forbidden
# You do not have permission to publish this server.
# You have permission to publish: io.github.<user>/*
# Attempting: io.github.<org>/server

Six-step diagnosis

Separate server metadata from namespace authorization

Validate before debugging auth

Run mcp-publisher validate against the intended server.json. A clean validation plus a publish-time 403 narrows the failure to authorization or namespace ownership rather than schema shape.

Read the permission list literally

The 403 response commonly states the namespaces currently granted. If it lists io.github.<user>/* but not io.github.<org>/*, stop changing package metadata: the publisher token does not currently carry the organization namespace.

Confirm the exact public identity

Check that server.json uses the organization name you intend to keep, with the correct spelling and case. Do not silently substitute a personal namespace just because it publishes.

Check organization visibility and role

For GitHub interactive auth, confirm the relevant organization membership is public and that the account has the ownership level required by the Registry. Then perform one fresh logout/login cycle.

Escalate auth method, not retries

If a fresh interactive login still returns only the personal namespace, use a documented organization-capable path: a PAT with organization membership read permission, GitHub Actions OIDC from an organization-owned repository, or an intentionally chosen custom-domain namespace.

Verify the published record

After a successful publish, query the Registry for the exact canonical server name. A local success message is not enough; verify that the intended organization identity is the one clients can discover.

Supported organization auth paths

Use a documented owner-aware credential instead of looping OAuth

PAT

Read organization membership

The current official GitHub Actions guide says a classic PAT needs read:org. A fine-grained PAT should be scoped to the organization and grant Members → Read-only. The CLI accepts a PAT through mcp-publisher login github --token=....

GitHub OIDC

Publish from the organization-owned repo

The official CI path uses mcp-publisher login github-oidc with id-token: write. The granted GitHub namespace is derived from the repository owner, so the workflow repository itself must be owned by the organization you intend to publish under.

DNS / HTTP

Choose a stable domain namespace

The Registry also supports DNS and HTTP proof for custom-domain namespaces. This is useful when a domain is the desired durable identity, but changing namespaces just to bypass one failed login creates a different public server identity.

Keep PATs, private keys and OIDC tokens out of source files, logs and issue reports. Use the minimum documented organization-read permission and the repository or environment secret controls appropriate to your CI setup.

Current evidence

Why this is not just a one-off typo

The official CLI reference currently says GitHub interactive authentication grants access to both personal and organization io.github.* namespaces. However, three separate open Registry issues from July and August 2026 report organization publishing returning 403 even after public membership and re-authentication. Two reports explicitly show the permission set remaining personal-only.

That does not prove every interactive login is broken. It does mean the practical diagnostic should trust the permission list returned by the Registry rather than assuming that public membership alone guarantees the organization namespace was actually granted.

Official mcp-publisher CLI reference →Official GitHub Actions auth guide →Registry issue #1468 →Registry issue #1537 →Registry issue #1551 →

After the fix

Verify the exact identity that agents will discover

A successful publish should be followed by a Registry lookup for the exact canonical name. Check the organization namespace, server version and endpoint/package metadata that clients will consume. Do not count a CLI success message, directory row or crawler hit as a real visitor, installation or paid conversion.

curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=io.github.<org>/<server>"

Continue the implementation path