What can you do with this server?

This MCP server provides comprehensive code analysis for Python and JavaScript/TypeScript projects through the following capabilities: * ruff-check — Lint Python code using Ruff to identify style violations and potential errors, with line/column info, rule codes, severity, and auto-fixable flags. * ruff-format — Format Python code using Ruff's fast formatter, returning the formatted code and whether changes were made. * ruff-check-ci — Run Ruff linting with CI/CD-optimized output formats (JSON, GitHub Actions, GitLab CI, SARIF) for automated pipelines. * ty-check — Type-check Python code using ty, returning diagnostics with line/column info, rule identifiers, severity, and error/warning counts. * vulture-scan — Detect dead/unused code (imports, functions, variables, classes) using Vulture, with configurable confidence thresholds. * analyze-code — Run a combined analysis (Ruff + ty + Vulture) in a single call, returning all individual results plus a unified summary with a code quality score (0–100). * biome-check / biome-format — Lint and format JavaScript/TypeScript code using Biome. Key characteristics: All tools are read-only and idempotent, processing code in-memory with no network calls or telemetry. Supports optional configuration paths for tailored analysis. Integrates with VS Code, Claude Desktop, Zed, and Claude Code via MCP protocol.

Which integrations are available for this server?

Provides comprehensive Python linting with auto-fixes using Ruff.

How do I use mcp-server-analyzer?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-analyzer analyze code quality of my Python script" 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.

mcp-server-analyzer

by Anselmoo

Overview Schema Related Servers Score Discussions

Python

Remote

MCP Server Analyzer for Python 🐍🔍

SafeSkill 92/100

CI/CD Pipeline PyPI version Python 3.13+ Docker License: MIT Code Coverage AgentSeal MCP Docs

A powerful Model Context Protocol (MCP) server that provides comprehensive Python code analysis using Ruff for linting, ty for type checking, and Vulture for dead code detection. Perfect for AI assistants, IDEs, and automated code review workflows.

🚀 Quick Start

VS Code Integration (One-Click Install)

For quick installation, use one of the one-click install buttons below...

Install with UV in VS Code Install with UV in VS Code Insiders

Install with Docker in VS Code

For manual installation, add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON).

Optionally, you can add it to a file called .vscode/mcp.json in your workspace. This will allow you to share the configuration with others.

Note that the mcp key is needed when using the mcp.json file.

Using uvx (recommended):

{
  "mcp": {
    "servers": {
      "analyzer": {
        "command": "uvx",
        "args": ["mcp-server-analyzer"]
      }
    }
  }
}

Using Docker:

{
  "mcp": {
    "servers": {
      "analyzer": {
        "command": "docker",
        "args": ["run", "-i", "--rm", "ghcr.io/anselmoo/mcp-server-analyzer"]
      }
    }
  }
}

Universal Installation

# Install with uvx (recommended)
uvx install mcp-server-analyzer

# Install with pip
pip install mcp-server-analyzer

# Run with Docker
docker run ghcr.io/anselmoo/mcp-server-analyzer:latest

# Install from source
git clone https://github.com/anselmoo/mcp-server-analyzer.git
cd mcp-server-analyzer
uv sync --dev
uv run mcp-server-analyzer

Related MCP server: codetest-mcp

📋 Features

🔍 RUFF Analysis: Comprehensive Python linting with auto-fixes
🧠 ty Type Checking: Fast Python type analysis with rule-based diagnostics
🧹 Dead Code Detection: Find unused imports, functions, and variables with VULTURE
⚡ Biome JS/TS Analysis: Fast linting and formatting for JavaScript and TypeScript
📊 Quality Scoring: Combined analysis with quality metrics
🚀 FastMCP Framework: High-performance MCP server implementation
🐳 Docker Ready: Multi-architecture containers with security signing
🔒 Secure: All releases signed with Sigstore for supply chain security

📈 Analysis Examples

RUFF Linting Preview

See comprehensive linting analysis examples: 📋 RUFF Analysis Preview

VULTURE Dead Code Detection Preview

Explore dead code detection capabilities: 🧹 VULTURE Analysis Preview

🛠️ Available Tools

Tool	Description	Use Case
`ruff-check`	Lint Python code with RUFF	Style violations, potential errors
`ruff-format`	Format Python code with RUFF	Code formatting and consistency
`ruff-check-ci`	CI/CD optimized RUFF output	GitHub Actions, GitLab CI
`ty-check`	Type-check Python code with ty	Type safety, incorrect return values
`vulture-scan`	Dead code detection	Unused imports, functions, variables
`biome-check`	Lint JS/TS code with Biome	Style violations, potential errors
`biome-format`	Format JS/TS code with Biome	Code formatting and consistency
`analyze-code`	Combined Ruff + ty + Vulture analysis	Complete code quality assessment

