[CSR-3102] feat: new tools

[waltergalvao]

Summary

• Add new tools to our MCP server, and bumps it to v2.0.0
• Removes get-api-config tool
• Organizes the codebase splitting tools to their own files
• Support for paginated API requests
• Removed response types that are not required for simplicity sake

Tools

Tool	Description
currents-get-projects	Retrieves a list of all projects available.
currents-get-run-details	Retrieves details of a specific test run.
currents-get-spec-instances	Retrieves debugging data a specific execution of a test spec file.
currents-get-spec-files-performance	Retrieves spec file historical performance metrics for a specific project.
currents-get-tests-performance	Retrieves test historical performance metrics for a specific project.
currents-get-tests-signatures	Retrieves a test signature by its spec file name and test name.
currents-get-test-results	Retrieves debugging data from test results of a test by its signature.

Use cases

The new tools should support use cases such as:

• "Please fix this test?" (Agent should retrieve last execution data just by knowing the test name and spec filename)
• "What were the top flaky tests in the last 30 days?" (Agent should retrieve test metrics from all projects in the date range)
• "What were the slowest specs in the last 7 days?" (Agent should retrieve spec metrics from all projects in the date range)
• "Please fix all my flaky tests" (Agent should investigate which tests are flaky, create a plan and execute it)

Demo

Make a plan to fix all my flaky tests

Plan to fix flaky tests

Exported on 9/15/2025 at 22:47:40 GMT-3 from Cursor (1.5.11)

---

User

Make a plan to fix all my flaky tests

---

Cursor

I'll help you create a plan to fix all your flaky tests. First, let me understand your current setup and identify the flaky tests using the Currents MCP tools.

Now let me get the flaky tests from both projects to understand the scope of the problem:

Now let me get more details about the most flaky tests to understand their patterns:

Now let me get more details about the spec files performance to understand the broader patterns:

Based on my analysis of your test data, I've identified significant flaky test issues across your projects. Here's a comprehensive plan to fix all your flaky tests:

Flaky Test Analysis Summary

Critical Issues Found:

1. web-app/reports.spec.ts - 59.4% flake rate (107 flaky executions out of 180)
2. web-app/payments.spec.ts - 22.7% flake rate (41 flaky executions out of 181)
3. web-app/onboarding.spec.ts - 19.3% flake rate (35 flaky executions out of 181)

Root Cause Analysis:

From the test results, I can see a consistent pattern:

• Timing Issues: Tests failing with expect(received).toBeTruthy() receiving false
• Race Conditions: Multiple attempts needed before tests pass
• Location: All failures occur at line 190:43 in web-app/reports.spec.ts
• Pattern: Tests fail on first 1-2 attempts, then pass on retry

Prioritized Action Plan

Phase 1: Critical Fixes (Week 1)

Priority: HIGH - 59.4% flake rate

1.1 Fix web-app/reports.spec.ts (Most Critical)

• Issue: Line 190:43 consistently failing with expect(received).toBeTruthy()
• Root Cause: Likely async operation not properly awaited
• Actions:
  • Add explicit waits for async operations
  • Implement proper element visibility checks
  • Add retry logic for flaky assertions
  • Use waitFor instead of immediate assertions

1.2 Fix web-app/payments.spec.ts (High Priority)

• Issue: 22.7% flake rate across payment-related tests
• Root Cause: Payment processing timing issues
• Actions:
  • Add proper waits for payment API responses
  • Implement mock delays for payment processing
  • Add explicit waits for UI state changes

Phase 2: Medium Priority Fixes (Week 2)

Priority: MEDIUM - 19.3% flake rate

2.1 Fix web-app/onboarding.spec.ts

• Issue: Onboarding flow timing issues
• Root Cause: Multi-step process race conditions
• Actions:
  • Add explicit waits between onboarding steps
  • Implement proper state validation
  • Add retry mechanisms for critical steps

Phase 3: Infrastructure Improvements (Week 3)

Priority: MEDIUM - Prevent future flakiness

3.1 Implement Test Stability Framework

• Add global retry configuration
• Implement proper wait strategies
• Add test isolation improvements
• Create flaky test detection alerts

3.2 Add Test Monitoring

• Set up flaky test tracking
• Implement test performance monitoring
• Add automated flaky test reporting

Specific Technical Recommendations

For web-app/reports.spec.ts (Line 190:43)

// Instead of:
expect(someElement).toBeTruthy();

// Use:
await expect(someElement).toBeVisible({ timeout: 10000 });
// or
await page.waitForSelector('selector', { state: 'visible', timeout: 10000 });

For Payment Tests

// Add explicit waits for payment processing
await page.waitForResponse(response => 
  response.url().includes('/payment') && response.status() === 200
);

For Onboarding Tests

// Add step-by-step validation
await expect(page.locator('[data-testid="step-1"]')).toBeVisible();
await page.click('[data-testid="next-button"]');
await expect(page.locator('[data-testid="step-2"]')).toBeVisible();

Implementation Timeline

Week	Focus	Expected Outcome
1	Fix reports.spec.ts	Reduce flake rate from 59.4% to <5%
2	Fix payments.spec.ts	Reduce flake rate from 22.7% to <5%
3	Fix onboarding.spec.ts	Reduce flake rate from 19.3% to <5%
4	Infrastructure improvements	Prevent future flakiness

Success Metrics

• Target: Reduce overall flake rate from current ~30% to <5%
• Monitoring: Track flaky test count weekly
• Alerting: Set up alerts for tests with >10% flake rate

Next Steps

1. Immediate: Start with web-app/reports.spec.ts line 190:43
2. This Week: Implement proper async/await patterns
3. Next Week: Add comprehensive wait strategies
4. Ongoing: Monitor and prevent regression

Would you like me to help you implement any of these specific fixes, or would you prefer to start with a particular test file?

// Instead of:
expect(someElement).toBeTruthy();

// Use:
await expect(someElement).toBeVisible({ timeout: 10000 });
// or
await page.waitForSelector('selector', { state: 'visible', timeout: 10000 });

// Add explicit waits for payment processing
await page.waitForResponse(response => 
  response.url().includes('/payment') && response.status() === 200
);

// Add step-by-step validation
await expect(page.locator('[data-testid="step-1"]')).toBeVisible();
await page.click('[data-testid="next-button"]');
await expect(page.locator('[data-testid="step-2"]')).toBeVisible();

[notion-workspace]

Improve MCP Server

[waltergalvao]

To avoid comitting API Key by accident, gitignoring .cursor

[waltergalvao]

Seems we cannot use stdout as MCP uses that: https://modelcontextprotocol.io/legacy/tools/debugging#server-side-logging

[waltergalvao]

https://docs.currents.dev/resources/api/api-resources/projects

[waltergalvao]

https://docs.currents.dev/resources/api/api-resources/runs

[waltergalvao]

https://docs.currents.dev/resources/api/api-resources/spec-files

[waltergalvao]

https://docs.currents.dev/resources/api/api-resources/instances

[waltergalvao]

https://docs.currents.dev/resources/api/api-resources/test-results

[waltergalvao]

https://docs.currents.dev/resources/api/api-resources/tests

[waltergalvao]

This actually uses the https://docs.currents.dev/resources/api/api-resources/tests API, leveraging the spec and title filters.

[waltergalvao]

Not typing responses anymore - the types will be incorrect if we change the API response, and we don't really need it as we just feed the response directly to the agent. The types does not help the agent.