Skip to main content
Glama
lolpack

MCP Pyrefly Autotype Server

by lolpack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

[WORK IN PROGRESS AND UNTESTED - USE AT OWN RISK] MCP Pyrefly Autotype Server

A Model Context Protocol (MCP) server that provides automatic Python type annotation using Pyrefly. This server enables LLMs and AI coding assistants to analyze Python code, add type annotations, and perform type checking seamlessly.

What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard that enables AI assistants and language models to securely access external data sources and tools. MCP servers act as bridges between AI systems and various resources, providing structured access to information and capabilities.

How MCP Works

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   LLM/AI Client │◄──►│   MCP Server    │◄──►│  External Tools │
│   (e.g. Claude) │    │  (This Project) │    │   (Pyrefly)     │
└─────────────────┘    └─────────────────┘    └─────────────────┘

MCP servers can provide:

  • Resources: Static or dynamic data sources (files, databases, APIs)

  • Tools: Executable functions that perform actions

  • Prompts: Templated prompts for specific tasks

This allows AI assistants to:

  • Access real-time information

  • Perform complex operations

  • Integrate with existing tools and workflows

  • Maintain security through controlled access

Related MCP server: @lex-tools/codebase-context-dumper

Features

This MCP server provides comprehensive Python type annotation capabilities:

🔍 Analysis Tools

  • File Analysis: Analyze individual Python files for missing type annotations

  • Project Context: Get project-wide type information for better inference

  • Pyrefly Integration: Leverage Pyrefly's powerful type inference engine

⚡ Type Enhancement

  • Automatic Type Addition: Add type annotations using Pyrefly's autotype feature

  • File-based Processing: Process individual Python files with type annotations

  • Optional Backup: Can create backup files before modification (when requested)

  • Project Integration: Respects pyrefly configuration files

✅ Type Checking

  • Pyrefly Integration: Validate type annotations using Pyrefly's built-in type checker

  • Error Reporting: Basic type checking results and error output

  • File-based Validation: Check individual files for type errors

🤖 LLM Integration

  • Basic Prompts: Pre-built prompts for type analysis tasks

  • Structured Data: JSON-formatted analysis results

  • Simple Workflows: Basic analyze → annotate → verify workflows

Why Use This MCP Server?

For LLMs and AI Assistants

  • MCP Integration: Works with MCP-compatible AI clients

  • JSON Responses: Provides structured data for better decision making

  • Basic Context: Simple project structure analysis

  • Error Handling: Basic error reporting and graceful failure handling

For Developers

  • Cold Start Helper: Assists with completely untyped codebases

  • Basic Typing: Simple type annotation workflows

  • File Processing: Individual file type checking and annotation

  • Tool Integration: Basic integration with existing Python development workflows

Installation

Prerequisites

Install the MCP Server

# Clone or download this repository
git clone https://github.com/your-username/mcp-pyrefly-autotype.git
cd mcp-pyrefly-autotype

# Install dependencies with uv
uv sync

# For development (includes dev dependencies)
uv sync --dev

# Alternative: traditional pip install
# pip install -e .
# pip install -e ".[dev]"

Usage

Running the Server

The server can be run directly or integrated with MCP-compatible clients:

# Run directly (for testing)
uv run python -m mcp_pyrefly_autotype.server

# Or use the installed script (after uv sync)
uv run mcp-pyrefly-autotype

# Alternative: activate virtual environment first
uv shell
python -m mcp_pyrefly_autotype.server

Integration with AI Clients

Claude Desktop (Example Configuration)

Add to your Claude Desktop configuration:

{
  "mcpServers": {
    "pyrefly-autotype": {
      "command": "uv",
      "args": ["run", "python", "-m", "mcp_pyrefly_autotype.server"],
      "env": {}
    }
  }
}

VS Code with Copilot

  1. Install the MCP extension for VS Code

  2. Configure the server in your workspace settings:

  3. Create a .vscode/mcp.json file

{
	"servers": {
		"pyrefly-autotype": {
			"type": "stdio",
			"command": "uv",
			"args": [
				"run",
				"mcp-pyrefly-autotype"
			]
		}
	},
	"inputs": []
}

