Skip to main content
Glama

run_tests

Execute pytest tests in a Python virtual environment to validate code functionality, with options for specific paths, test names, verbose output, or test collection only.

Instructions

Run pytest tests using the specified Python virtual environment.

Args: test_path (str, optional): Directory or file path containing tests to run test_name (str, optional): Specific test function/method to run verbose (bool, optional): Run tests in verbose mode collect_only (bool, optional): Only collect tests without executing them

Returns: dict: Test execution results including returncode, output, and execution time

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
test_pathNo
test_nameNo
verboseNo
collect_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Main handler for the 'run_tests' MCP tool. Validates PYTHON_VENV, builds pytest CLI arguments based on inputs, and delegates execution to the _run_tests helper.
    async def run_tests(
        test_path: Optional[str] = None,
        test_name: Optional[str] = None,
        verbose: bool = False,
        collect_only: bool = False,
    ) -> Dict[str, Any]:
        """
        Run pytest tests using the specified Python virtual environment.
    
        Args:
            test_path (str, optional): Directory or file path containing tests to run
            test_name (str, optional): Specific test function/method to run
            verbose (bool, optional): Run tests in verbose mode
            collect_only (bool, optional): Only collect tests without executing them
    
        Returns:
            dict: Test execution results including returncode, output, and execution time
        """
        if self.python_venv is None:
            return {
                "error": "No Python environment found. It needs to be set in the MCP config as environment variable called PYTHON_VENV."
            }
        # Build pytest arguments
        pytest_args = []
    
        # Add test path if specified
        if test_path:
            pytest_args.append(test_path)
    
        # Add specific test name if specified
        if test_name:
            pytest_args.append(f"-k {test_name}")
    
        # Add verbosity flag if specified
        if verbose:
            pytest_args.append("-v")
    
        # Add collect-only flag if specified
        if collect_only:
            pytest_args.append("--collect-only")
    
        # Run the tests
        return self._run_tests(pytest_args)
  • Core execution logic for running pytest via subprocess. Handles venv selection, command construction, output capture, timing, and error handling. Called by the run_tests handler.
    def _run_tests(self, pytest_args=None, python_venv=None):
        """
        Run pytest tests using the specified Python virtual environment.
    
        Args:
            pytest_args (list, optional): List of arguments to pass to pytest
            python_venv (str, optional): Path to Python executable in virtual environment
                                     If not provided, uses PYTHON_VENV environment variable
    
        Returns:
            dict: Test execution results including returncode, output, and execution time
        """
        try:
            # Determine the Python executable to use
            python_venv = (
                python_venv or self.python_venv
            )  # Use the class level python_venv
    
            # If no venv is specified, use the system Python
            python_cmd = python_venv or "python"
    
            # Build the command to run pytest
            cmd = [python_cmd, "-m", "pytest"]
    
            # Add any additional pytest arguments
            if pytest_args:
                cmd.extend(pytest_args)
    
            # Record the start time
            start_time = datetime.datetime.now()
    
            # Run the pytest command
            process = subprocess.run(cmd, capture_output=True, text=True)
    
            # Record the end time and calculate duration
            end_time = datetime.datetime.now()
            duration = (end_time - start_time).total_seconds()
    
            # Return the results
            return {
                "status": "success" if process.returncode == 0 else "failure",
                "returncode": process.returncode,
                "stdout": process.stdout,
                "stderr": process.stderr,
                "duration": duration,
                "command": " ".join(cmd),
            }
        except Exception as e:
            return {
                "status": "error",
                "error": str(e),
                "command": " ".join(cmd) if "cmd" in locals() else None,
            }
  • Supporting MCP tool to set PYTHONPATH environment variable before running tests, ensuring the project modules are discoverable by pytest.
    async def set_python_path(path: str):
        """
        Set it before running tests so the project is correctly recognized
        """
        os.environ["PYTHONPATH"] = path
  • FastMCP decorator registering the run_tests function as an MCP tool.
    async def run_tests(
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 provides minimal behavioral context. It mentions the tool runs tests in a virtual environment but doesn't disclose critical behaviors like: whether it modifies files, what happens if tests fail, if it requires specific permissions, execution timeouts, or how results are structured beyond the basic return dict. The description doesn't contradict annotations (none exist).

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 well-structured with clear sections (purpose statement, Args, Returns) and appropriately sized. The opening sentence efficiently states the core purpose. The Args section is necessary given the 0% schema coverage. Only minor improvement possible by integrating parameter explanations more seamlessly.

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?

Given 4 parameters with 0% schema coverage and no annotations, the description does a good job explaining parameters and return values. However, for a test execution tool that could have significant behavioral implications (modifying state, long-running processes, failure modes), the description lacks important context about execution environment, error handling, and behavioral constraints that would be needed for safe agent use.

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?

With 0% schema description coverage, the description compensates well by clearly explaining all 4 parameters in the Args section, adding meaningful context about what each parameter controls. The description provides semantic value beyond the bare schema by explaining test_path accepts 'Directory or file path', test_name is for 'Specific test function/method', and what collect_only actually does ('Only collect tests without executing them').

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 action ('Run pytest tests') and resource ('using the specified Python virtual environment'), distinguishing it from all sibling tools which are file/function operations rather than test execution. The verb 'Run' is precise and unambiguous.

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 about when to use this tool versus alternatives. While it's clearly for running pytest tests, there's no mention of prerequisites (e.g., needing a virtual environment setup), when to use collect_only versus full execution, or how it relates to other testing tools (none exist among siblings).

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

Install Server

Other Tools

Latest Blog Posts

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/danielpodrazka/editor-mcp'

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