tda MCP — 사용 사례, 설치 & 라이브 데모

왜 쓰나요

핵심 기능

Runs from a single JAR, fully offline
Parses multi-dump log files and summarizes across dumps
Deadlock detection + long-running thread tracking
Virtual-thread (Project Loom) pinning analysis

라이브 데모

실제 사용 모습

tda.replay ▶ 준비됨

0/0

설치

클라이언트 선택

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "tda": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config 열기. 저장 후 앱 재시작.

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "tda": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ],
      "_inferred": true
    }
  }
}

Cursor는 Claude Desktop과 동일한 mcpServers 스키마 사용. 프로젝트 설정이 전역보다 우선.

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "tda": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ],
      "_inferred": true
    }
  }
}

Cline 사이드바의 MCP Servers 아이콘 클릭 후 "Edit Configuration" 선택.

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "tda": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop과 같은 형식. Windsurf 재시작 후 적용.

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "tda",
      "command": "TODO",
      "args": [
        "See README: https://github.com/irockel/tda"
      ]
    }
  ]
}

Continue는 맵이 아닌 서버 오브젝트 배열 사용.

~/.config/zed/settings.json

{
  "context_servers": {
    "tda": {
      "command": {
        "path": "TODO",
        "args": [
          "See README: https://github.com/irockel/tda"
        ]
      }
    }
  }
}

context_servers에 추가. 저장 시 Zed가 핫 리로드.

claude mcp add tda -- TODO 'See README: https://github.com/irockel/tda'

한 줄 명령. claude mcp list로 확인, claude mcp remove로 제거.

사용 사례

실전 활용법: tda

Diagnose a JVM hang from thread dumps with TDA

👤 Java backend engineers ⏱ ~20 min advanced

언제 쓸까: Production JVM went unresponsive; you have a series of kill -3 dumps.

사전 조건

tda.jar downloaded — github.com/irockel/tda releases
Java 21+ installed — For Project Loom analysis features

흐름

Parse the log

parse_log on /tmp/threaddumps.log. Summarize: how many dumps, threads per dump.✓ 복사됨

→ Dump overview
Check for deadlocks

check_deadlocks across all dumps. Which threads, which locks?✓ 복사됨

→ Deadlock cycles if any
Find long-running threads

find_long_running threads persisting across all dumps. What are they doing?✓ 복사됨

→ List with stack heads

결과: A specific thread + lock + code path responsible for the hang.

함정

Scripts printing to stdout corrupt the JSON-RPC stream — Use java -Djava.awt.headless=true -jar tda.jar --mcp without wrapping in any script that also prints

Hunt virtual-thread carrier pinning in a Loom app

👤 Teams adopting Project Loom ⏱ ~30 min advanced

언제 쓸까: Virtual threads aren't giving the concurrency you expected — suspect pinning.

흐름

Capture dumps during load

Collect thread dumps at peak load; parse_log them in TDA.✓ 복사됨

→ Dumps loaded
Analyze

analyze_virtual_threads. Show carrier pinning hotspots and the Java code pinning them (typically synchronized blocks or native methods).✓ 복사됨

→ Pinning list with source hints

결과: Targeted fixes (ReentrantLock instead of synchronized, etc.) backed by evidence.

Identify threads stuck in native methods

👤 Performance engineers on JNI-heavy apps ⏱ ~15 min advanced

언제 쓸까: Your app integrates with native libs and you suspect blocking native calls.

흐름

List native-blocked threads

get_native_threads for dump #3. Which native methods are they stuck in?✓ 복사됨

→ Thread + native frame list

결과: Targeted review of specific JNI call sites.

조합

다른 MCP와 조합해 10배 효율

tda + prometheus

Correlate thread-level findings with JVM metrics

TDA says lock X is contended — show JVM thread_blocked_seconds for the same window from Prometheus.✓ 복사됨

tda + github

Turn findings into issues with code pointers

For the top 3 TDA findings, open a GitHub issue linking the suspect Java source lines.✓ 복사됨

도구

이 MCP가 노출하는 것

도구	입력	언제 호출	비용
parse_log	path: str	First step, always	local CPU
get_summary		Overview before digging	0
check_deadlocks		Hang diagnosis	0
find_long_running	min_dumps?: int	Persistent threads	0
analyze_virtual_threads		Loom diagnostics	0
get_native_threads	dump_index?: int	JNI suspicion	0
get_zombie_threads		Unresolved memory relocations	0
clear		Reset before parsing a new log	0

비용 및 제한

운영 비용

API 쿼터: None
호출당 토큰: Thread dumps are huge — 20k+ tokens per full dump. Summarize before dumping to chat
금액: Free
팁: Use get_summary/find_long_running narrowing before asking for full stacks

보안

권한, 시크릿, 파급범위

자격 증명 저장: None

데이터 외부 송신: None — entirely local file parsing

문제 해결

자주 발생하는 오류와 해결

MCP handshake corrupts

Run JAR exactly per README (headless + --mcp, no wrapper scripts printing to stdout)

parse_log fails on custom dump formats

Ensure dumps are standard HotSpot format; some APMs add prefixes TDA can't parse

Memory blows up on huge logs

Increase JVM heap for tda.jar: -Xmx4g or split the log into chunks

대안

tda 다른 것과 비교

대안	언제 쓰나	단점/장점
FastThread / other online analyzers	You're okay uploading dumps to a third party	Data leaves your network
async-profiler + flame graphs	You have live control and want sampling profiler not dumps	Different artifact; needs agent attach

tda