Make it show up in VS Code (MCP Servers + Copilot Chat Tools)

  1. Install the “Model Context Protocol (MCP)” extension in VS Code and ensure GitHub Copilot is enabled/updated.

  2. Save the .vscode/mcp.json file shown above in the root of your workspace.

  3. Reload the window: press Ctrl+Shift+P → “Developer: Reload Window”.

  4. Verify in the MCP Servers view:

    • Open the Command Palette (Ctrl+Shift+P) → run “MCP: Show Servers”, or open the “MCP Servers” view from the Activity Bar.

    • You should see a server named pyrefly-autotype. Status should be Running. If not:

      • Confirm uv is installed and on PATH, and that uv sync has been run.

      • On Windows, you may need to restart VS Code after installing Python/uv.

  5. Verify in Copilot Chat Tools:

    • Open Copilot Chat (Ctrl+I or the Copilot icon).

    • In the Tools pane, expand the MCP section. You should see pyrefly-autotype listed. If it’s missing, check that:

      • The workspace is trusted (look for the “Trust” banner in VS Code).

      • MCP integration is enabled in Copilot settings.

Run sample queries (inside Copilot Chat)

Try these prompts in a new Copilot Chat tab. Copilot will call the server’s tools for you.

  • “Use the pyrefly-autotype MCP server to analyze the file simple_untyped.py (detailed=true), then add types to it, and finally type check it. Repeat add→check up to 3 times until type check passes.”

  • “Analyze example_untyped.py for missing annotations, add types with a backup, and run a type check. Summarize changes and remaining warnings.”

  • “Given the loop in SamplePrompt.md, run the agent loop on simple_untyped.py: add_types_to_file → type_check_file, refining up to 3 rounds.”

Expected outcomes:

  • Copilot will invoke these MCP tools: analyze_python_file, add_types_to_file, type_check_file.

  • The file will be annotated in-place (a backup may be created depending on your request).

  • You’ll receive a summary and any remaining non-blocking warnings.

Available Tools

analyze_python_file

Analyze a Python file for missing type annotations.

Parameters:

  • file_path (required): Path to the Python file

  • detailed (optional): Include detailed analysis information

Example:

# LLM can request:
# "Analyze the file 'src/utils.py' for type annotation needs"

add_types_to_file

Add type annotations to a Python file using Pyrefly (this invokes pyrefly autotype under the hood).

Parameters:

  • file_path (required): Path to the Python file

  • backup (optional): Create backup before modifying (default: true)

Example:

# LLM can request:
# "Add type annotations to 'src/models.py'"

type_check_file

Run type checking on a Python file using Pyrefly.

Parameters:

  • file_path (required): Path to the Python file

Example:

# LLM can request:
# "Type check the file 'src/api.py' and report any errors"

get_project_context

Get project-wide type information for better inference.

Parameters:

  • project_path (required): Path to the project directory

Example:

# LLM can request:
# "Analyze the project structure for type annotation opportunities"

Available Prompts

analyze_typing_needs

Generate analysis prompts for type annotation needs.

type_improvement_plan

Create a comprehensive plan for improving type coverage in a project.

Example Workflows

1. Complete File Type Enhancement

# LLM workflow:
# 1. "Analyze 'calculator.py' for type needs"
# 2. "Add types to 'calculator.py'"
# 3. "Type check 'calculator.py' and report results"

2. Project-Wide Type Analysis

# LLM workflow:
# 1. "Get project context for '/my-project'"
# 2. "Create a type improvement plan for the project"
# 3. "Prioritize files for type annotation"

3. Cold Start Type Addition

# For completely untyped files:
# 1. "Analyze 'legacy_code.py' - it has no types at all"
# 2. "Add types to 'legacy_code.py'" 
# 3. "Check for type errors and suggest corrections"

Use Cases

🥶 Cold Start Projects

  • Challenge: Legacy codebases with no type annotations

  • Solution: Use Pyrefly autotype with basic MCP integration

  • Benefit: Start adding types to untyped codebases

📈 Incremental Typing

  • Challenge: Adding types to active projects gradually

  • Solution: File-by-file type annotation with basic project context

  • Benefit: Gradual type adoption without major disruption

🔧 CI/CD Integration

  • Challenge: Maintaining type quality in team projects

  • Solution: Basic type checking integration in pipelines

  • Benefit: Simple type validation workflows

🤝 LLM-Assisted Development

  • Challenge: LLMs need context about typing needs

  • Solution: Basic structured analysis data and simple prompts

  • Benefit: Improved AI assistance for Python type annotation tasks

Configuration

Pyrefly Configuration

The server respects Pyrefly's configuration. You can configure Pyrefly in your project using either:

  1. pyrefly.toml file in your project root:

# Files to include in type checking  
project-includes = ["src/**/*.py"]

# Files to exclude from type checking
project-excludes = ["tests/**", "**/__pycache__/**"]

# Python version to assume
python-version = "3.12"

# How to handle untyped function definitions
untyped-def-behavior = "check-and-infer-return-type"

# Configure specific error types
[errors]
# Enable/disable specific error types
bad-assignment = true
missing-return-type = true

  1. pyproject.toml file under the [tool.pyrefly] section:

[tool.pyrefly]
# Files to include in type checking
project-includes = ["src/**/*.py"]

