Testmo MCP

Write better code, faster, by learning from your existing tests. With the official Testmo MCP, not only can you supercharge your QA workflows: you can drive faster, more effective AI-coding to ship new features faster than ever.

How It Works: AI-Powered QA

The official Testmo Model Context Protocol ("MCP") unlocks hundreds of power-ups for your QA workflow. It is available wherever you connect to MCPs today, like from AI-powered IDEs like VS Code or Cursor, AI assistants like Claude or ChatGPT, etc.

Once authenticated, Testmo MCP exposes a number of tools built on our existing API endpoints, enabling you to use natural language prompts or task AI agents to achieve valuable QA workflows like:

• Analyze test coverage for new requirements & generate test cases to fill the gaps
• Refactoring tests based on new updates, and converting manual test candidates to automated tests
• Generating new test runs for new pull requests

How It Works: Tests as Context for Code Generation

The real power of Testmo's MCP starts to become clear the more deeply you integrate it with AI-coding pipelines.

The Challenge: Code That Breaks Existing Functionality

You're building a new feature or refactoring existing code. You're using AI agents to speed up the process. You've added your user stories as context, but AI doesn't know how your existing functionality works or what might break. Your test suite contains critical knowledge about how the system works—edge cases, validation rules, integration points, business logic—but that knowledge is locked away in test case descriptions and steps.

Traditional approaches:

• Read through hundreds of test cases manually (too slow)
• Hope your code review catches breaking changes (too risky)
• Wait for tests to fail in CI (too late) - Write code without understanding what already works (too dangerous)

The official Testmo MCP: Transform your test repository into an AI-powered knowledge base that your AI coding assistant can use to write better code faster, more effectively, and in less time.

The Solution

The Testmo MCP connects your test repository to any MCP-compatible AI assistant through the Model Context Protocol (MCP), enabling a powerful new workflow:

1. You describe what you want to build

You: I need to refactor the payment processing code to support subscription renewals with automatic retry logic for failed payments

2. Your AI assistant analyzes your existing tests

Behind the scenes, your AI assistant searches your Testmo test repository to find:

• How payment processing currently works
• What validation rules exist
• What error scenarios are already tested
• What edge cases have been discovered over time
• What integrations and dependencies exist

3. Your AI assistant generates code that respects existing behavior

Instead of writing code from scratch, your AI assistant:

• Incorporates knowledge from your tests into the implementation
• Identifies requirements you didn't mention but that exist in your tests
• Warns about potential breaking changes before you write code
• Suggests test cases you should add for new functionality

4. Your code ships with confidence

The result: code that works with your existing system, not against it.

Why This Matters: Real Examples

Example 1: Hidden Validation Rules

Without Testmo MCP:

You: Add a discount code field to the checkout form

AI Assistant: [Generates basic HTML form field with simple validation]

Result: Ships to production, breaks because discount codes have
complex validation rules (expiration dates, user eligibility,
product restrictions) that weren't mentioned in the requirements.

With Testmo MCP:

You: Add a discount code field to the checkout form

AI Assistant: I found 12 test cases related to discount code validation. Before generating the code, let me check what rules already exist:

Validation rules from your tests:
- Discount codes must be 6-12 alphanumeric characters
- Codes are case-insensitive
- Expired codes (past end_date) must be rejected
- Single-use codes can only be applied once per user
- Some codes are product-specific (SKU restrictions)
- Codes can't be combined with sale items
- First-time customer codes require new account (created_at < 30 days)

I'll generate a form field that respects all these rules. The
validation will happen both client-side (user feedback) and
server-side (security), matching your existing patterns.

[Generates complete implementation with proper validation]

Also, I notice you don't have test cases for:
- Multiple discount codes applied simultaneously
- Discount codes during checkout timeout scenarios

Would you like me to add those test cases?

Result: Code ships with complete validation logic on day one. No breaking changes.

Example 2: Understanding Existing Business Logic

Without Testmo MCP:

You: Update the shipping calculator to support international orders

AI Assistant: [Generates basic international shipping logic]

Result: Breaks existing functionality because shipping calculation
has complex rules for free shipping thresholds, promotional shipping, subscription orders, and hazmat handling that weren't in requirements.

With Testmo MCP:

You: Update the shipping calculator to support international orders

