Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, email [email protected] and we’ll put it right.

Declare an OSI-approved MCP server license

What we checked

We read your package manifest for a declared license and matched it against the list of OSI-approved licenses by its SPDX identifier. The outcomes are:

Clear OSI-approved license
The declared license is not a recognized OSI-approved license
License check failed: no license is declared.

Why it matters

Without a clear open-source license, the default legal position is “all rights reserved”: nobody actually has permission to use, modify, or redistribute your code, even if the source is public. For an MCP server, that’s a real adoption blocker: cautious teams won’t run code they have no license to run, and they can’t vendor or fork it to audit it. An OSI-approved license removes that doubt with a single, well-understood identifier, which is exactly why the package rubric rewards it.

How to fix it

Two things together: declare an OSI-approved license by its SPDX identifier in your manifest, and commit a matching LICENSE file at the repository root. The examples use MIT, but any OSI-approved SPDX identifier (Apache-2.0, BSD-3-Clause, MPL-2.0, GPL-3.0-or-later, …) works the same way.

{
"name": "your-mcp-server",
"license": "MIT"
}

Go has no manifest licence field; for Go modules, the LICENSE file itself is the declaration, which pkg.go.dev detects and displays from the repository.

How we re-check

We re-read the manifest (and the repository’s LICENSE file) on our next crawl. Once a recognised OSI-approved SPDX license is declared, the signal flips to a pass on the following score refresh.

Give this to your AI

Paste this into Claude Code (or any coding agent) from inside your server's repository. It states the failing signal, the outcome we re-check for, and the format the fix has to take.

Prompt
Context: this repository publishes an MCP server. VerifyMCP's license check
failed, which means the published package manifest declares no license, or
declares one that is not OSI-approved. Users therefore have no clear
permission to run, audit or fork the server.

Goal: the published manifest declares an OSI-approved license by its exact
SPDX identifier, and a matching LICENSE file sits at the repository root, so
the next crawl records an OSI-approved license.

Do this:
1. Identify the package ecosystem from the repository (package.json,
   pyproject.toml, *.csproj, Cargo.toml, go.mod) and read the current license
   declaration, if any.
2. Ask me which license to use if the repository does not already imply one.
   If a LICENSE file already exists, use the license it actually contains.
3. Set the manifest field to the exact SPDX identifier (for example `MIT`,
   `Apache-2.0`, `BSD-3-Clause`, `MPL-2.0`), not free text: `license` in
   package.json, `license` plus `license-files` in pyproject.toml (PEP 639),
   `<PackageLicenseExpression>` in the .csproj, `license` in Cargo.toml. Go
   modules have no manifest field, so the LICENSE file is the declaration.
4. Commit the full, unmodified license text as a LICENSE file at the
   repository root, and make sure it is the same license the manifest names.
5. Prepare the release, then stop and let me run the publish myself, since
   the check reads the published manifest.

Rules:
- Never run the publish command (`npm publish`, `twine upload`, `dotnet nuget
  push`, `cargo publish`, a release tag that triggers one) yourself. A
  published version is permanent and notifies every downstream consumer:
  prepare the change, show me the diff, and let me publish it.
- Never invent a license or change one that already exists without asking me,
  it is a legal decision, not a formatting one.
- Do not add a license file whose text disagrees with the manifest field.

Report back: the files you changed, the SPDX identifier you declared, and
confirmation that the manifest field and the LICENSE file agree.

Reference: https://verifymcp.io/docs/packages/license

Written by Stuart Blackler · Last reviewed 30 June 2026.