MCP Workflows
Practical AI agent workflow patterns using DebugBundle MCP tools.
This page walks through common workflow patterns that AI agents follow when using DebugBundle MCP tools. These patterns work with any MCP-compatible agent — GitHub Copilot, Cursor, Cline, or custom agents.
Triage Workflow
The most common workflow: an agent investigates a failing test or user-reported error.
1. list_incidents → Find matching incidents
2. get_incident → Read incident details and severity
3. get_bundle → Retrieve the full debug bundle
4. get_reproduction → Get reproduction commands
5. get_logs → Review raw log context
6. analyze → Run deep analysis for root causeExample conversation:
User: "The auth service started throwing 500 errors after yesterday's deploy."
The agent calls
list_incidentsfiltered byservice: "auth"andseverity: "high". It finds the relevant incident and callsget_bundleto retrieve the stack trace, request context, and environment details. Then callsget_reproductionto get a cURL command that reproduces the error. Finally,analyzeproduces a root cause hypothesis pointing to a missing environment variable.
Product Analytics Review
Use this workflow when a user asks how many people use a product, where a journey breaks down, which routes or devices are affected, or whether an observed incident changed product behavior.
1. get_usage_summary → Establish visits, active users, and trend context
2. get_route_metrics / get_action_metrics → Identify where users go and what they do
3. get_funnel_analysis → Measure conversion and step-level drop-off
4. get_journey_patterns → Compare common navigation paths and friction signals
5. list_analytics_journey_samples → Inspect bounded redacted sequences only when aggregates need evidence
6. list_analytics_opportunities → Review deterministic product-improvement signals
7. generate_analytics_bundle → Preserve one bounded analysis question when a durable artifact is usefulStart with direct aggregate reads. They answer most usage questions without creating another retained artifact. Journey samples are structured, redacted event sequences, not video replay. Generated analytics bundles are for durable, bounded analysis, not one bundle per visit.
Read get_analytics_settings and list_saved_analytics_funnels before changing
configuration. Calls to update_analytics_settings, create_saved_analytics_funnel,
update_saved_analytics_funnel, archive_saved_analytics_funnel, and
generate_analytics_bundle are mutations: explain the effect and proceed only when
the user explicitly asks. Analytics reads and management require member authentication;
project tokens remain write-only ingestion credentials.
Example conversation:
User: "Where do mobile visitors abandon signup, and did last week's checkout incident affect conversion?"
The agent calls
get_usage_summaryandget_device_breakdown, narrows the result withget_funnel_analysis, and callsget_incident_impactfor the incident window. It inspects a small set of journey samples only if the aggregate drop-off needs supporting evidence. It generates an analytics bundle only if the user wants the bounded review retained and shared.
Setup Verification
When starting work on a project, verify that DebugBundle is configured correctly.
1. doctor → Full connectivity check
2. verify_local → Confirm local mode works
3. verify_cloud → Confirm cloud mode works (if connected)
4. verify_cloud → Confirm hosted incident creation with trigger5xx or trigger4xxStatus
5. smoke → End-to-end test eventThis pattern is useful as a first step when a user says "set up DebugBundle" or when debugging connectivity issues.
Use trigger5xx: true to prove the standard request-failure path, or trigger4xxStatus: 403 to prove a configured client-error status promoted by the project's capture policy.
Token Rotation
Rotate tokens for security or after a team member leaves.
1. list_project_tokens → See existing tokens
2. create_project_token → Create new token with descriptive label and optional `allowedOrigins` for static-browser direct ingestion
3. revoke_project_token → Revoke the old tokenFor member tokens, the pattern is identical using list_member_tokens,
create_member_token, and revoke_member_token.
Important: Update SDK configuration and CI/CD secrets with the new token before revoking the old one to avoid ingestion downtime.
Webhook Setup
Configure webhooks for an external notification system.
1. create_webhook → Create endpoint with URL, events, and signing secret
2. test_webhook → Verify delivery reaches the endpoint
3. list_webhook_deliveries → Confirm successful deliveryIf the test delivery fails:
4. list_webhook_deliveries → Check delivery status and response code
5. update_webhook → Fix the URL or configuration
6. test_webhook → Re-testAlert Configuration
Set up alert rules for a newly deployed service.
1. create_alert → Slack alert for new_incident, severity >= high
2. create_alert → Email alert for incident_regressed
3. create_alert → Webhook alert for error_spike (to PagerDuty)Availability Check Investigation
Use this when a user reports downtime, endpoint reachability issues, or wants hosted health checks configured for a public service.
1. list_health_checks → Review saved checks and plan limits
2. list_health_check_results → Inspect recent raw executions
3. list_health_check_daily_rollups → Check retained daily status history
4. test_health_check → Verify a target without creating incidents or history
5. list_incidents / get_bundle → Inspect the linked availability incident when failures crossed the thresholdCreate or update saved checks only when the user explicitly wants monitoring
configuration changed. Prefer test_health_check first, avoid private/internal
targets, and remember that checks are hosted DebugBundle requests rather than SDK
events from the customer's app.
Incident Resolution
After fixing a bug, close out the incident chain.
1. get_incident → Confirm fix addresses root cause
2. resolve_incidents → Mark selected incidents as resolved
3. list_incidents → Verify no related active incidents remainIf the incident regresses later:
1. get_incident → Review the reopened incident
2. get_bundle → Compare new bundle with the previous one
3. analyze → Check if same root cause or new issueWeekly Report Review
Pull weekly reports for a project standup or retrospective.
1. list_weekly_reports → See available reports
2. get_weekly_report → Read the latest analysisTo enable reports for a new project:
1. configure_weekly_reports → Enable and set recipients
2. generate_weekly_report → Generate the first report immediatelyProbe-Driven Investigation
When an incident lacks sufficient diagnostic data, activate a probe to collect more.
1. get_incident → Review what data is available
2. get_bundle → Check if bundle has enough context
3. activate_probe → Activate probe for the matching label pattern
4. list_active_probes → Confirm the probe is active
5. get_bundle → Pull updated bundle with probe-enriched data
6. analyze → Re-run analysis with richer data
7. deactivate_probe → Clean up when doneProject Management
Create and configure projects directly from the agent conversation.
1. list_projects → See existing projects
2. create_project → Create a new project with name and slug
3. get_capture_policy → Check the default capture policy
4. update_capture_policy → Tune capture settings for the workloadMember Management
Manage project access and invitations without leaving the agent session.
1. list_project_members → See current project collaborators
2. invite_project_member → Invite a collaborator by email and role
3. list_project_member_invites → Track pending project invitations
4. cancel_project_member_invite → Revoke an invitation if needed
5. update_project_member_role → Change a collaborator's role
6. remove_project_member → Remove a collaborator from the projectBilling Management
Check billing state, start an eligible no-card trial, and manage project capacity.
1. get_billing_summary → View plan, billing state, trial state, and capacity usage
2. start_trial → Start a Solo or Team no-card trial when eligible
3. increase_capacity → Add capacity when the team needs more allowance
4. schedule_capacity_reduction → Schedule a reduction for the next billing cycle
5. cancel_capacity_reduction → Cancel a pending reductionActive no-card trials can use get_billing_summary and start_trial, but
capacity tools return trial_conversion_required until the organization
converts to a paid plan.
Combining Patterns
Real agent sessions often chain multiple patterns. For example, after triaging an incident and finding insufficient data:
Triage → Probe-Driven Investigation → Analysis → ResolutionOr when onboarding a new project:
Setup Verification → Token Rotation → Product Analytics Review → Webhook Setup → Alert Configuration → Availability Check InvestigationThe MCP server is stateless: each tool call is independent. Agents can interleave tools from different patterns freely.
Next Steps
- MCP Tools Reference — Complete tool catalog
- AnalyticsBundle — Product analytics model, privacy, retention, and evidence lifecycle
- Availability Checks — Hosted health-check behavior and limits
- MCP Server — Authentication and configuration
- CLI Cloud Workflow — CLI operations that complement MCP