AI Assistant: Before modifying the shipping calculator, I analyzed 34 test cases covering shipping logic. Here's what I found:

Existing shipping rules that must be preserved:
✓ Free shipping for orders >$50 (domestic only)
✓ Flat rate $8.99 for subscription boxes (any destination)
✓ Hazmat items require ground shipping (no air freight)
✓ Alaska/Hawaii use different rate tables
✓ PO boxes can't receive priority shipping
✓ Gift cards don't count toward free shipping threshold

For international orders, I need to understand:
- Should the $50 free shipping apply to international orders?
- Do subscription boxes ship internationally?
- What happens with hazmat items for international (likely blocked)?
- How do we handle customs/duties calculation?

Based on your test patterns, I'll implement international shipping
that integrates with these existing rules. Here's my proposed approach:

[Shows detailed implementation plan that preserves existing logic]

Should I proceed with this implementation?

Result: You catch the questions before writing code. Implementation preserves all existing business rules.

Example 3: Preventing Regression in Integrations

Without Testmo MCP:

You: Add a new payment method integration for Buy Now Pay Later

AI Assistant: [Generates integration code based on generic payment patterns]

Result: Integration works, but breaks the existing flow for saved
payment methods, automatic renewal billing, and refund processing
because it doesn't follow the same contract as existing integrations.

With Testmo MCP:

You: Add a new payment method integration for Buy Now Pay Later

AI Assistant: I found 47 test cases covering payment method integrations (credit cards, PayPal, Apple Pay, Google Pay). Let me extract the contract that new payment methods must follow:

Required payment method interface (from existing tests):
1. authorize() - preauth without capture
2. capture() - complete previously authorized payment
3. refund() - full or partial refunds
4. void() - cancel preauth before capture
5. tokenize() - save for future use (required for subscriptions)
6. validate() - verify payment method before charging

Error handling requirements:
- Must return standardized error codes (DECLINED, INSUFFICIENT_FUNDS, etc.)
- Must support idempotency keys for retry safety
- Must emit payment.authorized and payment.captured events
- Must log all API responses for audit

Integration points found in tests:
- Order confirmation emails (triggered by payment.captured event)
- Inventory reservation (released if payment fails within 15 minutes)
- Fraud detection (runs before authorization)
- Tax calculation (must complete before payment)

I'll generate a Buy Now Pay Later integration that implements this
complete interface. The integration will work with your existing:
- Subscription renewal system (via tokenize())
- Refund processing workflows
- Fraud detection system
- Inventory management

Here's the implementation:
[Generates complete integration that matches existing patterns]

Result: New payment method works seamlessly with all existing functionality.

Code Generation with Test Context

Testmo MCP grabs the context your AI assistant needs to help it stay aligned with your intent when generating code.

Step 1: Start with Your Intent

Describe what you want to build in natural language:

You: I need to implement a feature that lets users reschedule their
subscription delivery dates. They should be able to skip a delivery, delay it by up to 30 days, or move it earlier.

Step 2: AI Analyzes Existing Tests

Your AI assistant automatically searches your Testmo repository for relevant context:

AI Assistant: Let me check your existing test cases to understand how subscriptions currently work...

Found 43 relevant test cases across 3 areas:

Subscription Management (18 cases):
- How subscriptions are created and activated
- Billing cycle logic and renewal dates
- Cancellation and pause workflows
- Modification history and audit trails

Delivery Scheduling (12 cases):
- Current scheduling constraints
- What happens when delivery fails
- Notification timing and content
- Integration with fulfillment system

Billing & Payment (13 cases):
- When payment is charged vs. when item ships
- Pro-rating logic for mid-cycle changes
- Refund scenarios
- Payment method validation before schedule changes

Key findings from your tests:

1. Payment Timing Rule:
   Test case #1456 shows subscriptions are charged 3 days before ship date.
   If user reschedules delivery to earlier date, payment must be immediate.

2. Minimum Gap Requirement:
   Test case #1492 shows delivery can't be scheduled <48 hours from now (warehouse needs lead time for picking).

3. Notification Requirements:
   Test cases #1501-1503 show users must receive email 24h before ship date.
   If rescheduling within 24h, different notification template is used.

4. Inventory Lock:
   Test case #1467 shows inventory is reserved 7 days before ship date.
   Rescheduling later releases reservation; rescheduling earlier locks
   inventory sooner (must check availability).

5. Promo Code Impact:
   Test case #1523 shows some promo codes require monthly delivery schedule.
   Rescheduling may invalidate certain promotional subscriptions.

These rules aren't documented anywhere—they're only in your tests.
Should I incorporate all of these into the implementation?

Step 3: Review and Refine Requirements

Your AI assistant surfaces hidden requirements you didn't know existed:

You: Yes, incorporate those rules. But I didn't know about the promo code restriction—can you show me more detail?

AI Assistant: Here's test case #1523 "Promotional subscription must maintain monthly schedule":

Steps:
1. User signs up for subscription with code "MONTHLY50"
2. Subscription created with 50% discount
3. User attempts to change delivery from monthly to every 6 weeks
4. System should reject change with error message
5. User should see: "Your promotional rate requires monthly deliveries"

Expected Result:
- Schedule change blocked
- User shown clear error message
- Option to remove promo code and change schedule
- Promo code remains active if user cancels schedule change

This promotional code pattern is used for:
- MONTHLY50 (50% off monthly subscriptions)
- QUARTERLYSAVE (quarterly delivery discount)
- WEEKLYPLUS (premium weekly subscription)

Your new rescheduling feature needs to check if the active subscription has a promo code with delivery frequency requirements before allowing the schedule change.

Should I add this validation to the implementation?

Step 4: Generate Implementation

Your AI assistant writes code that respects all existing rules:

AI Assistant: Here's the implementation for subscription rescheduling:

[Generates complete code with:]

✓ Validates minimum 48-hour lead time
✓ Checks promo code delivery requirements
✓ Handles payment timing (immediate vs. 3-day advance)
✓ Updates inventory reservations
✓ Sends appropriate notification template
✓ Maintains audit trail of schedule changes
✓ Handles edge case: rescheduling during payment processing window

The code follows your existing patterns:
- Uses SubscriptionModificationService (like pause/resume)
- Emits subscription.schedule_changed event (for audit logging)
- Validates payment method before confirming change (like your other flows)
- Returns standardized error codes matching your test cases

I've also identified 4 new test cases you should add:

1. "Reschedule with promotional code constraint" (validates promo logic)
2. "Reschedule during payment processing window" (edge case)
3. "Reschedule to same-day delivery" (should fail 48h validation)
4. "Reschedule multiple times in same billing cycle" (stress test)

Would you like me to create these test cases in Testmo?

Step 5: Update Test Repository

Keep your test knowledge base current:

You: Yes, create those test cases and link them to the implementation PR

AI Assistant: Created 4 test cases in "Subscriptions > Scheduling" folder:

Case #2891: "Reschedule with promotional code constraint"
- Priority: High
- Linked to: PR #1234
- Tests: MONTHLY50 promo code blocks schedule change to 6-week delivery

Case #2892: "Reschedule during payment processing window"
- Priority: High
- Linked to: PR #1234
- Tests: Schedule change rejected if payment is currently being processed

Case #2893: "Reschedule to same-day delivery"
- Priority: Medium
- Linked to: PR #1234
- Tests: Validation error shown for <48h delivery requests

Case #2894: "Reschedule multiple times in same billing cycle"
- Priority: Medium
- Linked to: PR #1234
- Tests: System handles frequent schedule changes correctly

All test cases include:
- Detailed steps matching your test style
- Expected results with specific error messages
- Links to the implementation PR for traceability

Your test repository now documents the new feature alongside the
rules it preserves. Next engineer who modifies scheduling will have
this context available.

Additional Use Cases

The Testmo MCP supports a wide variety of workflows. You're only limited by your imagination!

Coverage Gap Analysis

Before implementing new features, understand what's already tested:

You: I'm implementing OAuth social login (Google, Facebook, GitHub).
What authentication test coverage already exists?

AI Assistant: Analyzing your authentication test suite...

Current coverage:
✓ Email/password login (18 test cases)
✓ Password reset flow (8 test cases)
✓ 2FA with SMS (6 test cases)
✓ Remember me functionality (4 test cases)
✓ Session management (9 test cases)

Missing coverage for OAuth:
✗ No test cases for third-party authentication
✗ No test cases for account linking (OAuth account + email account)
✗ No test cases for OAuth provider failures
✗ No test cases for permission scope management

Recommendations:
1. Create baseline OAuth tests (successful login, account creation)
2. Test account linking scenarios (prevent duplicate accounts)
3. Test OAuth failure handling (provider down, user denies permission)
4. Test session security (OAuth tokens vs. password sessions)

Would you like me to generate a test case template based on your
existing authentication test patterns?

Test-Driven Refactoring

Use tests to understand legacy code before refactoring:

You: I need to refactor the order processing code—it's become a 2000-line
function. What does it actually do?

AI Assistant: I analyzed 67 test cases that exercise order processing. Here's what that function actually does:

Core Responsibilities:
1. Inventory validation and reservation (14 test cases)
2. Payment processing and authorization (23 test cases)
3. Shipping calculation and carrier selection (12 test cases)
4. Tax calculation (8 test cases)
5. Promotional discount application (10 test cases)
6. Order confirmation and notifications (6 test cases)
7. Fraud detection and risk scoring (5 test cases)
8. Gift wrapping and special instructions (4 test cases)

Based on your test cases, I recommend splitting into:
- OrderInventoryService (handles stock validation, reservation)
- OrderPaymentService (handles payment auth, capture, retry)
- OrderShippingService (handles carrier selection, rate calculation)
- OrderNotificationService (handles emails, SMS confirmations)

Each service should maintain the contracts tested in your existing
test suite. Here's a detailed refactoring plan:

[Shows how to extract services while preserving all tested behavior]

This refactoring preserves all 67 test cases—they'll continue to pass because the behavior doesn't change, only the structure.

Requirements Discovery

Extract requirements from tests for documentation:

You: Generate a requirements specification for our checkout flow based on what's actually implemented and tested

AI Assistant: I analyzed 89 test cases covering checkout. Here's the complete requirements specification:

# Checkout Flow Requirements v2.4

## 1. Cart Management
Requirements extracted from 15 test cases:

REQ-CHK-001: Users must be able to add items to cart from product pages
- Source: Test case #445 "Add product to cart from detail page"
- Status: Implemented and tested

REQ-CHK-002: Cart must persist across sessions for logged-in users
- Source: Test case #446 "Cart persists after logout and re-login"
- Status: Implemented and tested

REQ-CHK-003: Cart must expire after 30 days of inactivity
- Source: Test case #449 "Old cart items expire after 30 days"
- Status: Implemented and tested
- Note: Expiration triggers email to user if cart value >$50

[Continues with all 89 test cases mapped to requirements...]

This document reflects what's actually implemented—based on your
tests, not on outdated requirements docs.

Would you like me to export this as a PDF or push it to Confluence?

Test Case Management

Standard test management operations through natural language:

You: Create test cases for the new email verification feature we just shipped

AI Assistant: I'll create test cases for email verification. First, let me check if similar test cases exist...

Found 8 test cases covering account verification patterns. I'll follow your existing test style.

Created 6 test cases in "Authentication > Email Verification" folder:

Case #2145: "Email verification link sent on signup"
Case #2146: "Verify email with valid token"
Case #2147: "Expired verification token shows error"
Case #2148: "Resend verification email"
Case #2149: "Login blocked until email verified"
Case #2150: "Email verification for profile email changes"

All cases include detailed steps, expected results, and follow your
test case format (Given/When/Then structure with explicit assertions).

Would you like me to add these to your next test run?

Compatible AI Assistants

The Testmo MCP uses the Model Context Protocol (MCP), an open standard created by Anthropic. Any AI assistant that supports MCP can connect to your Testmo test repository through the Testmo MCP.

MCP-Compatible AI Assistants

Claude Desktop & Claude Code - First-party MCP support from Anthropic - Configuration: Add the Testmo MCP to Claude's config file - Conversational coding with extensive context windows, supported by plugins in popular IDE's such as Visual Studio Code.

Codex - MCP support - Configuration: Add Testmo MCP to your MCP settings - IDE integration with code generation

Other MCP-Compatible Tools - The Testmo MCP implements the full MCP specification - Any AI assistant that supports the Model Context Protocol can connect - No vendor lock-in—MCP is an open standard, supported by tools like Cursor, Loveable & Replit.

Setup Requirements

To use the Testmo MCP with any MCP-compatible AI assistant:

1. Your AI tool must support MCP (Model Context Protocol)
2. Testmo MCP connection details (provided during beta setup)
3. API token from your Testmo instance (for authentication)
4. Configuration file pointing to the Testmo MCP endpoint

Setup takes 5-10 minutes and follows the same process regardless of which AI assistant you use.

Example: Complete End-to-End Workflow

Here's a real-world example showing the complete workflow:

Scenario: Adding Multi-Currency Support

Current State: Your e-commerce platform only supports USD. You need to add multi-currency support for international expansion.

Step 1: Initial Request

You: I need to add multi-currency support. We're expanding to UK and EU.

Step 2: AI Analyzes Existing Tests

AI Assistant: Let me analyze your test cases to understand how pricing and
payments currently work...

Found 127 test cases related to pricing, payments, and money handling:

Critical findings:

1. Price Storage (Test cases #234-#241):
   - Prices are currently stored as integers (cents)
   - Database column is INT(11), not DECIMAL
   - All price calculations use integer math to avoid floating point errors
   - Display logic divides by 100 for USD formatting

2. Tax Calculation (Test cases #556-#578):
   - Tax rates are percentage-based (stored as decimals)
   - Tax calculated as: (price_cents * tax_rate) / 100, rounded
   - Different rounding rules for different tax jurisdictions
   - Tax must be calculated AFTER discounts

3. Promotional Discounts (Test cases #445-#467):
   - Discounts stored as percentage OR fixed amount
   - Fixed amount discounts are in cents
   - "Spend $50, get $10 off" promotions compare total in cents
   - Free shipping thresholds are USD-specific ($50, $100)

4. Payment Gateway Integration (Test cases #789-#823):
   - All payment amounts sent to gateway in cents
   - Gateway expects USD (hardcoded in integration)
   - Refunds reference original payment amount
   - Partial refunds must not exceed original charge

5. Financial Reporting (Test cases #890-#901):
   - Revenue reports sum price_cents column
   - Conversion to dollars happens in reporting layer
   - Reports break if non-USD amounts are in database

⚠️ MAJOR BREAKING CHANGES REQUIRED:

Based on your tests, adding multi-currency support will require:

1. Database schema changes:
   - Add currency_code column to prices, orders, payments
   - Cannot reuse price_cents for multiple currencies (exchange rates)
   - Need separate amount + currency fields

2. Payment gateway updates:
   - Must support GBP, EUR in addition to USD
   - Each currency may need separate merchant account
   - Cannot convert currencies at payment time (requires new integration)

3. Tax calculation changes:
   - UK VAT (20%) works differently than US sales tax
   - EU requires showing tax-inclusive prices
   - Must handle multiple tax jurisdictions per order (EU cross-border)

4. Promotional discount updates:
   - "Spend $50" promotions need currency-specific thresholds
   - Fixed-amount discounts need currency conversion
   - Free shipping thresholds need per-currency configuration

5. Financial reporting changes:
   - Reports must group by currency OR convert to base currency
   - Exchange rates needed for consolidated reporting
   - Historical reporting breaks if currency data isn't backfilled

This is a major refactoring, not a simple feature addition. Your test suite shows this system was designed for single-currency operation.

Recommended approach:
1. Start with read-only multi-currency display (convert from USD)
2. Add multi-currency storage infrastructure
3. Migrate payment gateway integration
4. Update tax calculation for international rules
5. Handle promotions and reporting last

Would you like me to generate a detailed implementation plan that
preserves all existing USD functionality while adding multi-currency support?

Step 3: Refine Approach

You: Yes, but start with the UK market only - not full EU yet. Focus on GBP support.

AI Assistant: Good call—that simplifies significantly. Let me create a phased plan focused on GBP:

Phase 1: Infrastructure (Week 1)
- Add currency_code to products, orders, payments tables
- Backfill existing data with 'USD'
- Add CurrencyService for exchange rates (real-time API)
- Update price display to show currency symbol

Test preservation: All 127 existing test cases remain focused on USD and will continue to pass. New GBP tests added separately.

Phase 2: UK Product Pricing (Week 2)
- Allow setting GBP prices on products (optional, separate from USD)
- If no GBP price set, convert USD price at current rate
- Handle GBP-specific pricing rules (£X.99 pricing psychology)
- VAT-inclusive display (UK requirement)

Test impact: 8 product pricing test cases need GBP variants added

Phase 3: Payment Processing (Week 3)
- Configure Stripe for GBP (separate merchant account)
- Route GBP payments to UK merchant account
- Update payment integration tests

Test impact: 34 payment test cases need currency parameter added

Phase 4: Tax Calculation (Week 4)
- Add UK VAT calculation (20% tax-inclusive)
- VAT must be shown separately on invoices
- No tax for Northern Ireland edge cases

Test impact: 23 tax test cases need UK VAT variants added

Phase 5: Promotions & Reporting (Week 5)
- Convert promotional thresholds to GBP (£40 free shipping = ~$50)
- Add currency filter to financial reports
- Exchange rate tracking for consolidated reporting

Test impact: 35 test cases need currency-aware updates

This phased approach:
✓ Preserves all USD functionality (127 existing tests keep passing)
✓ Adds GBP support incrementally (lower risk)
✓ Each phase is independently testable
✓ Allows partial rollout (UK only, can revert easily)

I'll generate the code for Phase 1 - Infrastructure. This code will:
- Add database migrations (currency_code columns)
- Implement CurrencyService with exchange rate API
- Update display logic to show currency symbols
- Preserve all existing USD behavior

Should I proceed?

Step 4: Generate Implementation

You: Yes, but start with the UK market only - not full EU yet. Focus on GBP support.

AI Assistant: Good call—that simplifies significantly. Let me create a phased plan focused on GBP:

Phase 1: Infrastructure (Week 1)
- Add currency_code to products, orders, payments tables
- Backfill existing data with 'USD'
- Add CurrencyService for exchange rates (real-time API)
- Update price display to show currency symbol

Test preservation: All 127 existing test cases remain focused on USD and will continue to pass. New GBP tests added separately.

Phase 2: UK Product Pricing (Week 2)
- Allow setting GBP prices on products (optional, separate from USD)
- If no GBP price set, convert USD price at current rate
- Handle GBP-specific pricing rules (£X.99 pricing psychology)
- VAT-inclusive display (UK requirement)

Test impact: 8 product pricing test cases need GBP variants added

Phase 3: Payment Processing (Week 3)
- Configure Stripe for GBP (separate merchant account)
- Route GBP payments to UK merchant account
- Update payment integration tests

Test impact: 34 payment test cases need currency parameter added

Phase 4: Tax Calculation (Week 4)
- Add UK VAT calculation (20% tax-inclusive)
- VAT must be shown separately on invoices
- No tax for Northern Ireland edge cases

Test impact: 23 tax test cases need UK VAT variants added

Phase 5: Promotions & Reporting (Week 5)
- Convert promotional thresholds to GBP (£40 free shipping = ~$50)
- Add currency filter to financial reports
- Exchange rate tracking for consolidated reporting

Test impact: 35 test cases need currency-aware updates

This phased approach:
✓ Preserves all USD functionality (127 existing tests keep passing)
✓ Adds GBP support incrementally (lower risk)
✓ Each phase is independently testable
✓ Allows partial rollout (UK only, can revert easily)

I'll generate the code for Phase 1 - Infrastructure. This code will:
- Add database migrations (currency_code columns)
- Implement CurrencyService with exchange rate API
- Update display logic to show currency symbols
- Preserve all existing USD behavior

Should I proceed?

Result: Instead of blindly implementing multi-currency support and breaking dozens of features, your AI assistant used your test repository to:

• Understand the current architecture deeply
• Identify every component that would break
• Recommend a safe, phased approach
• Generate code that preserves all existing behavior
• Create a complete test suite for the new functionality

Time saved: Weeks of debugging and multiple production incidents prevented.

Getting Started: Beta Program

The official Testmo MCP will shortly be released to a small number of beta testers. We're looking for development teams who want to write better code by learning from their existing tests.

Want in? Apply here: Testmo MCP Beta Signup

Ideal Beta Participants

You're a great fit if:

• You use MCP-compatible AI coding assistants in your development workflow
• Your team is actively developing new features, modifying existing features, or making other improvements to your platform
• You are looking for ways to make your AI coding more effective, higher quality, and less expensive
• Your team has a substantial codebase and corresponding test repository (~500+ test cases)

What You'll Get

• Free access to the Testmo MCP
• Priority support from our product and engineering teams
• Weekly sync calls during the beta period to share feedback and influence roadmap

What We Ask

Time Commitment:

• 1-2 hours per week actively using the MCP
• 30-minute kickoff call to understand your workflows
• Bi-weekly feedback sessions (optional but appreciated)
• Help us understand what works and what doesn't

Feedback Areas:

• How accurately AI finds relevant test cases
• How helpful test context is for code generation
• Performance and speed
• Quality of generated code that incorporates test knowledge
• Suggestions for new workflows and use cases

Beta Timeline

• Mid-June 2026: Initial Beta Launch
• July - September 2026: Expanded Beta
• Q4 2026: General Availability

How to Apply

To participate in the beta, please apply via the survey link below. Seats are limited and will be awarded on a first-come, first-serve basis to teams that best fit the selection criteria for the beta.

Complete our beta application survey: Testmo MCP Beta Signup

Selection Criteria

We're prioritizing teams with:

• ✅ Active use of MCP-compatible AI coding assistants
• ✅ Established test repositories (more data = better AI performance)
• ✅ Complex business logic that's well-tested
• ✅ Commitment to providing detailed feedback
• ✅ Willingness to have your feedback referenced in

Security and Privacy

How Your Data Is Used

We are committed to building AI features that are secure, ethical, and user-centric. When you use the Testmo MCP Server:

• Your input—along with any optional context you provide (such as domain terms or project-specific information) is securely transmitted via encrypted APIs to process your request.
• That input is used solely to generate relevant responses for your request. No data is selected or processed automatically. Only what you submit.
• Using the MCP Server is entirely optional, and you decide what data is shared.

Review our documentation below for more information:

• About Testmo AI
• How Data is Used in Testmo AI

Frequently Asked Questions

Q: How does this differ from just reading test cases manually?
A: Your AI assistant can analyze hundreds of test cases instantly and extract patterns you'd miss. It understands relationships between tests, identifies edge cases across different test areas, and can synthesize requirements from multiple sources. A human reading tests manually would take hours or days and would miss non-obvious connections.

Q: What AI coding assistants work with Testmo MCP?
A: Any AI assistant that supports the Model Context Protocol (MCP). Examples include Claude Code/Desktop and Codex. The MCP standard is open, so any tool that adds MCP support can connect to the official Testmo MCP.

Q: What if my test cases are poorly written or out of date?
A: The MCP works with your tests as they exist today. If tests are outdated, your AI will warn you ("This test was last updated 2 years ago - it may not reflect current behavior"). If tests are sparse, your AI will identify coverage gaps. The system actually helps you improve your test repository over time by highlighting where documentation is weak.

Q: Can my AI write code that breaks my tests?
A: Yes, if you explicitly ask it to. But your AI will warn you: "This change will likely break 5 existing test cases related to payment processing. Should I show you which tests will be affected before proceeding?" The goal is informed decision-making, not preventing all breaking changes.

Q: How accurate is the semantic search?
A: In our testing, semantic search correctly identifies relevant test cases 85-90% of the time. It's not perfect, but it's far better than keyword search alone. When you ask about "checkout problems," your AI finds tests about "order completion failures," "payment processing errors," and "cart validation issues" - terms that mean the same thing in your domain.

Q: What if I have test cases in multiple formats (BDD, manual steps, automated)?
A: The MCP handles all test case formats. Your AI understands Gherkin (Given/When/Then), traditional step-by-step test cases, acceptance criteria, and even test automation code references. It extracts the intent regardless of format.

Q: Can I use this with test cases from other tools (e.g. Jira)?
A: Currently, the MCP only works with Testmo. However, if you migrate test cases from other tools to Testmo, they become immediately available through the MCP.

Q: Does this work with automated tests (unit tests, integration tests)?
A: The current version focuses on test cases in your Testmo repository. We're exploring integration with code-based automated tests (reading test files directly) in a future release. For now, if your automated tests are documented as test cases in Testmo, they're fully supported.

Q: Does my AI assistant send my code to the Testmo MCP?
A: No. Your AI assistant sends natural language queries to the MCP ("find test cases about payment validation") and receives test case data back. Your source code never leaves your AI assistant unless you explicitly share code in your prompts. The MCP only accesses your Testmo test repository.