# PractiTest MCP > PractiTest brings end-to-end QA management right into your AI client. You can list test cases, track execution runs, audit requirements compliance, and map software defects—all by asking natural questions in chat. It connects every piece of the testing puzzle: from initial requirements to final failed step. ## Overview - **Category:** developer-tools - **Price:** Free - **Tags:** qa-testing, test-management, bug-tracking, requirements-traceability, test-automation, software-quality ## Description Listen up. This server plugs PractiTest right into your AI client, so you don't have to jump through hoops across five different dashboards just to check on QA. It lets your agent orchestrate the entire testing lifecycle via natural conversation, mapping everything from initial business requirements down to specific failed steps. **Tracking Scope and Structure** When you need a high-level view of the project, you can start by listing all defined test sets using `list_sets`. This gives you names, current status flags, planned dates, and who's assigned to test them. To see every single test case in the system, run `list_tests`; this returns a JSON:API format list showing IDs, statuses, and any traceability links attached to those tests. If you want to drill down on specific groups of tests, use `get_set`. You'll get the name, status, instance count, and execution summary for that exact test set. For an even finer grain view of a single set, `list_instances` shows every individual copy of a test case—the IDs and their last run statuses. If you want to know what custom data fields are floating around in your project, check out `list_custom_fields`; it'll show the field name, type, and possible values. **Monitoring Execution and Failures** Need to track how well everything’s running? You can pull up a list of every test run execution using `list_runs`. This gives you IDs, status markers (PASSED or FAILED), duration times, and timestamps for every attempt. To trace exactly why something failed—a key capability for finding the root cause—the agent uses historical data from those runs to pinpoint precisely which step threw a failure flag. To get all the nitty-gritty details on one test case, you run `get_test`. This pulls up everything: its name, specific steps it includes, what preconditions must be met before running, the expected results, and any linked requirements. You can also use `list_examples` to pull all details for a single test case. **Auditing Compliance and Defects** For compliance checks, you don't have to manually count anything. Running `list_requirements` gives you every business requirement, showing its current status and exactly how many test cases are pointing back to it in the project. This lets you audit system compliance at a glance. When things go wrong, your agent handles defect triage. Using `list_issues`, you retrieve all reported defects, giving you the issue name, severity level, and which specific test instances they’re linked to. If you've got questions about who works here, run `list_users` to get names, emails, and assigned roles for every user in your PractiTest account. **The full capability set lets you:** * Audit the entire project against its business requirements using `list_requirements`. * Identify open defects by listing issues with `list_issues`, showing severity and linked test instances. * View complete test case details, including steps, expected results, and preconditions, via `get_test`. * Map out all users and their roles using `list_users`. It's this deep connection that lets your agent manage the entire QA scope—it doesn't just list things; it connects requirements to tests, tracks runs, and pins down defects. You don't need a dozen tabs open. ## Tools ### list_tests Returns a list of every test case in the project, showing IDs, statuses, and traceability links. Uses JSON:API format. ### get_test Pulls all details for one test case: name, steps, preconditions, expected results, and linked requirements. ### list_sets Lists all defined test sets in the project, including names, status, planned dates, and assigned testers. ### get_set Retrieves the name, status, instance count, and execution summary for a specific test set. ### list_instances Lists individual copies of test cases within a set, showing IDs and last run statuses. ### list_runs Provides a list of every test run execution, returning IDs, statuses (PASSED/FAILED), durations, and timestamps. ### list_requirements Lists all business requirements, showing their current status and how many test cases reference each one. ### list_issues Retrieves all defects (issues) in the project, including status, severity, and which tests are linked to them. ### list_custom_fields Shows all custom data fields available in the project, including their types and possible values. ### list_users Lists all user accounts associated with your PractiTest organization, including names, emails, and roles. ## Prompt Examples **Prompt:** ``` List all tests inside our active QA regression instance and find the ones mapped as failed. ``` **Response:** ``` I queried `list_runs` pulling executions. Exactly 3 Test Runs crashed the regression suite: Run ID `1202` (Login Flow Bypass), Run ID `1203` (Cart State Mismatch), and Run ID `1209` (Payment Fallback Failed). Should I extract step histories for #1209 using `get_test`? ``` **Prompt:** ``` Do we have any new custom fields we should be aware of inside the requirements area? ``` **Response:** ``` I analyzed `list_custom_fields` crossing your dictionaries. Let's see... a new custom List field 'GDPR Category' (ID 402) was instantiated targeting Requirement entities with possible values strings: ['P1', 'P2', 'Ignore']. ``` **Prompt:** ``` Are there any open defects (issues) linked directly to testing scenarios surrounding multi-currency operations? ``` **Response:** ``` Investigating `list_issues`, I see one highly relevant defect: 'EUR vs GBP Cart Rounding Error' (Issue ID #91). It carries a `High` severity and it strictly ties to instances in your 'Multicurrency V2' test cluster. Current status: UNRESOLVED. ``` ## Capabilities ### Trace a failed execution step The agent retrieves detailed historical data for specific test runs, showing statuses (PASSED/FAILED) and pinpointing exactly where the failure occurred. ### Audit system compliance against requirements You query all defined business requirements to see their current status and how many tests are linked to them in the project. ### Identify open defects tied to test clusters The agent searches for reported issues, giving you the issue name, severity, and which specific test instances they relate to. ### View full test case details You pull up a single test case to review its preconditions, expected results, steps, and associated custom metadata. ### Map user accounts and roles The agent lists all users in the PractiTest account, showing their name, email, and assigned role. ## Use Cases ### The sudden regression: A developer reports a failure in the payment flow. Instead of manually checking logs, they ask the agent: 'List runs for Payment Flow and check associated issues.' The agent uses `list_runs` to find the failed run ID, then calls `list_issues` to pull up 'Payment Fallback Failed' (Issue #129), giving the developer the exact context needed to start fixing. ### Auditing for regulatory compliance: A Product Owner needs proof that the GDPR requirement is fully tested. They ask: 'Show all requirements linked to GDPR.' The agent uses `list_requirements` and then checks the associated test links, giving them a clear list of coverage gaps or unaddressed statuses. ### Understanding dependencies: A tester is reviewing a large feature set. They ask: 'What are all the tests in Set X?' The agent calls `list_sets` to get the group, then uses `list_instances` and `get_test` repeatedly to build a complete map of every single test case included. ### Onboarding new team members: A manager needs an overview of current users and roles. They ask: 'Who is on the QA team?' The agent runs `list_users`, providing a clean roster with roles, saving time spent navigating internal directories. ## Benefits - Stop jumping between tabs. You can ask the agent to run `list_issues` and immediately see if a defect is tied to a specific requirement or test set, all in one response. - When debugging a failure, you don't need to open the runner UI. Ask for `list_runs`, pinpoint the Run ID, and use `get_test` to pull up the exact steps that failed. - Compliance checks are instant. Instead of manually cross-referencing documents, ask for `list_requirements`. The agent shows you which requirements lack test coverage or have open defects linked via `list_issues`. - Understand your testing scope quickly. By calling `list_tests` and then checking the details with `get_test`, you get a full picture of every single test case, its purpose, and its dependencies. - See who did what. Use `list_users` to manage access or check team assignments via `list_sets` without leaving your primary workflow. ## How It Works The bottom line is that your AI client becomes an expert QA analyst, pulling together scattered information from your whole test management platform instantly. 1. Subscribe to this server and supply your PractiTest Personal API Token and Project ID. 2. Launch your AI client (Claude, Cursor, etc.) and tell the agent what you need—for example: 'Why did the Payment flow fail last night?' 3. The agent uses the relevant tools (`list_runs`, `get_test`) to gather all data and gives you a clean, summarized answer in chat. ## Frequently Asked Questions **How does the list_runs tool work with get_test?** The agent uses `list_runs` to find a specific failed run ID. Then, it passes that ID's context to `get_test` to pull up the detailed steps and expected results for that test case, showing you exactly where the execution broke. **Can I check compliance using list_requirements?** Yes. You ask about a requirement, and the agent uses `list_requirements` to show its status, plus how many tests are linked to it and if any defects have been found against it. **What is the difference between list_tests and get_test?** `list_tests` gives you a summary of every test case (names, IDs, statuses). `get_test` digs into one specific ID to show all the granular data: preconditions, steps, expected results, etc. **Does list_issues track which test instances are affected?** Yes. When you call `list_issues`, the returned defect records contain links directly back to specific test references, allowing you to narrow down exactly where the bug appeared in the test suite. **What data fields can I expect when using list_tests?** The `list_tests` tool returns comprehensive records for each test case. You'll get names, IDs, statuses, custom field metadata, and explicit traceability links baked into the output. **How do I check which users are available using list_users?** The `list_users` tool provides an immediate roster of all accounts in your PractiTest project. It returns user names, corresponding emails, their defined roles, and current account statuses. **Can I use get_set to understand the scope versus just a single test case?** Yes, `get_set` gives you an execution summary for groups of tests. It shows the set's status, how many instances are included, and overall run statistics, which is broader than any single test case. **What is the purpose of list_custom_fields?** The `list_custom_fields` tool shows every custom field available in your project. It lists the field names, their data types, which entities they apply to, and any possible values defined. **Can the AI provide the exact step where a test case failed?** Yes. If an execution failed, the agent uses `list_runs` for the instance. Since an instance maps directly to test steps, the AI inherently decodes the exact execution traces to show you the failing parameters. **Is PractiTest's requirement and issue tracing accessible to the AI?** Yes. Tools like `list_requirements` and `list_issues` expose full traceability trees. You can ask exactly how many QA instances are mapped to Requirement 5. **Do I need to copy the project ID separately?** Yes. In PractiTest, APIs execute cleanly isolated within specific Project instances. You must provide the numeric Project ID alongside your Personal Token so the underlying `pt-engine` binds queries strictly to that project.