# Files to exclude from type checking  
project-excludes = ["tests/**", "**/__pycache__/**"]

# Python version and platform
python-version = "3.12"
python-platform = "linux"

# Type checking behavior
untyped-def-behavior = "check-and-infer-return-type"
ignore-missing-imports = ["requests.*", "numpy.*"]

# Error configuration
[tool.pyrefly.errors]
bad-assignment = true
missing-return-type = true

See the Pyrefly Configuration Documentation for all available options.

Development

Running Tests

# Run all tests
uv run pytest tests/

# Run with coverage
uv run pytest tests/ --cov=mcp_pyrefly_autotype

# Run specific test
uv run python tests/test_server.py

# Test server functions directly
uv run python test_direct.py

# Run demo workflow
uv run python test_demo.py

Testing the MCP Server

The project includes several test files to verify functionality:

  • tests/test_server.py - Comprehensive test suite with mocked pyrefly calls

  • test_direct.py - Direct testing of server functions with real pyrefly

  • test_demo.py - Interactive demo showing the complete workflow

  • simple_untyped.py - Example file for testing type annotation

To test the server end-to-end:

# 1. Test with a simple untyped file
uv run python test_demo.py

# 2. Test server functions directly  
uv run python test_direct.py

# 3. Run the MCP server (for client integration)
uv run python -m mcp_pyrefly_autotype.server

Code Quality

# Format code
uv run black src/ tests/

# Lint code  
uv run ruff check src/ tests/

# Type check
uv run pyrefly check src/

Contributing

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

License

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

Related Projects

Support

For questions and support:

  • Open an issue on GitHub

  • Check the Pyrefly documentation

  • Review the MCP specification

This MCP server bridges the gap between AI assistants and Python type annotation tools, enabling seamless integration of type enhancement workflows in AI-powered development environments.

Sample Queries and Prompt Library

The sample_queries/ directory contains ready-to-use prompt templates you can paste into your AI client (VS Code with Copilot MCP or Claude Desktop) to drive the server effectively:

  • sample_queries/PromptWithTools.md — A compact “agent loop” prompt that instructs the assistant to use the available tools (add_types_to_file, type_check_file, and optionally get_project_context) and iterate up to 3 refinement rounds. Great for single-file or small feature work.

  • sample_queries/LargeUntypedCodebase.md — A batch-oriented workflow for incrementally typing a large, mostly-untyped repo. It includes planning, per-file refine loops, batch gates, and progress tracking guidance.

How to use with VS Code + Copilot:

  • Open Copilot Chat. Ensure the pyrefly-autotype MCP server appears under Tools (see instructions above).

  • Open one of the markdown files in sample_queries/, copy the prompt, and paste it into Copilot Chat.

  • If the prompt includes tool call JSON examples, Copilot will translate them into MCP tool invocations automatically.

How to use with Claude Desktop:

  • Ensure your Claude MCP configuration includes this server (see “Claude Desktop” section above).

  • Open a new chat, paste any of the prompts, and follow the agent’s steps. Claude will call the MCP tools using the provided JSON shapes.

Tip: Start with PromptWithTools.md on a single file (e.g., simple_untyped.py) to see the full add → check → refine flow end to end. Then progress to LargeUntypedCodebase.md for multi-file, incremental adoption.

Available Tools

4 tools
add_types_to_fileC

Add type annotations to a Python file using Pyrefly

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the Python file to add types to
backupNoCreate a backup of the original file
aggressiveNoUse aggressive type inference
safe_modeNoUse safe mode for type inference

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose potential side effects (e.g., file modification, backup creation implied by parameter), error conditions, or performance considerations. The mention of 'Pyrefly' hints at external dependency but lacks specifics.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly.

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 and no output schema, the description is incomplete for a tool that modifies files. It lacks information on success/failure outcomes, error handling, and the impact of using 'Pyrefly'. For a mutation tool with 4 parameters, more context is needed to ensure safe and effective use.

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 parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying file modification. Baseline 3 is appropriate as the schema handles parameter details effectively.

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 ('Add type annotations') and target resource ('to a Python file'), specifying the tool 'Pyrefly' is used. It distinguishes from siblings like 'analyze_python_file' or 'type_check_file' by focusing on annotation addition rather than analysis or checking. However, it doesn't explicitly contrast with these siblings in the description text itself.

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 is provided on when to use this tool versus alternatives like 'type_check_file' or 'analyze_python_file'. The description lacks context about prerequisites (e.g., file must exist, Python version compatibility) or typical scenarios (e.g., during refactoring, for static typing).

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

analyze_python_fileB

