Skip to main content

BitDive MCP Integration

BitDive MCP gives AI agents access to real runtime evidence from your Java application.

Instead of guessing from source code alone, the agent can inspect real execution traces: SQL queries, HTTP payloads, call chains, method return values, timing, and failures captured from real requests. This is what turns an AI assistant into a tool that can debug, verify, and explain changes against production reality.

What BitDive MCP Is For​

Use BitDive MCP when you need an agent to:

  • discover which service or method is actually hot or failing
  • inspect the exact trace behind a bug or performance regression
  • reproduce a real request locally from captured data
  • compare before and after traces after a code change
  • refresh trace-based JUnit suites after an intended behavior change

The core value is simple: the agent reasons over runtime facts, not assumptions.

What BitDive MCP Is Not​

BitDive MCP is not:

  • direct database access for the agent
  • synthetic test generation
  • a replacement for mvn test
  • a way to capture a new trace by replaying an existing JUnit test

This distinction matters:

  • Replay tests verify code against a recorded baseline.
  • New traces appear only when a real request hits a service with the BitDive agent attached.

If you changed code and need true before and after verification, trigger the same real request again and compare the two traces.

Typical Setup​

BitDive setup for MCP-enabled tools usually looks like this:

  1. Open the MCP configuration card in BitDive and copy the server settings.
  2. Add that server configuration to Cursor, Claude Desktop, Windsurf, or another MCP-capable client.
  3. Copy the BitDive user rule or token configuration from BitDive and add it to the tool's rules or system prompt area.
  4. Confirm the connection with a simple request such as listing recent calls for a target service.

Once configured, the AI tool can call BitDive tools directly without switching context to the dashboard for every step.

The most effective use of BitDive MCP follows a repeatable loop.

1. Discover the Target​

Start broad. Find the right module, service, and hot path before looking at code.

Typical tools:

  • get_heatmap_all_system
  • get_heatmap_for_module
  • get_heatmap_for_service

Use this stage to answer:

  • Which service is failing or slow?
  • Which methods are active right now?
  • Where should the agent focus first?

2. Locate the Right Trace​

Once the target service is known, fetch a concrete call_id.

Typical tools:

  • get_last_calls
  • find_trace_between_time

This is the handoff from system-level observation to a specific execution that can be analyzed, reproduced, or compared later.

3. Analyze Before Touching Code​

Use the trace itself as the behavioral baseline.

Typical tools:

  • find_trace_summary
  • find_trace_for_method

The goal is to understand:

  • the real execution tree
  • SQL counts and query shapes
  • downstream HTTP or Kafka interactions
  • exact failure points and inputs

If needed, generate an exact request for local reproduction:

  • get_reproduction_command

4. Make the Code Change​

The agent or developer makes a focused change using the runtime evidence as scope. This is where BitDive helps prevent broad speculative refactors.

5. Verify the Change Against Reality​

After the change, trigger the same endpoint or business flow again so BitDive captures a new trace.

Then compare:

  • compare_traces
  • compare_trace_evolution

This is the strongest proof that the fix did what you intended and nothing more.

6. Keep the Regression Suite Aligned​

Once the new behavior is confirmed as correct, refresh the replay-based test baseline.

Typical tools:

  • auto_generate_tests_for_service
  • update_existing_test_group
  • update_failed_tests_in_group
  • replace_test_with_latest_trace

This closes the loop between runtime evidence and deterministic regression protection.

Example Prompts for AI Tools​

These prompt patterns work well with BitDive MCP-enabled agents:

Diagnose a production bug​

Use BitDive MCP to inspect the latest failing trace for billing-service. Summarize the execution path, the error location, and the SQL and downstream calls involved.

Fix and verify a performance issue​

Use BitDive MCP to analyze the trace for GET /orders/{id}. If there is an N+1 query pattern, suggest a focused fix. After the change, compare before and after traces and report the SQL delta.

Reproduce a real request locally​

Find the latest successful call for customer-service, generate the reproduction command, and explain which headers and payload fields matter for replaying the same scenario locally.

Refresh the expected baseline​

Inspect the failing methods in this BitDive test group. Update only the methods that now reflect the intended new behavior, and leave unrelated regressions untouched.

Security Model​

BitDive MCP is designed to expose runtime context without giving the model unrestricted infrastructure access.

  • authentication is handled server-side by BitDive
  • tool usage can be audited
  • the agent reads runtime evidence through approved BitDive operations
  • there is no direct raw database shell access through MCP

For deployment and security architecture details, see System Architecture and Secure Data Processing.

Where To Go Next​

BitDive MCP is most effective when paired with standard regression discipline. The model uses runtime data to decide and verify. Your test suite still remains the global safety net.

Last updated on by turmyshevd