🔧 Configuration

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "analyzer": {
      "command": "uvx",
      "args": ["mcp-server-analyzer"]
    }
  }
}

Zed

Add to your Zed settings.json:

"context_servers": {
  "analyzer": {
    "command": "uvx",
    "args": ["mcp-server-analyzer"]
  }
}

Claude Code (project-level)

Place .mcp.json at your project root:

{
  "mcpServers": {
    "analyzer": {
      "command": "uvx",
      "args": ["mcp-server-analyzer"]
    }
  }
}

🧪 Development

Prerequisites

Python 3.13+
uv (recommended) or pip
Node.js 22+ (for Biome JS/TS analysis)
Docker (optional)

Setup

# Clone repository
git clone https://github.com/anselmoo/mcp-server-analyzer.git
cd mcp-server-analyzer

# Install Python dependencies
uv sync --dev

# Install Biome (JS/TS analyzer)
npm ci

# Run tests
uv run pytest

# Run type checks
uv run ty check src tests

# Run pre-commit hooks
uv tool run pre-commit run --all-files

# Build Docker image
docker build -t mcp-server-analyzer .

Testing

# Run all tests
uv run pytest tests/ -v

# Run with coverage
uv run pytest --cov=src/mcp_server_analyzer --cov-report=html

# Test specific functionality
uv run pytest tests/test_server.py::TestAnalyzers::test_ruff_with_sample_code

📊 Quality Metrics

The server provides quality scoring based on:

Ruff Issues: Style violations, potential bugs, complexity metrics
ty Diagnostics: Static typing errors and warnings
Dead Code Detection: Unused imports, functions, variables
Combined Score: Weighted quality assessment (0-100)

🔒 Security

Signed Releases: All releases signed with Sigstore
Container Signing: Docker images signed with Cosign
Trusted Publishing: PyPI releases use GitHub OIDC trusted publishing
Vulnerability Scanning: Automated security scanning in CI/CD
Supply Chain Security: SLSA Build Level 3 compliance
Security Policy: See SECURITY.md for vulnerability reporting

🔍 Data Handling & Transparency

In-memory only: Code passed to tools is written to a temporary file, analyzed, and the file is deleted immediately — nothing is persisted between calls.
No network calls: The server makes no outbound network connections during analysis.
No telemetry: No usage data, analytics, or crash reports are collected.
Subprocess isolation: ruff, ty, and vulture are invoked with fixed argument lists — no shell expansion or arbitrary command execution.

📚 Documentation

Full Documentation - GitHub Pages docs
Tools Reference - Detailed tool parameters and return types
MCP Specification - Learn about Model Context Protocol
FastMCP Framework - High-performance MCP implementation
Ruff Documentation - Python linter and formatter
ty Documentation - Python type checker and language server
Vulture Documentation - Dead code finder

🤝 Contributing

Contributions are welcome! Please see CONTRIBUTING.md for details.

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes using Conventional Commits
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

📝 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

Astral for RUFF and uv
Jendrik Seipp for VULTURE
Model Context Protocol team
FastMCP framework

Made with ❤️ for better Python code quality

Available Tools

8 tools

analyze-codeA

Read-onlyIdempotent

Comprehensive analysis combining Ruff linting, ty type checking, and Vulture dead code detection.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	Python code to analyze
`project_path`	No	Optional project directory used by ty for config and import resolution
`min_confidence`	No	Minimum confidence level for VULTURE (default: 80)
`ruff_config_path`	No	Optional path to RUFF configuration file

Output Schema

ParametersJSON Schema

Name	Required	Description
`summary`	Yes	Summary statistics of the analysis
`ty_result`	Yes	ty type-checking results
`ruff_result`	Yes	RUFF linting results
`vulture_result`	Yes	VULTURE dead code detection results

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, reducing the burden. The description adds that it combines three tools, but no additional behavioral details like performance or error handling are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the purpose with no unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations are present, the description is nearly complete. It lacks usage guidance for when to use this combined tool rather than individual ones, but covers purpose and scope adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All parameters have schema descriptions (100% coverage) with clear roles for code, ruff_config_path, min_confidence, and project_path. The description adds no extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs comprehensive analysis combining Ruff, ty, and Vulture, with specific verb 'analyze' and resource 'code'. It distinguishes itself from sibling tools that focus on single tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this combined tool versus individual siblings like ruff-check or ty-check. It implies comprehensive analysis but lacks direct alternatives or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

biome-checkA

Read-onlyIdempotent

Lint JavaScript/TypeScript code using Biome.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	JS/TS/JSX/TSX code to analyze
`filename`	No	Virtual filename used to select parser and rule set (e.g., "app.ts", "index.jsx")	code.ts

Output Schema

ParametersJSON Schema

