Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
--dirNoPath 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
license_inventoryA

List every dependency's license, grouped, with where each answer came from.

path is a project directory (lockfiles are found up to 3 levels down) or one lockfile. License sources, in priority order: (1) packages already installed - a Python venv at .venv/venv next to the lockfile, or the one you give as python (a venv dir, its python executable, or a site-packages dir), node_modules, ~/.cargo/registry; (2) data in the lockfile itself (package-lock.json has it); (3) a network lookup against PyPI / npm / crates.io, ONLY if online=true. Anything none of these answers is UNKNOWN - never guessed.

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 (allow is an optional list of SPDX ids you accept; otherwise the least restrictive option is shown), and flags ambiguous spellings such as plain 'BSD'.

check_policyA

Give each dependency a verdict - ok / needs review / violation - with reasons.

Policy comes from the arguments or from a .license-policy.toml in path (arguments win, key by key). Entries in allow/deny are SPDX ids ('MIT', 'GPL-2.0' is read as GPL-2.0-only), wildcards ('BSD-*'), or category names: public-domain, permissive, weak-copyleft, strong-copyleft, network-copyleft, source-available, noncommercial, restricted, proprietary. The TOML file may also hold project_license = "..." and an [exceptions] table mapping a package name (or name@version) to the reason you accepted it.

Rules: deny beats allow; with an allow list, anything known and not on it is a violation; otherwise, if project_license is given, each dependency is judged by the compatibility table (compatible = ok, conditional = needs review, incompatible = violation); with neither, permissive licenses are ok, weak copyleft (LGPL/MPL/EPL) needs review with linking notes, and strong/network copyleft, source-available and non-commercial licenses are violations. UNKNOWN and unclassified licenses always need review. OR expressions take the best option for you, AND expressions the worst. Same license sources as license_inventory.

compatibilityA

Can code under dependency_license be used in a project licensed project_license?

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 licenses/), node_modules package directories and ~/.cargo/registry. Lists packages with files (flagging NOTICE files you must reproduce under Apache-2.0), packages installed without any license file, and packages with no installed copy to inspect. Offline only.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 6 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues