One‑Click Bug Fixes: AI‑Powered Log Diagnosis Skill with MCP

Problem Overview

Backend developers spend most of debugging time switching between a log platform and an IDE to locate bugs. The workflow consists of querying logs by traceId or keywords, filtering relevant entries, copying class/method names, searching code, and combining with business logic to pinpoint the root cause. This process is repetitive and time‑consuming.

Model Context Protocol (MCP)

MCP is a standardized tool‑calling protocol that enables Claude Code to invoke log‑query services over a Server‑Sent Events (SSE) long‑connection. The protocol returns real‑time log data without manual queries. Authentication uses a secretKey to acquire an accessToken (valid 1 hour, up to 5 concurrent tokens); the token is refreshed automatically.

/log‑diagnosis Skill

The Skill lives in .claude/skills/log-diagnosis/ (or .cursor/skills/) and is triggered by the command /log-diagnosis {env} {branch} {description}. Execution chain:

user input → load SKILL.md → read .diagnosis/config.json → refresh accessToken if needed → derive time window from traceId → paginated MCP log fetch (max 20 pages) → checkout specified code branch → search code with log keywords → combine upstream, current‑service logs and code logic → generate diagnosis report → restore original branch

Entry methods

Provide a traceId to locate a specific request.

Provide an alarm description; the AI infers the traceId.

Installation & Configuration

Add MCP endpoints in Claude Code:

claude mcp add --transport sse dw-log-mcp-t1 https://{your-t1-aigw-domain}/api/v1/mcp/log-mcp/sse

Create .diagnosis/config.json with the secretKey obtained from the log‑platform backend. The Skill automatically populates accessToken, accessTokenExpireAt and fields.

Usage

Example command:

/log-diagnosis T1 feature/your-branch trace_id: "your-trace" why no data returned

The AI handles token refresh, pagination, DTO extraction and produces a root‑cause analysis within minutes.

Practical case – hidden SQL bug

Scenario: a search API in the test environment returns no data. The developer runs the Skill with the traceId.

Time window derived from traceId (2026‑02‑27 whole day).

Expired token refreshed automatically.

73 log entries fetched across two pages.

The AI reconstructed the request DTO, extracted the actual SQL, and identified that the customer_tag condition lacked an empty‑string check, causing all rows to be filtered.

Original MyBatis mapper fragment:

<!-- problem code -->
<if test="customerTag != null">
    and (a.customer_tag IS NULL OR a.customer_tag = #{customerTag})
</if>

Suggested fix:

<!-- fixed code -->
<if test="customerTag != null">
    and (a.customer_tag IS NULL OR a.customer_tag = '' OR a.customer_tag = #{customerTag})
</if>

AI highlighted that other fields handle both NULL and empty‑string cases, while customer_tag does not, revealing the bug that manual inspection would likely miss.

Efficiency tips

Prefer traceId‑based retrieval for precise request tracing.

Focus on key log nodes such as toSearchDTO finished, resultList is empty, etc.

SQL logs from ORM frameworks are critical clues.

Enforce full pagination (up to 20 pages) to avoid missing logs.

Conclusion

Combining MCP (dynamic data access) with a Skill (reproducible SOP) creates a closed‑loop AI capability that automates repetitive debugging tasks. The same pattern can be extended to code review, performance reporting and alert inspection, turning engineering experience into reusable AI‑driven processes.