Name	Required	Description
`errors`	Yes	Number of error-severity diagnostics
`issues`	Yes	List of diagnostics found
`warnings`	Yes	Number of warning-severity diagnostics
`total_issues`	Yes	Total number of diagnostics

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and idempotent. The description does not add behavioral context beyond the basic purpose, but does not contradict. Minimal value added.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the purpose with zero wasted words and is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimal but, combined with the input schema, provides enough context for a simple linting tool. However, it could be more descriptive about the scope and behavior, especially given multiple similar tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 both parameters. The description adds no additional parameter semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lints JavaScript/TypeScript code using Biome, which is a specific action and resource. It distinguishes from sibling tools like biome-format (formatting) and ruff-check (Python linting).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no usage guidelines, such as when to use this tool versus alternatives like ruff-check or ty-check, or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

biome-formatA

Read-onlyIdempotent

Format JavaScript/TypeScript code using Biome.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	JS/TS/JSX/TSX code to format
`filename`	No	Virtual filename used to select parser (e.g., "app.ts", "index.jsx")	code.ts

Output Schema

ParametersJSON Schema

Name	Required	Description
`changed`	Yes	Whether the code was modified during formatting
`formatted_code`	Yes	The formatted JS/TS code

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and idempotentHint, so the description does not need to repeat those. The description adds no additional behavioral context, but does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that immediately states the tool's purpose. Every word is necessary, and there is no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (2 parameters, full schema coverage, annotations present, output schema exists), the description is sufficient. It could mention that the tool returns formatted code, but that is implied by formatting context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for both parameters. The description does not add extra meaning beyond the schema, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool formats JavaScript/TypeScript code using Biome, with a specific verb and resource, and is distinct from sibling tools like biome-check and ruff-format.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, nor does it mention exclusions or prerequisites. The usage context is only implied by the tool name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruff-checkA

Read-onlyIdempotent

Lint Python code using RUFF to identify style violations and potential errors.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python code to analyze
`config_path`	No	Optional path to RUFF configuration file

Output Schema

ParametersJSON Schema

Name	Required	Description
`issues`	Yes	List of linting issues found
`total_issues`	Yes	Total number of issues
`fixable_issues`	Yes	Number of auto-fixable issues

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'identify style violations and potential errors', which confirms read-only behavior but does not provide additional behavioral traits beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 10 words, front-loaded with key action. No redundant or extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity and presence of output schema (though not shown), the description sufficiently covers purpose. However, it lacks mention of output format or error handling, which could be inferred from output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already describes both parameters (code, config_path). The description adds no extra parameter details beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'lint', resource 'Python code', and tool 'RUFF' to identify style violations and errors. This distinguishes it from siblings like ruff-format (formatting) and vulture-scan (dead code).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context provides sibling tool names (analyze-code, ruff-check-ci, ruff-format, ty-check, vulture-scan), and the description implies linting use, but no explicit when-to-use or when-not-to-use guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruff-check-ciA

Read-onlyIdempotent

Run RUFF linter with CI/CD-specific output formats.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python code to lint
`config_path`	No	Optional path to RUFF configuration file
`output_format`	No	Output format (json, gitlab, github, sarif)	json

Output Schema

ParametersJSON Schema

Name	Required	Description
`format`	Yes	Output format used (json, gitlab, github, sarif)
`output`	Yes	Raw RUFF output in the requested format
`success`	Yes	Whether the check completed without errors

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and idempotentHint. The description adds no additional behavioral context beyond stating the tool runs the linter. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, no fluff. Every word is meaningful and directly conveys the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complete input schema descriptions, existing annotations, and an output schema, the description is largely sufficient. Minor gap: could elaborate on what 'CI/CD-specific output formats' entails, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage, so parameters are fully described. The description adds no new semantic meaning beyond the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs the RUFF linter and specifies its CI/CD-specific output formats. This explicitly distinguishes it from sibling tools like ruff-check (likely generic) and other linters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when CI/CD formatted output is needed, but does not provide explicit when-not-to-use guidance or mention alternative tools. More specificity could improve clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ruff-formatB

Read-onlyIdempotent

Format Python code using RUFF's fast formatter.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python code to format
`config_path`	No	Optional path to RUFF configuration file

Output Schema

ParametersJSON Schema

Name	Required	Description
`changed`	Yes	Whether the code was modified during formatting
`formatted_code`	Yes	The formatted Python code

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and idempotentHint, so the description adds minimal behavioral context. It doesn't mention return format or side effects, but annotations cover safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single short sentence, zero waste. Could include output information but remains efficient for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately covers purpose and parameters, but fails to mention output (formatted code) despite an output schema existing. Sibling differentiation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both parameters. The description only adds 'RUFF's fast formatter' as context, not enhancing parameter understanding beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool formats Python code with RUFF, using a specific verb and resource. It's distinct from siblings like 'ruff-check' but doesn't explicitly differentiate, leaving slight ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like 'ruff-check' or 'analyze-code'. Does not mention scenarios, prerequisites, or post-conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ty-checkB

