Kiro MCP: Turn Bug Evidence Into a Fix Spec

Kiro MCP gives a Kiro workspace access to configured MCP servers. That lets an agent retrieve report evidence while working with workspace files and specs. Kiro MCP configuration documentation documents mcpServers, remote URLs, OAuth, autoApprove, and disabledTools.

The useful boundary is between evidence and implementation:

• clip.qa supplies a captured report, human-reviewed diagnosis context, and available artifacts.
• Kiro MCP retrieves selected report data through approved tools.
• A Kiro bugfix spec records observable requirements and acceptance criteria.
• Kiro uses that spec to propose tasks and code changes.
• You validate the result in the environment that produced the report.

For broader agentic QA guidance, see LLM-ready bug reports. To prepare a concise evidence handoff, use how to describe a bug to AI.

Kiro supports workspace-scoped and user-scoped MCP configuration. Workspace settings live in .kiro/settings/mcp.json; user settings live in ~/.kiro/settings/mcp.json. A remote server entry can use a url, OAuth support, an autoApprove list, and a disabledTools list. Kiro’s MCP documentation confirms these locations and options.

Use this minimal workspace configuration:

{
  "mcpServers": {
    "clip-qa": {
      "url": "https://mcp.clip.qa/mcp",
      "disabled": false,
      "autoApprove": []
    }
  }
}

Then follow these steps:

1. Place the configuration in the relevant workspace .kiro/settings/mcp.json, or use the user-level file if the connection should apply across workspaces.
2. Restart or reload Kiro if its current session does not discover the new server.
3. Complete authentication when Kiro prompts for OAuth. The clip.qa remote endpoint uses OAuth 2.1 PKCE.
4. Confirm that the clip-qa server is enabled and its tools are discovered.
5. Verify listReports, then call getDetails for one known report.
6. Leave autoApprove empty while validating access. Configure individual write tools separately only when the task needs them.
7. Restrict disabledTools only after confirming which operations the workflow should not perform.

This is a documentation-based setup, not an end-to-end integration test. Kiro MCP configuration applies to the documented IDE and workspace surfaces; do not assume the same file or behavior exists on every Kiro surface.

The remote clip.qa MCP server exposes listReports, getDetails, getNetworkRequests, getConsoleLogs, getScreenshots, getVideoTranscript, getReportDiff, createComment, linkFix, and linkFixAttempt. Do not substitute local-server tool names.

A read-only spec workflow can begin with a compact tool sequence:

1. Call listReports to identify the report without opening unrelated records.
2. Call getDetails for the selected report.
3. Use getVideoTranscript to locate the action sequence.
4. Use getScreenshots to compare visible states.
5. Use getNetworkRequests and getConsoleLogs for a supported browser capture.
6. Use getReportDiff if a later report documents a changed symptom.

createComment, linkFix, and linkFixAttempt mutate workflow records. Keep them out of automatic approval until you understand their effect. Reports remain private until explicitly shared, and authenticated access does not automatically make every report available.

Kiro specs can use requirements.md or bugfix.md, followed by design.md and tasks.md. A bugfix spec should state current behavior, expected behavior, and unchanged behavior. Kiro specs documentation confirms this structure and purpose.

Translate evidence into observable requirements. Avoid “fix the keyboard” because it does not define success. Use language that a tester can verify.

For a hypothetical Android keyboard issue, the report shows a form field near the bottom of the screen. When the on-screen keyboard opens, the field is covered and the submit button cannot be reached. The desktop layout remains correct, and the report does not establish whether the failure is specific to one device or all Android versions.

A concise bugfix.md could read:

# Bugfix: Reach submit action while Android keyboard is open

## Current behavior
When the address form is focused near the bottom of the viewport, opening the
on-screen keyboard can obscure the field and submit action. The user cannot
complete the form through the recorded path.

## Expected behavior
When the Android keyboard is open, the focused field and submit action remain
reachable. The form can be completed without dismissing the keyboard.

## Unchanged behavior
The desktop form layout, field labels, validation rules, request payload, and
successful-submission behavior remain unchanged.

## Evidence constraints
The captured report provides evidence from an Android environment. A browser or
desktop reproduction does not establish native Android behavior.

## Acceptance criteria
- Given the keyboard is open and focus reaches the bottom form field, the field
  and submit action remain operable.
- Existing validation still blocks an invalid address.
- A valid address still submits the same payload.
- Desktop layout shows no regression.

This format follows the structure in how to write bug reports with an AI template: trigger, current result, expected result, constraints, and checks.

design.md should explain the intended behavior change without inventing implementation details that the evidence cannot support. tasks.md should turn acceptance criteria into small, reviewable steps.

For the keyboard example, a useful task sequence is:

1. Reproduce the field focus and keyboard-open state in the relevant Android build and device configuration.
2. Identify whether the obstruction comes from window sizing, layout measurement, scrolling, or another mechanism.
3. Implement the smallest change that keeps the field and submit action reachable.
4. Add a regression check for the affected form path.
5. Confirm validation, payload, desktop layout, and successful submission remain unchanged.
6. Retest the original captured scenario and record the result.

Avoid task language such as “support every Android keyboard.” The report may support one observed device or viewport state. Record the exact test conditions first. If no native test is available, state that the fix remains unverified on Android rather than implying success from a desktop or browser run.

Validation must answer the acceptance criteria, not merely confirm that code compiles. Start with the evidence dimensions available in the report.

For browser reports, compare the original browser environment and supported console or network artifacts. For native mobile reports, acknowledge telemetry limits: iOS telemetry is limited while another app is foregrounded. Do not imply that browser-style console and network inspection applies to arbitrary native mobile apps.

Use this review checklist:

• The implementation matches the expected behavior stated in bugfix.md.
• The unchanged behavior in the spec still passes.
• The regression check fails against the old behavior or clearly exercises the reported path.
• The fix is retested in the original environment.
• Any linked fix attempt records pending, succeeded, or failed based on that evidence.
• A commit or pull request is linked, but it is not treated as proof by itself.

clip.qa produces a draft report through cloud video analysis, followed by human review. It does not guarantee accuracy or autonomously fix code. Kiro’s spec improves traceability; your validation determines whether the behavior changed.

Use the least privilege that lets the agent complete the task. Start with an empty autoApprove list, enable the server, and approve read operations after reviewing their targets. Configure write operations separately. Do not put secrets in a spec, prompt, or tracked workspace settings file.

For shared debugging, decide what each person can see before sharing evidence. A report remains private until explicitly shared. A team member with MCP access may still need the report owner to share the specific record.

Avoid granting write tools merely because a future task might need them. A createComment call changes collaboration state. linkFix associates code with a report. linkFixAttempt records validation history and requires a commit or pull request with an outcome. Those actions should follow a deliberate review point.

If mobile evidence is needed without adding an SDK to the app under test, review mobile bug reporting without SDK and the clip.qa apps capture options. All capture clients are in beta or require request access, and no SDK is installed into the app being tested.

Sign up free to capture evidence for an AI-assisted debugging workflow.

• Kiro MCP configuration — Confirms mcpServers, remote URL configuration, workspace and user settings paths, OAuth support, autoApprove, and disabledTools. Checked 2026-11-05.
• Kiro specs — Confirms requirements.md or bugfix.md, design.md, tasks.md, and current, expected, and unchanged behavior framing. Checked 2026-11-05.
• clip.qa MCP — Product reference for the remote MCP setup and report workflow. Checked 2026-11-05.