Allows running MegaLinter linting within Bitbucket Pipelines.
Allows running MegaLinter linting within CircleCI pipelines.
Allows running MegaLinter linting within GitHub Actions workflows.
Allows running MegaLinter linting within GitLab CI/CD pipelines.
Allows running MegaLinter linting within Jenkins pipelines.
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., "@MegaLinter MCP Server quick scan this repository"
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.
Note: This is a community-maintained MCP server. It is not an official Model Context Protocol server, but it is sanctioned by Ox Security as a complement to their official MegaLinter tools.
A Model Context Protocol (MCP) server for running Ox Security MegaLinter through mega-linter-runner. Works with any CI/CD platform (GitHub Actions, GitLab CI, Azure DevOps, CircleCI, Jenkins) or locally.
This server provides 15 MCP tools in total: 10 core tools and 5 convenience aliases across execution, discovery, and analysis workflows.
megalinter_quick_action for short, natural requests with sensible defaults.
megalinter_run to execute MegaLinter with configurable runtime and runner options.
megalinter_write_config to generate a minimal .mega-linter.yml file.
megalinter_list_flavors to return common MegaLinter flavors.
megalinter_get_linters to discover available linters by language, security focus, and auto-fix capability.
megalinter_get_security_info to group security linters by threat category.
megalinter_get_reporters to list supported report output formats and CI-targeted reporters.
megalinter_parse_reports to parse JSON or SARIF report artefacts.
megalinter_get_issue_summary to aggregate report issues by linter and severity.
megalinter_get_security_recommendations to generate security-focused remediation guidance.
If you prefer short prompts, use megalinter_quick_action first:
@megalinter quick scan this repository
@megalinter security scan
@megalinter summarise errors
@megalinter list python security linters
@megalinter write config
Or use ultra-short aliases for minimal typing:
@megalinter scan — Quick scan with defaults
@megalinter summary — Summarise last run's errors
@megalinter parse — Parse JSON report
@megalinter help_quick — Context-aware help for your project
This MCP server is platform-agnostic and works universally:
✅ Locally — Run MegaLinter from your IDE or command line
✅ GitHub Actions — Integrate with workflows
✅ GitLab CI/CD — Use in GitLab pipelines
✅ Azure DevOps — Run in Azure Pipelines
✅ CircleCI, Jenkins, Bitbucket Pipelines — Any CI/CD platform with Docker support
✅ AI Agents & Copilot — Automated code quality checks via MCP
The only requirement is Docker (or a compatible container runtime like Colima).
Tool | Category | Typical outcome |
| Interactive | Handle short natural requests with defaults |
| Alias | Ultra-short alias for quick scan |
| Alias | Ultra-short alias for error summary |
| Alias | Ultra-short alias for report parsing |
| Alias | Ultra-short alias for context-aware help |
| Help | Context-aware suggestions for your project |
| Execution | Run linting and produce report artefacts |
| Configuration | Generate baseline |
| Discovery | Identify an appropriate flavour for your stack |
| Discovery | Filter linters by language, security, and auto-fix support |
| Discovery | View security linters grouped by SAST, secrets, container, and IaC |
| Discovery | Select output/reporting formats for local and CI workflows |
| Analysis | Read JSON or SARIF reports in structured form |
| Analysis | Summarise issue totals and top failing linters |
| Analysis | Produce practical shift-left security actions |
Related MCP server: kube-lint-mcp
megalinter_quick_actionInteractive shortcut that accepts a short request and routes it to the right workflow.
Inputs:
request (string, optional): Short instruction. Default: quick scan.
action (string, optional): Explicit quick action (scan, config, flavors, linters, security, reporters, parse, summary, recommendations).
scanMode (string, optional): Scan preset (quick, full, security, fix).
target (string, optional): Directory to scan. Default: ..
workingDirectory (string, optional): Command working directory.
reportsPath (string, optional): Reports directory. Default: megalinter-reports.
reportType (string, optional): Parse format (json or sarif).
severity (string, optional): Summary filter (error, warning, info).
language (string, optional): Language filter for linter queries. For scans, maps to a flavor hint (python, javascript, terraform, and similar).
securityOnly (boolean, optional): Return only security linters in linter queries. For scans, forces security flavor.
autoFixOnly (boolean, optional): Return only auto-fix linters in linter queries.
timeoutMinutes (number, optional): Timeout for scan actions. Default: 20.
summaryOnly (boolean, optional): Return concise output for scans. Default: true.
flavor (string, optional): Optional flavor override for scan actions.
fix (boolean, optional): Force auto-fixes for scan actions.
targetPath (string, optional): Config output path for write-config requests.
Examples:
request: "quick scan" -> Runs ci_light against changed files.
request: "full scan" -> Runs all flavor.
request: "security scan" -> Runs security flavor.
request: "summarise errors" -> Returns issue summary filtered to errors.
request: "parse sarif report" -> Parses SARIF output.
action: "summary", severity: "error" -> Deterministic summary with no phrase parsing.
action: "scan", scanMode: "security" -> Deterministic security scan.
scan (Ultra-short alias)Run a quick scan with minimal typing. Accepts optional parameters for customization.
Inputs:
language (string, optional): Target language mapped to flavor (e.g., python, javascript, terraform).
scanMode (string, optional): Scan preset (quick, full, security, fix). Default: quick.
summaryOnly (boolean, optional): Return concise output. Default: true.
Example: @megalinter scan runs a quick scan with concise output.
summary (Ultra-short alias)Summarise errors from the last MegaLinter run with minimal typing.
Inputs:
severity (string, optional): Filter by severity (error, warning, info).
linterFilter (string, optional): Filter by linter name.
Example: @megalinter summary shows all error/warning totals.
parse (Ultra-short alias)Parse MegaLinter report files with minimal typing.
Inputs:
reportType (string, optional): Report format (json or sarif). Default: json.
reportsPath (string, optional): Reports directory path.
Example: @megalinter parse parses the JSON report.
megalinter_help_quickGet context-aware help based on your current repository. Detects languages, frameworks, Docker, Terraform, and security files to suggest relevant commands.
No inputs required.
Example: @megalinter help_quick returns tailored suggestions for your project.
megalinter_runUse this tool when you need full argument-level control. For short prompts, prefer megalinter_quick_action.
Runs mega-linter-runner via npx.
Inputs:
workingDirectory (string, optional): Command working directory. Defaults to current process directory.
path (string, optional): Directory path to lint.
flavor (string, optional): MegaLinter flavor. Default: all.
release (string, optional): MegaLinter image tag. Default: v9.
image (string, optional): Full Docker image override.
env (string, optional): Environment variable string passed to --env.
fix (boolean, optional): Apply auto-fixes.
help (boolean, optional): Show mega-linter-runner help.
install (boolean, optional): Generate MegaLinter starter config.
containerName (string, optional): Docker container name override.
removeContainer (boolean, optional): Remove container after run.
configFile (string, optional): Path to .mega-linter.yml.
reportsPath (string, optional): Reports directory. Default: megalinter-reports.
disableLinters (string, optional): Comma-separated list of linters to disable.
lintChangedFilesOnly (boolean, optional): Sets VALIDATE_ALL_CODEBASE=false when true.
runnerVersion (string, optional): npm version for mega-linter-runner (for example latest).
timeoutSeconds (number, optional): Timeout in seconds. Default: 3600.
summaryOnly (boolean, optional): Return concise logs. Default: false.
extraArgs (string[], optional): Additional CLI arguments.
megalinter_write_configWrites a minimal MegaLinter configuration.
Inputs:
targetPath (string, optional): Output file path. Default: .mega-linter.yml.
applyFixes (string, optional): Value for APPLY_FIXES. Default: none.
showElapsedTime (boolean, optional): Value for SHOW_ELAPSED_TIME. Default: true.
flavorSuggestions (boolean, optional): Value for FLAVOR_SUGGESTIONS. Default: false.
disableLinters (string[], optional): Values for DISABLE_LINTERS.
megalinter_list_flavorsReturns the built-in list of common flavors (all, javascript, python, terraform, and others).
megalinter_get_lintersReturns linter metadata from the built-in catalogue and supports targeted filtering.
Inputs:
language (string, optional): Filter by language (for example python, javascript, terraform).
securityOnly (boolean, optional): Return only security-focused linters.
autoFixOnly (boolean, optional): Return only linters with automatic fix capability.
megalinter_get_security_infoReturns security linters grouped into categories such as SAST, secrets, supply chain, container, and infrastructure.
Inputs:
None.
megalinter_get_reportersReturns available MegaLinter reporters, including CI-targeted formats.
Inputs:
None.
megalinter_parse_reportsParses MegaLinter report files from the reports directory.
Inputs:
reportsPath (string, optional): Report directory path. Default: megalinter-reports.
reportType (string, optional): Report type (json or sarif). Default: json.
megalinter_get_issue_summarySummarises issues from megalinter-report.json and can apply severity/linter filters.
Inputs:
reportsPath (string, optional): Report directory path. Default: megalinter-reports.
severityFilter (string, optional): Filter results by severity (error, warning, info).
linterFilter (string, optional): Filter results by linter name.
megalinter_get_security_recommendationsGenerates security recommendations based on active linters in the parsed report data.
Inputs:
reportsPath (string, optional): Report directory path. Default: megalinter-reports.
Use these copy/paste prompts in Copilot Chat with @megalinter.
CLI tools default to the current workspace root when no path is given.
If you add a file or folder as Copilot context (#file or #folder), reference it in your prompt and the tool will target that path.
megalinter_quick_action)@megalinter quick scan
@megalinter full scan
@megalinter security scan
@megalinter summarise errors
@megalinter parse sarif report
@megalinter write configExpected output: Routes each short request to the correct tool with sensible defaults.
Deterministic alternatives using explicit action fields:
@megalinter run quick action with action summary and severity error
@megalinter run quick action with action parse and reportType sarif
@megalinter run quick action with action scan and scanMode securitymegalinter_run)@megalinter run megalinter with flavor all on . with reports in megalinter-reportsExpected output: Executes linters and reports issues found across all languages. Creates megalinter-reports/ with JSON, SARIF, and text reports.
megalinter_write_config)@megalinter create a MegaLinter config at .mega-linter.ymlExpected output: Creates .mega-linter.yml with specified settings ready for customization.
megalinter_list_flavors)@megalinter list all available MegaLinter flavorsExpected output: Table of flavors (all, python, javascript, go, etc.) with descriptions and use cases.
megalinter_get_linters)@megalinter list python security linters with autofix supportExpected output: Filtered list of Python-related and multi-language security linters from the current catalog that support autofix (if any match the query).
megalinter_get_security_info)@megalinter show MegaLinter security linter categoriesExpected output: Security categories (for example, sast, secrets, supply-chain, container, infrastructure) with associated linters (gitleaks, trivy, etc.).
megalinter_get_reporters)@megalinter list available MegaLinter reportersExpected output: List of reporters (console, json, sarif, github-comment, etc.) with activation methods.
megalinter_parse_reports)@megalinter parse the json report from megalinter-reportsExpected output: Parsed MegaLinter JSON or SARIF report content as structured data (raw report payload).
megalinter_get_issue_summary)@megalinter summarise issues from megalinter-reports with severity errorExpected output: Summary of issues filtered by severity and linter inputs, aggregated by linter with totals and run counts.
megalinter_get_security_recommendations)@megalinter generate security recommendations using megalinter-reportsExpected output: Actionable security recommendations prioritized by severity with linter names, rule IDs, and suggested next steps.
Node.js >=24.0.0
npm (bundled with Node.js)
Docker Engine or Docker Desktop (must be running for megalinter_run)
Optional local container runtime wrapper such as Colima
Runtime:
@modelcontextprotocol/sdk (MCP server SDK)
Development:
typescript (build/compile)
tsx (development runner)
@types/node (Node.js typings)
Runtime note:
mega-linter-runner is executed via npx at runtime and can be pinned with the runnerVersion tool input.
npm install
npm run buildThis workspace is preconfigured in .vscode/mcp.json:
{
"servers": {
"megalinter": {
"type": "stdio",
"command": "node",
"args": ["./dist/index.js"]
}
}
}Reload VS Code (Cmd+Shift+P → Developer: Reload Window) after changing MCP configuration.
Then query the server from Copilot Chat with @megalinter, for example:
@megalinter list available flavors
@megalinter list security linters for javascriptUse a stdio server configuration that runs the compiled entrypoint:
{
"name": "megalinter-mcp-server",
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/megalinter-mcp/dist/index.js"]
}Build first with npm run build, then start your MCP client.
npm startDevelopment mode:
npm run devUse .vscode/launch.json:
Debug MCP Server (runs npm run dev)
Debug MCP Server (Built) (runs dist/index.js after build)
Set breakpoints in src/index.ts, then press F5.
See docs/TESTING.md for Copilot Chat scenarios, manual JSON-RPC checks, and troubleshooting guidance.
Quick validation prompt in Copilot Chat:
@megalinter list available flavorsAsk Copilot to run a scan:
@megalinter run megalinter on this repository with reports enabledParse the generated report:
@megalinter parse the json report in megalinter-reportsSummarise and prioritise:
@megalinter summarise error-level issues and top failing lintersRequest security guidance:
@megalinter generate security recommendations from the current reportDiscover linters for your stack:
@megalinter list python security linters with autofix supportGenerate starter config:
@megalinter create a megalinter config file with apply fixes set to noneDisable unsuitable linters and iterate.
List reporters:
@megalinter list available reportersSelect formats for your pipeline (for example SARIF for security tooling, Markdown for human-readable summaries).
Start with megalinter_write_config, then tighten rules in small steps.
Use lintChangedFilesOnly during fast feedback loops, and full scans in CI.
Keep reportsPath stable so downstream analysis tools always read from a known location.
Prefer megalinter_get_issue_summary for triage before requesting full report dumps.
Run megalinter_get_security_recommendations regularly to maintain shift-left coverage.
Pre-merge quality gates: Run megalinter_run in PR checks and publish SARIF output.
Repo onboarding packs: Use megalinter_get_linters and megalinter_list_flavors to choose a baseline quickly.
Security baseline reporting: Combine megalinter_parse_reports and megalinter_get_issue_summary for recurring snapshots.
Compliance evidence: Store generated reports and summaries as CI artefacts for audit trails.
Developer self-service: Let contributors query available linters/reporters directly through Copilot Chat.
MegaLinter website — Comprehensive documentation and configuration guide
MegaLinter repository — Source code and issue tracking
mega-linter-runner — npm package used by this server
MegaLinter Azure DevOps Extension — ADO task by the same author (also sanctioned by Ox Security)
GitHub Actions: Use MegaLinter's official GitHub Action
GitLab CI/CD: See MegaLinter GitLab integration docs
Jenkins, CircleCI, and others: Run MegaLinter via Docker in any CI/CD pipeline
Maintained by Carl Dawson under the Down At The Bottom Of The Mole Hole organization.
Licensed under the MIT License. MegaLinter is managed by Ox Security.
Ultra-short alias for context-aware help. Same as megalinter_help_quick.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'context-aware help', which is vague. No disclosure of whether it's read-only, what it returns, or any side effects. Lacks behavioral detail beyond being an alias.
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?
Extremely concise: two short clauses. Every word serves a purpose. No wasted text. Well-structured for an alias definition.
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?
Despite zero parameters and no output schema, the description fails to explain why both help_quick and megalinter_help_quick exist as siblings. This creates confusion about which to use. Missing contextual differentiation.
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?
Input schema has zero parameters, so baseline is 4. Description adds 'context-aware' hint, implying it uses conversational context, which is meaningful beyond the empty schema.
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?
Clearly states it's an alias for context-aware help and specifically mentions being the same as megalinter_help_quick. However, it doesn't elaborate on what 'help' entails, but the purpose as a help alias is evident.
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?
No guidance on when to use this tool versus alternatives. It merely says it's an alias for another tool, but doesn't explain why both exist or when one is preferred. Absence of usage or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze and summarize issues from MegaLinter reports by severity, linter, and category. Enables filtering and targeted remediation.
| Name | Required | Description | Default |
|---|---|---|---|
| reportsPath | No | Path to the reports directory. Defaults to megalinter-reports. | |
| severityFilter | No | Filter issues by severity level. | |
| linterFilter | No | Filter issues by specific linter name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose whether the tool is read-only, what the summary includes, or any side effects. Only states high-level action without behavioral details.
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?
Two sentences, no wasted words. However, the first sentence includes an extraneous reference to 'category' that doesn't align with the schema.
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?
No output schema and description does not explain the format of the summary (e.g., counts, groupings). Lacks completeness for a tool that produces a summary.
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 coverage is 100%, so baseline is 3, but the description adds misleading info by mentioning 'category' which is not a parameter. This confuses rather than clarifies.
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 analyzes and summarizes issues, but mentions 'category' as a filter which is not in the schema, causing slight confusion. It distinguishes from sibling tools by focusing on issue 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?
No explicit guidance on when to use this tool versus alternatives like megalinter_parse_reports. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover available linters by language, security category, or auto-fix capability.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Filter by programming language (e.g., python, javascript, terraform). | |
| securityOnly | No | Return only security-focused linters. | |
| autoFixOnly | No | Return only linters that support automatic fixes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It implies a read-only operation by saying 'Discover' but does not explicitly state that no changes are made. The behavior is straightforward (filtering and listing), but the description lacks explicit safety or side-effect disclosure.
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, front-loaded sentence that conveys the purpose and filtering capabilities with no wasted words. It is concise and easy to parse.
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 there is no output schema, the description should hint at the return format (e.g., a list of linter names or details). It only says 'Discover available linters' without describing the output structure. For a simple filtering tool, this is adequate but not fully complete.
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 coverage is 100% (each parameter has a description). The description adds a brief mapping ('by language, security category, or auto-fix capability') but does not provide additional meaning beyond what the schema already offers. Baseline of 3 is appropriate.
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 discovers available linters and lists three filtering criteria that directly correspond to the input schema parameters. It distinguishes itself from sibling tools like megalinter_run or megalinter_get_issue_summary by focusing on linter discovery.
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 discovering linters before running, but it does not explicitly state when to use this tool versus alternatives like megalinter_get_security_info or when not to use it. No exclusions or context on prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available MegaLinter reporters and their configuration options.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It correctly implies a read-only operation without side effects by stating 'list'. It adds context by mentioning 'configuration options', but does not detail potential rate limits or data completeness beyond 'all available'.
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 sentence of seven words, containing no fluff. Every word is essential and front-loaded with the action and subject.
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 has no parameters and no output schema, the description sufficiently explains what the tool does. It could be slightly improved by hinting at the return format, but it is largely complete for a simple listing tool.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed since the schema already covers all properties.
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 verb 'list' and the resource 'all available MegaLinter reporters and their configuration options'. This distinguishes it from sibling tools like 'megalinter_get_linters' which list linters, not reporters.
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?
No explicit guidance on when to use this tool versus alternatives like 'megalinter_get_linters' or 'megalinter_get_security_info'. The purpose is implied by the name and description, but the agent gets no direct when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive information about security-focused linters organized by category (SAST, secrets, supply-chain, container, infrastructure).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'get comprehensive information' but does not disclose whether the data is static or dynamic, if authentication is required, or the structure of the output. For a zero-parameter tool, the behavioral implications are minimal but still could be more explicit.
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 sentence of 15 words with no redundancy. It efficiently conveys the tool's purpose and organizational structure.
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 output schema, the description could better define what 'comprehensive information' entails (e.g., lint names, rules, severity). However, for a zero-parameter retrieval tool, it is minimally adequate but lacks full specificity.
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?
There are zero parameters and schema coverage is 100%. The description adds value by listing the categories of linters, but no parameter documentation is needed beyond the schema.
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 retrieves comprehensive information about security-focused linters, organized by specific categories (SAST, secrets, supply-chain, container, infrastructure). This differentiates it from sibling tools like megalinter_get_linters which covers all linters.
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 security linter info is needed but does not explicitly state when to use it over alternatives like megalinter_get_security_recommendations or megalinter_get_linters. No exclusion or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate security-focused recommendations based on active linters and common threat categories (SAST, secrets, container, infrastructure).
| Name | Required | Description | Default |
|---|---|---|---|
| reportsPath | No | Path to the reports directory. Defaults to megalinter-reports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'generate' without specifying whether this is a read-only operation, any required permissions (e.g., file system access for reportsPath), or side effects. For a tool without annotations, this is insufficient.
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 sentence that efficiently conveys the core purpose. However, it lacks structure like bullet points for threat categories or examples, which could improve scannability.
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?
With 13 sibling tools, no annotations, and no output schema, the description should provide more context about how the tool fits into the ecosystem, what the output format looks like, or when to use it. Currently, it only covers the basic purpose.
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% for the single parameter 'reportsPath', which is fully described in the schema. The tool description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
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 generates security-focused recommendations based on active linters and specific threat categories (SAST, secrets, container, infrastructure). This distinguishes it from sibling tools like megalinter_get_security_info which likely provides raw security data rather than recommendations.
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?
No guidance is given on when to use this tool versus alternatives such as megalinter_get_security_info or megalinter_get_linters. The description does not mention exclusions, prerequisites, or use cases, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get context-aware help and examples based on your current repository. Suggests relevant commands for detected languages and frameworks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only mentions 'context-aware' and 'suggests relevant commands' without disclosing whether it scans files, requires network access, or alters state. The behavioral impact is unclear.
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, concise sentence that front-loads the core functionality. Every word adds value without redundancy.
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 output schema and zero parameters, the description adequately conveys the basic purpose but lacks details on the return format (e.g., text, list of commands) or how 'context-aware' is determined. It is sufficient but not fully complete.
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?
With zero parameters, the baseline is 4. The description adds no parameter details because none exist, and the schema's 100% coverage is trivial. No deduction is warranted.
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 provides context-aware help based on the repository, which distinguishes it from siblings like megalinter_run or megalinter_get_linters. It uses specific verbs ('get', 'suggests') and defines the resource ('help and examples', 'relevant commands').
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 obtaining quick, repository-specific help but does not explicitly state when to use this tool versus alternatives like help_quick or other megalinter tools. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List commonly used MegaLinter flavors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only indicates that the tool lists 'commonly used' flavors, implying a filtering behavior. No information about authentication, rate limits, or return format is given, which is a gap for a read 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, concise sentence that directly states the tool's function. No superfluous words, and it is appropriately front-loaded for quick understanding.
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 has no parameters and no output schema, the description is mostly complete. However, not specifying the return format (e.g., list of strings vs objects) slightly reduces completeness. The qualifier 'commonly used' also lacks precise definition.
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 no parameters, and schema description coverage is 100%. The description adds no additional parameter info, but the baseline score is 3 as per instructions when coverage is high.
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 'List commonly used MegaLinter flavors' clearly states the action (list) and resource (flavors), distinguishing it from sibling tools that list linters or reporters. The qualifier 'commonly used' adds a slight ambiguity but still conveys the purpose effectively.
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 explicit guidance on when to use this tool versus alternatives like `megalinter_get_linters`. However, the name and sibling context imply use for listing flavors, which is adequate but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse MegaLinter JSON or SARIF reports from the reports directory. Returns structured report data for analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| reportsPath | No | Path to the reports directory. Defaults to megalinter-reports. | |
| reportType | No | Type of report to parse. Defaults to json. | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool parses and returns structured data, without disclosing any behavioral traits like permissions needed, side effects, or performance implications. More transparency is needed for a parse 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 sentence that conveys action and resource upfront. No redundant information. Every word adds value, making it highly efficient.
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?
The tool has two optional parameters and no output schema. The description states returns structured data but does not specify the format or structure of the output. Given the presence of sibling analysis tools, more detail on what 'structured report data' entails would improve completeness.
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?
Both parameters have descriptions in the input schema (100% coverage). The description does not add any extra meaning beyond what the schema provides, such as example values or format constraints. Baseline of 3 is appropriate.
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 parses MegaLinter JSON or SARIF reports and returns structured data. It specifics the resource (reports) and action (parse), distinguishing it from siblings like 'megalinter_get_issue_summary' which likely summarize rather than parse raw reports.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for parsing reports, but does not mention when to choose JSON or SARIF, nor does it exclude specific contexts. This is adequate but lacks differentiation from other analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interactive shortcut tool for short requests (for example: quick scan, security scan, summarise errors, list python security linters).
| Name | Required | Description | Default |
|---|---|---|---|
| request | No | Short instruction. Examples: quick scan, full scan, security scan, summarise errors, parse sarif report, write config. | quick scan |
| action | No | Optional explicit action. Use this for deterministic quick workflows. | |
| scanMode | No | Scan preset when action is scan (or request implies a scan). | |
| target | No | Directory to scan for run requests. Defaults to . | |
| workingDirectory | No | Directory where commands run. Defaults to current process directory. | |
| reportsPath | No | Report directory for parse, summary, and recommendation requests. | megalinter-reports |
| reportType | No | Report format for parse requests. Defaults to json unless sarif is requested. | |
| severity | No | Severity filter for summary requests. | |
| linterFilter | No | Linter filter for summary requests. | |
| language | No | Language filter for linter-list requests. For scans, this maps to a flavor hint (e.g., python -> python, typescript -> javascript). | |
| securityOnly | No | Filter linter-list requests to security linters. For scans, forces security flavor. | |
| autoFixOnly | No | Filter linter-list requests to auto-fix linters. | |
| timeoutMinutes | No | Run timeout in minutes for scan requests. | |
| summaryOnly | No | Use concise output for scan requests. Set false for full logs. | |
| flavor | No | Optional flavour override for scan requests (e.g., javascript, python, security). | |
| fix | No | Force auto-fix for scan requests. | |
| targetPath | No | Output file path for write-config requests. Defaults to .mega-linter.yml. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only describes the tool as 'interactive shortcut' without mentioning side effects, permissions, or whether operations are read-only or mutating. This is insufficient for safe agent invocation.
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 concise—one sentence plus examples—and front-loaded with the core purpose. It avoids unnecessary elaboration while still being informative.
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?
Despite the schema covering parameter descriptions, the tool description is too brief for a tool with 17 parameters and no output schema. There is no explanation of interactions between parameters (e.g., how 'request' and 'action' relate), default behaviors, or error handling. This leaves gaps for effective 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% with detailed parameter descriptions. The tool description adds high-level context (e.g., examples mapping to parameters) but does not significantly enhance understanding beyond what the schema provides. Baseline 3 is appropriate.
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 identifies this as an 'interactive shortcut tool for short requests' and provides concrete examples (quick scan, security scan, summarise errors). This distinguishes it from sibling tools like megalinter_run which handles full runs, though the differentiation is not explicitly stated.
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 use for short requests but does not provide explicit guidance on when to use this tool vs. alternatives such as megalinter_run or scan. No 'when not to use' information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Ox Security MegaLinter using mega-linter-runner with full low-level control. For short prompts, use megalinter_quick_action.
| Name | Required | Description | Default |
|---|---|---|---|
| workingDirectory | No | Directory where the command is executed. Defaults to current process directory. | |
| path | No | Directory path to lint. | |
| flavor | No | MegaLinter flavor. | all |
| release | No | MegaLinter Docker image tag. | v9 |
| image | No | Optional full Docker image override. | |
| env | No | Environment variable string passed to --env (for example: DISABLE_LINTERS=SPELL_CSPELL,MARKDOWN_MARKDOWNLINT). | |
| fix | No | Apply auto-fixes. | |
| help | No | Show mega-linter-runner help. | |
| install | No | Generate MegaLinter starter config files. | |
| containerName | No | Optional Docker container name. | |
| removeContainer | No | Remove container after completion. | |
| configFile | No | Path to .mega-linter.yml file. | |
| reportsPath | No | Directory where reports are written. | megalinter-reports |
| disableLinters | No | Comma-separated list of linters to disable. | |
| lintChangedFilesOnly | No | If true, sets VALIDATE_ALL_CODEBASE=false to lint only changed files. | |
| runnerVersion | No | mega-linter-runner npm version. Use 'latest' or a specific version. | latest |
| timeoutSeconds | No | Command timeout in seconds. | |
| summaryOnly | No | Return concise logs instead of full stdout/stderr output. | |
| extraArgs | No | Additional CLI arguments to append. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It lacks behavioral traits such as whether it modifies files, authentication requirements, or rate limits. 'Full low-level control' is vague.
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?
Two concise sentences, front-loaded with purpose and sibling distinction. 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?
With 19 parameters, 100% schema coverage, no output schema, and no annotations, the description is minimal. It achieves basic completeness but lacks behavioral guidance; the agent would rely heavily on parameter names and schema descriptions.
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 baseline is 3. The description adds no parameter-level detail beyond the schema; it only provides a high-level summary.
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 Ox Security MegaLinter with full low-level control, and explicitly distinguishes it from the sibling tool 'megalinter_quick_action' for short prompts.
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?
Provides a clear context for when to use this tool (full low-level control) vs. a simpler alternative (megalinter_quick_action for short prompts). However, no explicit when-not or exclusion criteria for other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a minimal .mega-linter.yml configuration file.
| Name | Required | Description | Default |
|---|---|---|---|
| targetPath | No | Output path for the MegaLinter config file. Defaults to .mega-linter.yml | |
| applyFixes | No | Value for APPLY_FIXES (none, all, or linter list). | none |
| showElapsedTime | No | Set SHOW_ELAPSED_TIME. | |
| flavorSuggestions | No | Set FLAVOR_SUGGESTIONS. | |
| disableLinters | No | Optional list for DISABLE_LINTERS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden to disclose side effects. It states 'Generate' but does not clarify that this creates or overwrites a file on disk, nor does it mention any permissions or potential destructive behavior. The minimal nature of the output is also undefined.
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 sentence that is short, direct, and front-loaded with the key action and resource. Every word earns its place, with no unnecessary details.
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 lack of output schema and annotations, the description should provide more context about what the generated config contains, whether it overwrites existing files, and how it integrates with other tools. The current description leaves important gaps for a config-generation tool.
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 coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions, which are already clear. Thus it meets but does not exceed the baseline.
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 uses a specific verb 'Generate' and clearly identifies the resource as 'a minimal .mega-linter.yml configuration file'. This distinguishes the tool from siblings like megalinter_run or megalinter_get_linters, which serve different purposes.
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, typical workflow placement, or scenarios where this tool is appropriate, leaving the AI agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ultra-short alias for report parsing. Same as megalinter_quick_action with action='parse'.
| Name | Required | Description | Default |
|---|---|---|---|
| reportType | No | Type of report to parse. | json |
| reportsPath | No | Reports directory path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says it's an alias without detailing behavior such as input/output processing or side effects.
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?
Description is exceptionally short and front-loaded with purpose, but lacks completeness for a standalone description.
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 fails to explain tool behavior, output, or usage context, leaving significant gaps.
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 coverage is 100% with descriptions for both parameters; description adds no additional semantic value beyond the schema.
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 is for report parsing and explicitly identifies it as an alias for megalinter_quick_action with action='parse', distinguishing it from siblings.
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 use via alias for quick action, but does not specify when to use this tool over the full megalinter_quick_action or other parsing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ultra-short alias for quick scan. Same as megalinter_quick_action with action='scan'.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Target language to map into a scan flavor (e.g., python, javascript, terraform). | |
| scanMode | No | Scan preset mode. | quick |
| summaryOnly | No | Return concise output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it's an alias, with no disclosure of behavioral traits (e.g., mutability, permissions, side effects). Schema shows scan modes but description lacks elaboration.
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?
Extremely concise: two sentences, no wasted words. Front-loaded with key point 'ultra-short alias'.
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?
Adequate for a simple alias tool given full schema coverage, but lacks context on return values, behavior for different scan modes, and overall tool purpose beyond being an alias.
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 coverage is 100%, so baseline is 3. Description adds no extra meaning to the parameters already documented in the schema.
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 it's an alias for a quick scan, referencing megalinter_quick_action. It identifies the verb (scan) and resource (quick scan) but does not differentiate from sibling tools in detail.
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?
Implies usage for quick scans via 'Ultra-short alias', but no explicit when/when-not or alternatives beyond referencing the equivalent function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ultra-short alias for error summary. Same as megalinter_quick_action with action='summary'.
| Name | Required | Description | Default |
|---|---|---|---|
| severity | No | Filter by severity level. | |
| linterFilter | No | Filter by linter name. | |
| reportsPath | No | Reports directory path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It explains that the tool behaves identically to megalinter_quick_action with a specific parameter, but does not elaborate on the summary's content or any side effects, offering minimal behavioral detail.
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: two sentences that front-load the purpose and provide essential context without any extraneous 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?
While the description correctly identifies the tool as an alias, it lacks details about the output or behavior beyond the equivalence. For a tool with 3 parameters and no output schema, this is adequate but not complete.
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 100% coverage with descriptions for each parameter. The description adds no additional meaning to the parameters, so it meets the baseline expectation.
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 is an alias for an error summary and explicitly names the equivalent sibling tool with its action parameter, making the purpose immediately understandable and differentiating it from sibling tools.
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 indicates that this tool is a shorthand for megalinter_quick_action with action='summary', providing a clear alternative. It implies when to use this tool (quick access) but does not explicitly state when not to use it or other exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiple tools are direct aliases (e.g., help_quick and megalinter_help_quick; parse, scan, summary for megalinter_quick_action), creating ambiguity about which to use. While the descriptions mention the aliasing, it adds unnecessary overlap.
Most tools follow a consistent megalinter_verb_noun pattern, but the inclusion of aliases like help_quick, parse, scan, and summary breaks the pattern, mixing short and full names.
With 15 tools, the count is at the high end of well-scoped. However, some tools are redundant due to aliases, so not every tool earns its place, but overall the scope is reasonable.
The tool surface covers the core lifecycle: listing, running, parsing reports, writing config, and security recommendations. Minor gaps like updating config or managing multiple runs are absent, but essential functionality is present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Free MCP tools: the only MCP linter, health checks, cost estimation, and trust evaluation.
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DownAtTheBottomOfTheMoleHole/megalinter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