Analyze a Python file for missing type annotations

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the Python file to analyze
detailedNoInclude detailed analysis information

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('analyze') but does not describe what the analysis entails (e.g., static analysis, runtime checks), output format, error handling, or performance considerations. This leaves significant gaps in understanding the tool's behavior.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to understand at a glance.

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 lack of annotations and output schema, the description is incomplete for a tool that performs analysis. It does not explain what the analysis returns (e.g., a list of missing annotations, statistics, or recommendations), how results are structured, or any behavioral traits like error conditions. This leaves the agent with insufficient context for effective use.

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%, with clear descriptions for both parameters ('file_path' and 'detailed'). The description does not add any additional meaning beyond what the schema provides, such as explaining how 'detailed' affects the analysis output. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 specific verb ('analyze') and resource ('Python file') with a precise purpose ('for missing type annotations'). It effectively distinguishes from sibling tools like 'add_types_to_file' (which modifies files), 'get_project_context' (which retrieves context), and 'type_check_file' (which checks types rather than analyzing for missing ones).

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 usage by specifying the analysis target ('Python file for missing type annotations'), but it does not explicitly state when to use this tool versus alternatives like 'type_check_file' or 'add_types_to_file'. No guidance is provided on prerequisites, exclusions, or specific scenarios for selection.

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

get_project_contextC

Get project-wide type information for better type inference

ParametersJSON Schema
NameRequiredDescriptionDefault
project_pathYesPath to the project directory

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions 'type inference' but doesn't specify what the tool returns (e.g., a summary, structured data, or raw output), whether it's read-only or has side effects, or any performance considerations. It lacks details on behavior beyond the basic purpose.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool with one parameter, though it could be slightly more informative without losing conciseness. The structure is front-loaded with the core function.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a data structure, success status, or error messages), which is critical for a tool focused on 'type information'. For a tool with no structured output documentation, the description should compensate more by detailing expected results or usage 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 input schema has 100% description coverage, with the parameter 'project_path' clearly documented as 'Path to the project directory'. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate since the schema handles the parameter documentation adequately.

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

Purpose3/5

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

The description states the tool 'Get project-wide type information for better type inference', which provides a clear verb ('Get') and resource ('project-wide type information'). However, it doesn't specifically distinguish this from sibling tools like 'analyze_python_file' or 'type_check_file' that also deal with type-related operations. The purpose is understandable but lacks sibling differentiation.

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. It doesn't mention when this tool is appropriate (e.g., for initial project setup, batch analysis) or when to prefer sibling tools like 'analyze_python_file' for file-specific analysis. There's no explicit or implied context for usage decisions.

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

type_check_fileC

Run type checking on a Python file using Pyrefly

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesPath to the Python file to type check

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool runs type checking, implying a read-only analysis, but doesn't specify if it modifies files, requires specific permissions, has rate limits, or what the output format is. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It front-loads the core action and resource, making it easy to scan. Every word earns its place, providing essential information without redundancy.

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's complexity (type checking implies potential for detailed output) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., errors, warnings, success status) or behavioral traits like execution time or dependencies. For a tool with no structured output, more context is needed.

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 fully documents the 'file_path' parameter. The description adds no additional meaning beyond what the schema provides (e.g., no details on path format, supported file types, or examples). Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 type checking') and target resource ('on a Python file'), specifying the tool 'Pyrefly'. It distinguishes from siblings like 'add_types_to_file' (which modifies) and 'analyze_python_file' (which may be broader), but doesn't explicitly contrast them. The purpose is specific but lacks explicit sibling differentiation.

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 is provided on when to use this tool versus alternatives like 'analyze_python_file' or 'get_project_context'. The description implies usage for type checking Python files, but offers no context on prerequisites, exclusions, or comparisons to siblings. It's a basic statement without usage instructions.

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.

  1. 4 tool updates
    • First observedadd_types_to_file
    • First observedanalyze_python_file
    • First observedget_project_context
    • First observedtype_check_file
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: adding types, analyzing for missing types, getting project context, and type checking. There is no overlap in functionality, and an agent can easily differentiate between them based on their specific actions.

Naming Consistency4/5

The tools follow a consistent verb_noun pattern (e.g., add_types_to_file, analyze_python_file), with all using snake_case. However, 'get_project_context' slightly deviates by using 'get' instead of a more action-oriented verb like 'analyze' or 'type', but overall the naming is predictable and readable.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of Python type annotation and checking. Each tool serves a specific role in the workflow, from analysis to application and verification, making the count appropriate and efficient.

Completeness4/5

The tool set covers core workflows for type annotation: analysis, context gathering, type addition, and type checking. A minor gap exists in not having a tool to remove or update existing type annotations, but agents can work around this, and the surface is largely complete for the stated purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches