mcp-shellcheck
ShellCheck MCP Server
A Model Context Protocol (MCP) server that provides shell script linting via ShellCheck. Allows AI agents to analyze shell scripts for common errors, stylistic issues, and potential bugs.
MCP Server Profile
{
"name": "mcp-shellcheck",
"description": "A Model Context Protocol (MCP) server that provides shell script linting via ShellCheck for AI coding assistants",
"tools": [
{
"name": "shellcheck",
"description": "Run ShellCheck on a shell script to find bugs, stylistic issues, and potential errors",
"inputSchema": {
"type": "object",
"properties": {
"file_path": { "type": "string", "description": "Path to the shell script file to check" },
"script_content": { "type": "string", "description": "Raw shell script content to check" },
"shell": { "type": "string", "description": "Shell type to check", "enum": ["bash", "sh", "dash", "ksh", "ash"] },
"check_sourced": { "type": "boolean", "description": "Enable checks for sourced files" },
"enable_all": { "type": "boolean", "description": "Enable all optional checks" },
"exclude": { "type": "string", "description": "Comma-separated list of warning codes to exclude" },
"severity": { "type": "string", "description": "Minimum severity to report", "enum": ["error", "warning", "info", "style"] }
}
}
},
{
"name": "shellcheck_info",
"description": "Get information about the ShellCheck version and server capabilities",
"inputSchema": {
"type": "object",
"properties": {}
}
}
]
}Related MCP server: sql-sop-mcp
Quick Install
# Run via uvx from PyPI
uvx --from mcp-shellcheck shellcheck-mcp-server
# Run via uvx from GitHub release
uvx --from https://github.com/Ev3lynx727/mcp-shellcheck/releases/download/v0.1.3/mcp_shellcheck-0.1.3-py3-none-any.whl shellcheck-mcp-server
# One-liner install (install.sh)
curl -fsSL https://raw.githubusercontent.com/Ev3lynx727/mcp-shellcheck/main/install.sh | sh
# Install from PyPI
pip install mcp-shellcheck
# Clone and dev install
git clone https://github.com/Ev3lynx727/mcp-shellcheck.git
cd mcp-shellcheck && pip install -e .Features
File-based analysis: Check shell scripts by file path
Inline script checking: Analyze raw shell script content directly
Multiple shell support: bash, sh, dash, ksh, ash
Configurable checks: Exclude specific warnings, set severity levels
Structured output: JSON-formatted results for easy parsing
OpenCode integration: Ready to use with OpenCode agents
Production-ready: Async, tested, validated, logged
Requirements
Python 3.10+
ShellCheck installed on the system
Installing ShellCheck
Recommended (always latest):
pip install shellcheck-pyThe shellcheck-py package provides a pre-built shellcheck v0.11.0 binary on your PATH with no system dependencies.
System package managers (may ship older versions):
# Ubuntu/Debian
sudo apt-get install shellcheck
# macOS
brew install shellcheck
# Fedora/RHEL
sudo dnf install ShellCheck
# Arch Linux
sudo pacman -S shellcheckTools
shellcheck
Run ShellCheck on a shell script to find bugs, stylistic issues, and potential errors.
Parameters:
Parameter | Type | Required | Description |
| string | No* | Path to the shell script file |
| string | No* | Raw shell script content |
| string | No | Shell type: bash, sh, dash, ksh, ash (default: bash) |
| boolean | No | Enable checks for sourced files (default: false) |
| boolean | No | Enable all optional checks (default: false) |
| string | No | Comma-separated codes to exclude (e.g., "SC1090,SC2148") |
| string | No | Comma-separated codes to include (e.g., "SC2086,SC2164") |
| string | No | Minimum severity: error, warning, info, style |
*Either file_path or script_content must be provided.
Common error codes:
Code | Description | Severity |
SC1090 | Can't follow non-constant source | info |
SC2086 | Double quote to prevent globbing | warning |
SC2164 | Use cd with || exit | warning |
SC2006 | Use $(...) instead of legacy backticks | style |
shellcheck_info
Get ShellCheck version and server capabilities.
Parameters: None
Configuration
OpenCode
{
"mcp": {
"shellcheck": {
"type": "local",
"command": [
"uv",
"run",
"--with", "mcp",
"python3",
"/path/to/mcp-shellcheck/shellcheck_mcp_server.py"
],
"enabled": true,
"timeout": 60000
}
}
}OpenCode (uvx from GitHub release)
{
"mcp": {
"shellcheck": {
"type": "local",
"command": [
"uvx",
"--from", "https://github.com/Ev3lynx727/mcp-shellcheck/releases/download/v0.1.3/mcp_shellcheck-0.1.3-py3-none-any.whl",
"shellcheck-mcp-server"
],
"enabled": true,
"timeout": 60000
}
}
}Claude Desktop
{
"mcpServers": {
"shellcheck": {
"command": "python3",
"args": ["/path/to/mcp-shellcheck/shellcheck_mcp_server.py"]
}
}
}Cursor
{
"mcpServers": {
"shellcheck": {
"command": "uvx",
"args": ["shellcheck-mcp-server"]
}
}
}VS Code (Copilot)
Add to .vscode/mcp.json:
{
"servers": {
"shellcheck": {
"command": "python3",
"args": ["/path/to/mcp-shellcheck/shellcheck_mcp_server.py"]
}
}
}Examples
Check a File
// Input
{ "file_path": "/path/to/deploy.sh" }
// Output
{
"success": false,
"message": "Found 3 issue(s)",
"results": [
{
"line": 15,
"column": 10,
"code": "SC2086",
"message": "Double quote to prevent globbing",
"severity": "warning"
}
],
"exit_code": 1
}Check Script Content
// Input
{ "script_content": "#!/bin/bash\ncat `ls *.txt`", "shell": "bash" }Exclude Specific Warnings
{ "file_path": "/path/to/script.sh", "exclude": "SC1090,SC2148" }Filter by Severity
{ "file_path": "/path/to/script.sh", "severity": "error" }Troubleshooting
Problem | Solution |
ShellCheck not found | Install via |
MCP package not installed |
|
Server not connecting | Verify |
Timeout errors | Increase timeout: |
Development
pip install -e ".[dev]"
pytest
ruff check .See CHANGELOG.md for release history and ARCHITECTURE.md for design docs.
License
MIT
Available Tools
2 toolsshellcheckA
Run ShellCheck on a shell script to find bugs, stylistic issues, and potential errors. Use when: reviewing shell scripts, validating CI pipeline scripts, or debugging script errors. Prefer over: manual bash syntax inspection when you want automated rule-based analysis (300+ rules). Avoid when: checking many large scripts — run ShellCheck locally for bulk analysis.
Supported shells: bash, sh, dash, ksh, ash
Returns structured JSON with issue details including line, column, code, message, and severity.
Common error codes:
SC1090: Can't follow non-constant source
SC2148: Tips depend on target shell and yours is unknown
SC2086: Double quote to prevent globbing
SC2164: Use cd with || exit
SC2006: Use $(...) instead of legacy backticks
SC2029: Note that, unlike in BASH, a variable cannot contain a newline
SC2230: Which is redundant
SC2068: Double quote array subscript
SC2196: Several way to test global flag
SC2001: See if you can use ${var//search/replace}
SC2162: read without -r will mangle backslashes
SC2129: Style: Consider using { cmd1; cmd2; } >> file instead of individual redirects
Use exclude parameter to suppress warnings (e.g., "SC1090,SC2148"). Use severity parameter to filter by minimum severity (error, warning, info, style).
| Name | Required | Description | Default |
|---|---|---|---|
| shell | No | Shell type to check | bash |
| exclude | No | Comma-separated list of warning codes to exclude (e.g., 'SC1090,SC2148') | |
| severity | No | Minimum severity to report | |
| file_path | No | Path to the shell script file to check | |
| enable_all | No | Enable all optional checks | |
| check_sourced | No | Enable checks for sourced files | |
| script_content | No | Raw shell script content to check (alternative to file_path) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format (structured JSON with line/column/code/message/severity) and lists common error codes. Implicitly non-destructive but could explicitly state read-only 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?
Well-structured with clear sections (purpose, usage, supported shells, returns, common codes). The list of error codes is verbose but helpful. Front-loaded with critical info.
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?
For a 7-param tool with no output schema or annotations, the description covers purpose, usage, parameter guidance, and output format. Lacks detailed output structure but adequate for standard linter output. Sibling tool not referenced but not necessary.
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 covers all 7 params (100% coverage). Description adds value by explaining exclude/suppression, severity filtering, and listing common error codes. Enhances understanding beyond schema descriptions.
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 runs ShellCheck on shell scripts to find bugs, stylistic issues, and potential errors. It distinguishes from the sibling 'shellcheck_info' by focusing on analysis execution.
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?
Explicitly specifies when to use (reviewing scripts, validating CI, debugging), preference over manual inspection, and when to avoid (many large scripts for local bulk analysis). Provides actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shellcheck_infoA
Get ShellCheck version and server capability info. Use when: verifying ShellCheck is installed or checking available shell versions. Prefer over: shellcheck when you don't need an actual analysis (cheaper — no script processing). Avoid when: you need script analysis — use shellcheck instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the tool is cheap and does no script processing, implying no side effects. However, could be more explicit about read-only nature and output format. Still, good coverage.
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?
Three sentences, front-loaded with purpose. Every sentence adds value – purpose, usage conditions, alternative. No wasted words.
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 zero parameters and no output schema, the description fully covers what an agent needs: what it does, when to use it, and how it compares to sibling. Output format is implicit from version/capability info.
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?
Zero parameters, so schema coverage is 100%. Description adds meaning by stating what info is returned (version and capability). Baseline 4 is appropriate with no parameters needing explanation.
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?
Description clearly states 'Get ShellCheck version and server capability info' – specific verb (get) and resource (ShellCheck version and capability). Distinguishes from sibling 'shellcheck' by noting it's for info, not analysis.
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?
Explicitly provides when to use (verifying installation, checking available versions), when to prefer over sibling (cheaper, no script processing), and when to avoid (need analysis). This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v0.2.0- First observed
shellcheck - First observed
shellcheck_info
TDQS
The two tools have completely distinct purposes: one performs script analysis, the other provides server info. No ambiguity.
Both tool names follow the pattern 'shellcheck' with an optional suffix ('shellcheck', 'shellcheck_info'), maintaining consistency.
With only 2 tools, it is below the typical 3-15 range for a well-scoped server, but it covers the essential functionality of a shellcheck service.
The core lifecycle is covered (run analysis and check capability), but a tool to list available rules or get detailed help is missing, which is a minor gap.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server (stdio): lint OpenAPI specs with Spectral via the AgentForge API
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceCode linting and style checking tools for AI agents, exposed as an MCP server. Supports style checks, naming conventions, complexity analysis, dead code detection, and import analysis.63MIT
- AlicenseAqualityFmaintenanceMCP server that integrates sql-sop SQL linter into LLM clients, enabling linting SQL queries and listing lint rules via chat tools.2MIT

shell-mcpofficial
AlicenseNot gradedqualityDmaintenanceGives AI agents shell access by providing a run_command tool for executing shell commands and returning stdout, stderr, and exit code.151ISC- FlicenseAqualityCmaintenanceA simple MCP server that exposes a terminal tool, allowing AI agents to execute shell commands.1-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ev3lynx727/mcp-shellcheck'
If you have feedback or need assistance with the MCP directory API, please join our Discord server