Required as a runtime environment for the Scancode License Analysis Tool (v18 or higher)
Used as a prerequisite for installing the Scancode License Analysis Tool dependencies
Used as the programming language for developing the Scancode License Analysis Tool
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Scancode License Analysis Tool for MCP show me files with GPL licenses"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project provides a set of tools built with the Model Context Protocol (MCP) TypeScript SDK. These tools help you analyze software licenses, specifically using data from a Scancode-generated license_analysis_detailed.json file. It's designed to make license compliance easier to manage by providing quick access to critical information about problematic licenses, affected files, and scan issues.
MCP is a standardized way for applications (like code editors or AI agents) to communicate with external services (like this license analysis tool). Think of it as a universal language that allows different software components to understand each other and work together, especially when dealing with large codebases or complex data.
Related MCP server: MCP SBOM Server
If you work with software projects, understanding the licenses of your dependencies is crucial for legal compliance. This tool helps you:
Quickly identify problematic licenses: See which licenses are a concern (e.g., copyleft, GPL, unknown).
Pinpoint affected files: Find out which specific files in your codebase are associated with these licenses.
Review scan issues: Understand if there were any problems during the license scanning process.
Get recommendations: Receive high-level guidance on how to address licensing concerns.
Generate file reports: Easily get the content of a specific file along with its associated problematic licenses, directly from the tool.
Before you get started, make sure you have the following installed on your system:
Node.js (v18 or higher): A JavaScript runtime. You can download it from nodejs.org.
npm: Node Package Manager, which comes with Node.js.
Follow these steps to set up and run your Scancode License Analysis Tool:
Clone this repository (if you haven't already): Open your terminal or command prompt and run:
git clone <your-repo-url> # Replace <your-repo-url> with the actual URL
cd <your-repo-directory> # Navigate into the cloned project folderInstall project dependencies: This command downloads all the necessary libraries and packages for the tool to run:
npm installEnsure your license_analysis_detailed.json file is present:
This tool relies on a license_analysis_detailed.json file generated by Scancode. Make sure this file is in the root directory of your project (where index.ts is located). This file contains the license scan results that the tools will analyze.
Configure TypeScript (Optional, but recommended for development):
A tsconfig.json file is already included and configured. It tells TypeScript how to compile your code. Key settings for this project include:
{
"compilerOptions": {
"module": "nodenext", // Ensures modern module resolution for Node.js
"target": "es2022", // Compiles to a recent JavaScript version
"outDir": "dist", // Output compiled JavaScript files to the 'dist' folder
// ... other settings for strictness and compatibility ...
},
"include": ["index.ts"] // Only compile this file
}Build the project (Compile TypeScript to JavaScript):
This step compiles your TypeScript code (.ts) into plain JavaScript (.js) files, which Node.js can execute. The compiled files will be placed in the dist/ directory.
npx tscYouYou have two main ways to run this tool:
tsx)tsx allows you to run TypeScript files directly without a separate compilation step, which is great for development and testing:
npx tsx index.tsAfter building your project (step 5 above), you can run the compiled JavaScript files from the dist/ directory:
node dist/index.jsTo integrate this tool with Cursor’s Model Context Protocol (MCP) feature, follow these steps:
Start your MCP server:
First, get your MCP server running using one of the methods above (e.g., npx tsx index.ts). This will keep the server active and listening for requests from Cursor.
Open Cursor and navigate to the MCP integration panel. In Cursor, look for the MCP panel (usually in the sidebar or a dedicated view).
Add a new MCP server connection: Click on the option to “Add MCP Server” or similar. You'll need to configure how Cursor connects to your running tool.
Connection Type: Select Stdio.
Command: Provide the command to start your server. This is the same command you used to run it in your terminal.
Example (for development): npx tsx C:\Users\Admin\Desktop\Dev\ScancodeMCP\index.ts
Example (for built version): node C:\Users\Admin\Desktop\Dev\ScancodeMCP\dist\index.js
(Optional) Environment Variables: You might want to add NODE_NO_WARNINGS: 1 under environment variables to suppress Node.js warnings.
Save and Connect. Once configured, save the connection. Cursor should automatically detect your tools and make them available in the MCP tool palette.
.cursor/mcp.json ConfigurationFor a permanent setup, you can add this tool directly to your Cursor's global or project-specific .cursor/mcp.json file. This file tells Cursor which MCP servers to automatically start and connect to.
Here's an example entry to add to your .cursor/mcp.json:
{
"mcpServers": {
"scancode-license-server": {
"command": "npx",
"args": [
"tsx",
"C:\\Users\\Admin\\Desktop\\Dev\\ScancodeMCP\\index.ts"
],
"env": {
"NODE_NO_WARNINGS": "1"
},
"disabled": false,
"autoApprove": [
"mcp_ScancodeMCP_analyze_license_file",
"mcp_ScancodeMCP_summarize_license_risks",
"mcp_ScancodeMCP_compare_license_compatibility",
"mcp_ScancodeMCP_list_high_risk_files",
"mcp_ScancodeMCP_get_license_clause_summary"
]
}
// ... any other MCP servers you have ...
}
}Adjust the args path: Make sure the C:\\Users\\Admin\\Desktop\\Dev\\ScancodeMCP\\index.ts path matches the actual location of your index.ts file.
autoApprove: This list tells Cursor which tools from your server can be automatically approved by the AI. This is convenient for frequently used tools.
After saving mcp.json, reload MCP servers in Cursor (there's usually a refresh button in the MCP panel). Your "Scancode License Analysis Tool" and its sub-tools will then be available in the MCP tool palette, ready to use!
Here are the tools provided by this server, designed to help with license compliance:
Tool Name | Description | How to Use (Example) |
| Clause-by-clause legal analysis of all licenses detected in a file, including obligations, risks, and compatibility. Supports analyzing multiple files and reading a configurable number of lines from each file. |
|
| Lists all files with high-risk/problematic licenses and provides a legal risk summary for each license type. |
|
| Legal compatibility verdict and explanation for two license types (e.g., MIT vs GPLv3). |
|
| Lists all files with copyleft, unknown, or commercial-unfriendly licenses, with a legal warning for each. |
|
| Clause-by-clause legal summary of a license (obligations, risks, compatibility, etc). |
|
MIT
#OpenSource #LicenseCompliance #LegalTech #Scancode #MCP #ModelContextProtocol #SoftwareLicenses #LicenseAnalysis #ComplianceTool #DeveloperTools #TypeScript #NodeJS #AutomatedLegal #CodeAnalysis
Clause-by-clause legal analysis of all licenses detected in a file, including obligations, risks, and compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| filePaths | Yes | An array of file paths to analyze. Can be a single file path for individual analysis. | |
| linesToRead | No | Number of lines to read from each file (default: 100). | |
| scannedDataBasePath | No | The base absolute path for resolving relative license paths (default: 'C:\Users\Admin\Desktop\LICENSE_MANAGER\'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'clause-by-clause legal analysis' but does not disclose behavioral traits such as computational intensity, rate limits, authentication needs, or what happens with invalid file paths. For a tool with no annotations and three parameters, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Clause-by-clause legal analysis') and lists key outputs. Every word earns its place with no redundancy or unnecessary details, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (legal analysis with 3 parameters) and lack of annotations and output schema, the description is incomplete. It covers the purpose but misses behavioral context, usage guidelines, and output details. It's adequate as a minimum viable description but has clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any meaning beyond what the schema provides (e.g., it doesn't explain how 'linesToRead' affects analysis or the purpose of 'scannedDataBasePath'). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('clause-by-clause legal analysis') and resource ('all licenses detected in a file'), with explicit outputs ('obligations, risks, and compatibility'). It distinguishes from sibling tools like 'compare_license_compatibility' and 'summarize_license_risks' by focusing on detailed file-level analysis rather than comparison or summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detailed license analysis in files, but does not explicitly state when to use this tool versus alternatives like 'get_license_clause_summary' or 'list_high_risk_files'. No guidance is provided on prerequisites, exclusions, or specific scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Legal compatibility verdict and explanation for two license types (e.g., MIT vs GPLv3).
| Name | Required | Description | Default |
|---|---|---|---|
| licenseA | Yes | First license name (e.g., MIT, GPL-3.0) | |
| licenseB | Yes | Second license name (e.g., Apache-2.0, GPL-2.0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool provides a 'verdict and explanation', which implies read-only analysis, but doesn't disclose behavioral traits like whether it requires network access, has rate limits, what format the explanation takes, or if it's authoritative for legal decisions. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded in a single sentence. Every word earns its place: 'Legal compatibility verdict and explanation' defines the output, 'for two license types' specifies the input scope, and the parenthetical example clarifies usage without redundancy. No wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (comparing legal licenses), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It states what the tool does but lacks details on output format, reliability, or integration context. It meets the bare minimum for a read-only analysis tool but doesn't fully compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds minimal value beyond the schema by implying the parameters represent license types for comparison, but doesn't provide additional semantics like valid license formats, case sensitivity, or handling of aliases. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to provide a 'legal compatibility verdict and explanation for two license types'. It specifies the verb ('compare'), resource ('license compatibility'), and scope ('two license types'). However, it doesn't explicitly differentiate from sibling tools like 'analyze_license_file' or 'summarize_license_risks', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this comparison is appropriate versus other license analysis tools. The example 'e.g., MIT vs GPLv3' hints at usage but lacks explicit when/when-not instructions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clause-by-clause legal summary of a license (obligations, risks, compatibility, etc).
| Name | Required | Description | Default |
|---|---|---|---|
| licenseName | Yes | The license name to summarize (e.g., MIT, GPL-3.0, unknown) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the output type ('legal summary') but doesn't specify format, depth, or limitations (e.g., coverage of known licenses, handling of unknown licenses, or potential errors). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place by specifying the action ('Clause-by-clause legal summary'), target ('of a license'), and key aspects ('obligations, risks, compatibility, etc.'). No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that produces legal summaries. It doesn't explain what the summary includes, its format, or how to interpret results. For a tool with potential complexity in legal analysis, more context is needed to understand its output and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'licenseName' well-documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., examples of license names or handling of edge cases). Baseline score of 3 is appropriate since the schema adequately covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Clause-by-clause legal summary of a license' with specific aspects like 'obligations, risks, compatibility, etc.' It distinguishes from siblings by focusing on detailed clause analysis rather than file analysis, comparison, or risk listing. However, it doesn't explicitly name the sibling tools for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a detailed legal breakdown of a license is needed, but doesn't explicitly state when to use this tool versus alternatives like 'summarize_license_risks' or 'compare_license_compatibility'. No exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all files with copyleft, unknown, or commercial-unfriendly licenses, with a legal warning for each.
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | No | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'legal warning for each' as a behavioral trait, but does not disclose other important aspects such as whether this is a read-only operation, potential performance impacts, data sources, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Lists all files with...') and includes the key detail about legal warnings. There is no wasted text, and it effectively communicates the tool's purpose in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (listing files with risk filtering) and lack of annotations and output schema, the description is moderately complete. It covers what the tool does and includes an output feature (legal warnings), but does not address return format, pagination, or error cases. It meets minimum viability but has clear gaps for a tool with no structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% coverage, but it's a dummy parameter ('random_string') for no-parameter tools. The description correctly indicates no meaningful parameters by not mentioning any, adding value beyond the schema by implying the tool operates without user inputs. This compensates well for the dummy parameter setup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Lists all files') with precise criteria ('with copyleft, unknown, or commercial-unfriendly licenses') and includes an additional output feature ('with a legal warning for each'). It distinguishes itself from siblings like 'analyze_license_file' or 'summarize_license_risks' by focusing on file listing with risk filtering rather than analysis or summarization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when identifying high-risk files based on license types, but does not explicitly state when to use this tool versus alternatives like 'summarize_license_risks' or provide exclusions. It offers some context but lacks clear guidance on prerequisites or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all files with high-risk/problematic licenses and provides a legal risk summary for each license type.
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | No | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists files and provides summaries, but does not cover critical aspects like whether it requires prior analysis, how it determines 'high-risk/problematic' licenses, output format, or potential side effects. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality ('Lists all files with high-risk/problematic licenses') and adds the summary aspect. Every word contributes directly to understanding the tool's purpose without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that likely produces complex data (license risk summaries), the description is incomplete. It lacks details on output structure, how risks are assessed, or dependencies on other tools. For a risk analysis tool with rich context needs, this minimal description does not provide sufficient completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, but it's a dummy parameter ('random_string') for a no-parameter tool. The description correctly implies no meaningful parameters are needed by not mentioning any, adding value beyond the schema by clarifying the tool's parameter-free nature. Baseline is 3 for high schema coverage, but the description compensates by aligning with the tool's actual usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Lists all files with high-risk/problematic licenses' and 'provides a legal risk summary for each license type'), distinguishing it from siblings like 'list_high_risk_files' by adding the summary component. It explicitly identifies the resource (files with problematic licenses) and the action (list and summarize).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or compare to sibling tools like 'list_high_risk_files' (which may only list without summarizing) or 'analyze_license_file' (which might focus on individual files). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
mcp_ScancodeMCP_analyze_license_filemcp_ScancodeMCP_compare_license_compatibilitymcp_ScancodeMCP_get_license_clause_summarymcp_ScancodeMCP_list_high_risk_filesmcp_ScancodeMCP_summarize_license_risksMost tools have distinct purposes: analyze_license_file examines a specific file's licenses, compare_license_compatibility checks two licenses, get_license_clause_summary details a single license, and list_high_risk_files and summarize_license_risks both identify high-risk files but with slightly different focuses (listing vs. summarizing). The overlap between list_high_risk_files and summarize_license_risks could cause minor confusion, but descriptions clarify their nuances.
All tool names follow a consistent pattern with the prefix 'mcp_ScancodeMCP_' and use snake_case for the action-object structure (e.g., analyze_license_file, compare_license_compatibility). This uniformity makes the set predictable and easy to navigate, with no deviations in naming conventions.
With 5 tools, the server is well-scoped for license analysis, covering key operations like analysis, comparison, summarization, and risk identification. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain's complexity and typical use cases.
The tool set covers core aspects of license analysis, including detailed examination, compatibility checks, and risk assessment. A minor gap exists in lacking tools for broader actions like batch processing multiple files or managing license databases, but agents can work around this with the provided tools for most workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Open-source licence risk checks for AI coding agents and dependency trees.
Generate, audit, and maintain legal policies that match what your code actually does.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bivex/scancodeMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
