squish-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SQUISH_PREFIX | Yes | Path to Squish installation directory. | |
| SQUISH_GLOBAL_SCRIPTS | No | Directory storing scripts available for all Squish test cases. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_bdd_contextB | Analyze how BDD is used in a specific test suite. Args:
test_suite_path: Path to a |
| analyze_bdd_documentationA | Parse the local BDD-specific Squish documentation to find relevant information. |
| analyze_existing_patternsC | Analyze test suite to find common patterns that should be used for generating new test cases. Args:
test_suite_path: Path to a |
| analyze_global_scriptsC | Analyze global scripts usage patterns that should be used for generating new test cases. |
| analyze_object_map_structureB | Analyze the current object map structure to understand existing patterns. Args:
test_suite_path: Path to a |
| analyze_object_referencesB | Analyze object-reference patterns that should be used for generating new test cases. This includes where and how object maps are stored and how the objects are then accessed. Args:
test_suite_path: Path to a |
| analyze_squish_api_documentationB | Parse the local Squish documentation to find relevant information like the available functions and code snippets. |
| analyze_squish_rulesB | Analyze project-specific Squish rules (explicitly defined patterns). |
| extract_object_referencesC | Extract object references from test content to understand what objects are being used. Args: test_content: The test code to analyze |
| generate_bdd_templateB | Generate a BDD test template that can be used as a starting point for creating new BDD-style test cases. Args: test_case_name: Name of the test case test_description: Description for the BDD feature (recommended) |
| generate_page_objects_from_snapshotA | Generate page object references from an XML object snapshot file. This tool:
Args:
xml_file_path: Absolute path to the XML object snapshot file
page_name: Name of the page/component these objects belong to
test_suite_path: Path to a Note:
To generate the XML snapshot file, a testcase script has to call
|
| generate_test_templateA | Generate a test template based on existing patterns and project conventions. Args:
test_suite_path: Path to a |
| suggest_code_improvementsB | Analyze test content and suggest improvements based on project patterns. Args:
test_content: The test code to analyze
test_suite_path: Path to a |
| create_test_caseA | Create a new Squish test case within an existing test suite. Args: suite_path: Absolute path to the test suite directory (must start with 'suite_') test_case_name: Name of the test case (will be prefixed with 'tst_' if not already) test_content: Python code content for the test.py file (optional) is_bdd: Whether to create a BDD test with proper QtCare Squish BDD structure (default: False) test_description: Description for BDD feature file (optional, recommended for BDD tests) |
| create_test_suiteA | Create a new Squish test suite with the standard directory structure. Creates suite.conf and shared/names.py inside the given directory. The suite directory must not already exist. Args: suite_path: Absolute path to the test suite directory to create (must start with 'suite_') wrapper: Name of the wrapper to use (default 'Qt'). Written as WRAPPERS in suite.conf. |
| get_suite_configurationB | Read the suite configuration from a suite.conf file. Args: suite_path: Absolute path to the test suite directory |
| get_global_script_dirsA | Get the global script directories configured in the active Squish test suite. This uses the squishrunner --config getGlobalScriptDirs command. Returns: List of global script directory paths. |
| run_testA | Run a Squish test suite or test case. You need to figure out the test suite and test case absolute paths on your own. You may be asked to either run a full test suite or a single test case within a test suite. This is a wrapper around the squishrunner command line tool. IMPORTANT PATH HANDLING AND SQUISH TEST NAMING CONVENTIONS:
Args: test_suite_path: Absolute path to the test suite which you should figure out on your own Example: "/Users/yourname/projects/addressbook/suite_py" context: Dictionary variables of options to pass to Squish Format: {"VAR_NAME": "value"} test_case_name: Name of the test case to run. Example: "tst_general" Returns: Test run results with squishrunner output. |
| set_global_script_dirsA | Set the global script directories for Squish test execution. Args: directories: List of directory paths to set as global script directories |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
Most tools have distinct purposes, but there is some overlap among analysis tools (e.g., analyze_bdd_context vs analyze_bdd_documentation, analyze_existing_patterns vs analyze_global_scripts). Descriptions are detailed enough to differentiate, but an agent might occasionally misinterpret which analysis tool to use.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_bdd_context, create_test_case, generate_bdd_template). There are no deviations or mixed conventions, making the naming predictable.
With 19 tools covering analysis, creation, running, and configuration, the set is well-scoped for a Squish testing server. Each tool serves a clear role without being excessive or insufficient.
The tool surface covers core workflows: creating suites/test cases, analyzing patterns, generating templates, running tests, and managing global scripts. Minor gaps exist, such as missing update/delete operations for test cases or suites, but agents can work around them.