license-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| --dir | No | Path to the project directory to inspect. May be specified multiple times; if omitted, the server may read the directory it was started in. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Answers 'what licenses are my dependencies under, and can I ship this?' from a project's lockfiles (uv.lock, poetry.lock, requirements.txt, package-lock.json, pnpm-lock.yaml, yarn.lock v1, Cargo.lock, go.sum), mostly offline: it reads the licenses of packages already installed in the project's venv / node_modules / cargo registry, then lockfile data, and only looks online if online=true. Every package reports where its license came from and UNKNOWN is never guessed. Start with license_inventory; use check_policy for ok / needs review / violation verdicts; compatibility and explain_license answer general license questions without touching files; generate_notices drafts THIRD-PARTY-NOTICES.md (returned as text); find_license_files lists which dependencies ship LICENSE/NOTICE files. Read-only. Guidance, not legal advice.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| license_inventoryA | List every dependency's license, grouped, with where each answer came from.
The output groups packages by normalised SPDX expression with direct/transitive counts,
lists UNKNOWN packages with the reason, shows dual-licensed (OR) packages and which option
applies ( |
| check_policyA | Give each dependency a verdict - ok / needs review / violation - with reasons. Policy comes from the arguments or from a Rules: deny beats allow; with an allow list, anything known and not on it is a violation;
otherwise, if |
| compatibilityA | Can code under Both accept SPDX ids/expressions or common spellings ('MIT', 'Apache 2', 'GPL-3.0-only', 'MIT OR Apache-2.0'); use 'proprietary' for a closed-source project. Answers compatible / conditional / incompatible / unknown from a small documented rule table (rule ids R1-R12 are cited), with the reasoning: e.g. Apache-2.0 into GPL-2.0-only is incompatible, into GPL-3.0 is fine; AGPL gets a network-clause note. A project offered under several licenses must be compatible with each option. Does not read any files. |
| explain_licenseA | Explain a license in plain words: what you can do, what you must do, and the limits. Accepts an SPDX id ('MIT', 'GPL-3.0-only'), a common spelling ('Apache 2'), a deprecated id ('GPL-2.0' is read as GPL-2.0-only), or an expression ('MIT OR Apache-2.0', 'GPL-2.0-only WITH Classpath-exception-2.0'). Covers about 50 common licenses from an embedded, hand-written table; for others it says so rather than guessing. Does not read any files. |
| generate_noticesA | Draft a THIRD-PARTY-NOTICES.md for the project's dependencies, returned as text (nothing is written). One entry per package: name, version, license, where the license came from, and copyright lines found in the package's installed LICENSE/COPYING files (or 'not found'). Packages with an UNKNOWN license are grouped under a heading so they cannot be missed. License texts are not embedded - copy them from the packages' own files (see find_license_files). Same license sources as license_inventory; copyright lines only exist for packages that are installed. |
| find_license_filesA | Show which dependencies ship a LICENSE / COPYING / NOTICE file in their installed copy. Looks in the project's venv dist-info (including PEP 639 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a clearly distinct task: inventory listing, policy verdicts, pairwise license compatibility, plain-language explanations, notice generation, and license-file discovery. The descriptions explicitly clarify boundaries, such as compatibility not reading files and check_policy applying a project policy. An agent should have no trouble selecting the right tool.
All tool names use consistent snake_case and are readable. Most follow a verb_noun pattern (check_policy, explain_license, generate_notices, find_license_files), while license_inventory is noun_noun and compatibility is a bare noun. Minor deviations only.
Six tools is well-scoped for a license-compliance server. Each tool covers a distinct part of the workflow and none appears redundant or like padding.
The surface covers the core license-compliance lifecycle: discover licenses, check project policy, assess pairwise compatibility, explain licenses, generate third-party notices, and locate license files. No obvious critical gaps remain for the stated purpose.