How do I use prospector-mcp?

1. Click on "Deploy 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., "@prospector-mcp Run Prospector analysis on the src directory." 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.

prospector-mcp

by athoune

Overview Schema Source Related Servers Discussions Admin

Python

Local

Prospector MCP Server

An MCP (Model Context Protocol) server that exposes Prospector — the Python static analysis tool — through its native Python API.

Features

Run Prospector on a single file or an entire directory.
Return structured, machine-readable results (messages with severity, location, rule code).
Layered TOML configuration with sensible defaults.
Supports both stdio and SSE transports via FastMCP.
Secure by default: respects .gitignore, ignores .env / .venv, validates paths, enforces timeouts.

Related MCP server: MegaLinter MCP Server

Installation

Via `uvx` (recommended)

uvx run prospector-mcp

Via `pip`

pip install prospector-mcp
prospector-mcp

Development setup

git clone https://github.com/yourname/prospector-mcp.git
cd prospector-mcp
pip install -e ".[dev]"
pytest

Usage

Claude Desktop / OpenCode

Add the server to your MCP settings:

{
  "mcpServers": {
    "prospector": {
      "command": "uvx",
      "args": ["run", "prospector-mcp"]
    }
  }
}

SSE transport

prospector-mcp --transport sse
# or
prospector-mcp --sse

Configuration

Configuration is layered (later layers override earlier ones):

Built-in defaults
Global config: ~/.config/prospector-mcp/config.toml
Project config: .prospector-mcp.toml in the project root

Example `.prospector-mcp.toml`

[prospector]
timeout = 60
strictness = "medium"
profile = "default"
ignore = [".tox", "build", "dist"]

[server]
transport = "stdio"

Tools

`prospector.run`

Run Prospector on a target path.

Parameters:

target (string, required): Path to a Python file or directory.
profile (string, optional): Override the Prospector profile.
strictness (string, optional): Override strictness (verylow to veryhigh).

Returns: Structured dict with summary, messages, and execution_time.

`prospector.check_ready`

Check if Prospector is installed and available.

License

MIT

Available Tools

2 tools

prospector_check_readyA

Check whether Prospector is installed and report its version.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It states the tool checks installation and reports version, but does not disclose behavior if Prospector is not installed (e.g., error vs. false response). No mention of side effects or read-only nature.

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, no extraneous words. Perfectly concise for a simple tool.

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 tool has no parameters, an output schema exists (so return values are documented there), and complexity is low, the description adequately conveys the tool's purpose. Could mention error behavior, but not strictly necessary.

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

Parameters4/5

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

No parameters exist (schema coverage 100% trivially). Baseline 4 for 0 params; description adds no param info but is not needed.

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?

Clearly states the verb 'check whether ... installed' and the resource 'Prospector', plus 'report its version'. Distinguishes from sibling 'prospector_run' which would likely run the tool, not check readiness.

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?

Implicitly suggests using before running prospector_run, but does not explicitly state when to use or when not, nor any alternatives. For a simple 0-param tool, this is acceptable but not explicit.

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

prospector_runC

Run Prospector static analysis on a file or directory.

ParametersJSON Schema

Name	Required	Description
`target`	Yes	Absolute or relative path to a Python file or directory.
`profile`	No	Prospector profile to use (overrides config).
`strictness`	No	Strictness level (overrides config).

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It does not disclose behavioral traits such as whether the tool modifies files, error handling, or output format. Only states it runs analysis.

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

Conciseness3/5

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

The description is very concise (one sentence), but it lacks substance needed for a tool with 3 parameters and no annotations. It is front-loaded but under-specified.

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 no annotations, 3 parameters, and the existence of an output schema, the description does not explain what the tool returns or how to interpret results. The description is insufficiently complete for a static analysis tool.

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 beyond the parameter descriptions in the schema (e.g., 'target', 'profile', 'strictness'). No additional parameter guidance.

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 action (Run) and resource (Prospector static analysis on a file or directory), and the sibling 'prospector_check_ready' implies a different function. However, it lacks detail on the scope or output.

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 vs the sibling 'prospector_check_ready' or other alternatives. The description does not provide any usage context or prerequisites.

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.

2 tool updatesv0.3.0Jul 29, 2026
- First observedprospector_check_ready
- First observedprospector_run

Deploy Server

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

TDQS

B3.4/5.0

Scored 2026-07-29 19:25 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one runs the analysis, the other checks installation. No overlap.

Naming Consistency5/5

Both tools follow a consistent 'prospector_' prefix with a verb (run, check_ready). Clear and predictable pattern.

Tool Count3/5

Only 2 tools for a static analysis server feels minimal but not unreasonable if the scope is limited to running checks.

Completeness2/5

Missing common operations like listing rules, retrieving results, or configuring the analysis. Gaps are significant for a typical analysis workflow.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Compuute MCP Security Scanner A
io.github.Compuute
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
Security Code Analysis Version Control
12
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
mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21
MCP Surface Lint A
io.github.DLeibner
Statically audits MCP tool surfaces for token cost, schema quality, and design issues.
Developer Tools Code Analysis
11

Related MCP Servers

code-quality-mcp
Developer Tools Code Analysis
Javier-Morenosa
F
license
Not graded
quality
D
maintenance
Provides deterministic Python code quality analysis using flake8, mypy, McCabe, and vulture, enabling LLMs to access real linting and type checking results.
Updated 4 months ago (2026-05-17 16:24 UTC)
1
-
MegaLinter MCP Server
Developer Tools Code Analysis Testing & QA Tools
DownAtTheBottomOfTheMoleHole
A
license
B
quality
A
maintenance
Enables running MegaLinter linting, configuration, and analysis through MCP tools. Works with any CI/CD platform or locally.
Updated 3 days ago (2026-09-09 20:28 UTC)
15
67
3
MIT
promptpack
cognis-digital
F
license
Not graded
quality
C
maintenance
Enables AI agents to scan codebases for prioritized findings (TODO, FIXME, XXX) and retrieve results in table, JSON, or SARIF format via MCP.
Updated 2 months ago (2026-06-30 03:10 UTC)
-
Mcp Server
Code Analysis Developer Tools
jspark2504
F
license
Not graded
quality
D
maintenance
Enables dependency, security, and coding convention checks for Python and Java projects via MCP tools. Supports local paths or Git URLs.
Updated 5 months ago (2026-03-29 15:27 UTC)
-

Prospector MCP Server

Features

Installation

Via uvx (recommended)

Via pip

Development setup

Usage

Claude Desktop / OpenCode

SSE transport

Configuration

Example .prospector-mcp.toml

Tools

prospector.run

prospector.check_ready

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

code-quality-mcp

MegaLinter MCP Server

promptpack

Mcp Server

Via `uvx` (recommended)

Via `pip`

Example `.prospector-mcp.toml`

`prospector.run`

`prospector.check_ready`