Read-onlyIdempotent

Type-check Python code using ty.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python code to analyze
`project_path`	No	Optional project directory used for ty config and import resolution

Output Schema

ParametersJSON Schema

Name	Required	Description
`diagnostics`	Yes	List of type diagnostics found
`error_count`	Yes	Number of error diagnostics
`warning_count`	Yes	Number of warning diagnostics
`total_diagnostics`	Yes	Total number of diagnostics

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. Description adds no further behavioral traits such as side effects or dependencies. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise and front-loaded. Could include more context without being verbose, but not overly minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 100% schema coverage and an output schema, the description is minimally adequate. Lacks usage context but covers basic purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage for both parameters. The description adds no additional meaning beyond what is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool type-checks Python code using 'ty'. It is specific and distinguishes from siblings which perform linting, formatting, or scanning rather than type-checking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use vs sibling tools like ruff-check or analyze-code. The description lacks context for proper selection among alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

vulture-scanC

Read-onlyIdempotent

Detect dead/unused code using VULTURE.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python code to analyze
`min_confidence`	No	Minimum confidence level (0-100) for reporting items

Output Schema

ParametersJSON Schema

Name	Required	Description
`total_items`	Yes	Total number of unused items
`unused_items`	Yes	List of unused code items found
`high_confidence_items`	Yes	Number of items with confidence >= 80

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the description adds no additional behavioral context. It does not mention that the tool only analyzes input without modifying it, nor does it discuss any other behavioral traits like output format or limitations beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence that directly states the tool's purpose. It is appropriately concise for a simple tool, though it could be more informative without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema and siblings, the description lacks context about output format, prerequisites, or when to use this over other tools. It does not explain what VULTURE detects or any important usage notes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to the parameters beyond what the schema provides. Both parameters are adequately described in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it detects dead/unused code using VULTURE, which is a specific verb and resource. While it distinguishes from siblings like ruff-check and ty-check by focusing on dead code, it doesn't explicitly contrast with analyze-code, which might also analyze code quality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios where other tools would be more appropriate, such as when checking type errors or formatting issues with sibling tools.

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 updatesv0.3.0Jul 6, 2026
- Addedbiome-check
- Addedbiome-format
6 tool updatesv0.2.1May 25, 2026
- First observedanalyze-code
- First observedruff-check
- First observedruff-check-ci
- First observedruff-format
- First observedty-check
- First observedvulture-scan

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze-code is a comprehensive analysis, while specific tools handle linting (ruff-check, ruff-check-ci), formatting (ruff-format), type checking (ty-check), and dead code detection (vulture-scan). No overlap that causes confusion.

Naming Consistency5/5

All tool names follow a consistent lowercase hyphen-separated pattern (e.g., ruff-check, ty-check, vulture-scan, analyze-code). The verb-noun structure is predictable and uniform.

Tool Count5/5

With 6 tools covering linting, formatting, type checking, dead code detection, and a combined tool, the count is well-scoped for a Python code analysis server. No redundancy or missing essential operations.

Completeness4/5

The tool set covers the main static analysis tasks (linting, formatting, type checking, dead code) and includes a comprehensive tool. Minor gap: no security linting or complexity analysis, but the core workflows are well-covered.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361

Related MCP Servers

ruff-mcp-server
Code Analysis Developer Tools
drewsonne
A
license
B
quality
D
maintenance
An MCP server that integrates Ruff linting, formatting, and code analysis tools with advanced logging and configuration options for AI coding assistants.
Updated a year ago (2025-07-30 08:10 UTC)
4
1
MIT
codetest-mcp
Code Analysis Developer Tools
jihyun0410
F
license
Not graded
quality
B
maintenance
MCP server for static code analysis using AST parsing and linters, providing tools to detect syntax errors, type issues, typos, and incorrect variable usage across multiple languages. It supports headless linting with tools like ast_check, lint_check, and health.
Updated 3 days ago (2026-09-03 08:35 UTC)
-
python-mcp
Code Analysis Developer Tools
yriveiro
A
license
A
quality
C
maintenance
This MCP server provides direct access to ruff linting, formatting checks, and ty type-checking for Python projects, with token-efficient, structured output.
Updated a month ago (2026-08-10 15:03 UTC)
9
MIT
pyfmcp
Developer Tools Testing & QA Tools Code Analysis
pzarczynski
A
license
B
quality
C
maintenance
An MCP server that runs Python project checks through pytest, Ruff, and basedpyright, with configurable settings and stdio/HTTP transport.
Updated a month ago (2026-08-08 20:35 UTC)
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Anselmoo/mcp-server-analyzer'

If you have feedback or need assistance with the MCP directory API, please join our Discord server