Skip to main content

Ownership & verification

Ownership verification answers a narrow but important question: does the personal account or organization publishing an MCP server control the domain or repository the server claims?

It strengthens publisher and source evidence. It does not prove that every tool exposed by the server is safe.

Verification flow​

Choose the owner before creating proof​

Verification belongs to the active owner context. A proof created in your personal workspace does not automatically authorize an organization, and an organization proof does not become personal ownership.

1
Select Personal or an organization

Choose the context that should own and publish the server.

2
Verify the claimed domain

Use DNS TXT or well-known HTTPS for a reverse-domain namespace or other domain claim.

3
Connect the repository owner

Install the LightNow GitHub App and grant access to the repositories the selected owner is allowed to publish.

4
Publish from the same context

LightNow checks the namespace, repository and existing ownership before accepting the server version.

Verify a domain​

Open Profile → Ownership → Domains and choose Add domain. LightNow creates a verification token and renders the exact record or endpoint content for the selected method.

Domain proofDNS TXT

Publish the generated token as the requested TXT record. The token must match exactly; DNS propagation can delay verification.

Domain proofWell-known HTTPS

Serve the generated token from https://<domain>/.well-known/mcp-verification.json. LightNow requires an HTTPS response and the expected token value.

Domain verification can be pending, verified, failed or expired. A failed or expired proof must be corrected or recreated before it can support publishing.

Verify GitHub repository ownership​

Open Profile → Ownership → Repositories and install the LightNow GitHub App. Select only the repositories LightNow should be allowed to inspect and connect to the active owner context.

The connected repository list is the source for publish-time repository ownership checks. Repository visibility or an authenticated GitHub session by itself is not ownership proof inside LightNow.

What publishing checks​

Before accepting a server, LightNow evaluates the claims relevant to that manifest and active context:

  • whether the reverse-domain namespace is controlled by the publisher,
  • whether the referenced repository belongs to the selected owner,
  • whether an existing server is already owned by another context, and
  • whether the authenticated actor is allowed to publish for that context.

A publish failure is intentional when these claims conflict. Do not work around it by changing to an unrelated namespace or removing a repository link. Fix the owner context or proof that is actually wrong.

Ownership and trust are different​

Ownership proof is evidence about identity and control. Trust evaluation also considers other signals, such as endpoint security, source evidence, reputation, vulnerabilities and critical blocklist results.

A verified owner can still publish a server that needs security review. An unverified ownership claim can also force a cautious trust result even when the server otherwise looks mature.

Diagnose a failed claim​

  1. Confirm the active Personal or organization context.
  2. Confirm that the manifest domain and repository match the intended owner.
  3. Open the corresponding Ownership tab and inspect the current status.
  4. For DNS, query the exact requested record after propagation.
  5. For well-known HTTPS, request the exact path and inspect the returned token.
  6. For GitHub, confirm that the App installation includes the repository.
How-toPublish an MCP server

Validate artifacts and ownership before creating a Registry version.

ConceptRead the Trust Score

See how ownership evidence fits into the broader trust decision.

Ownership scopeChoose a context

Understand when an action belongs to you or to an organization.