rf-log-mcp

Robot Framework 결과 파일을 검사하기 위한 MCP 서버로, LLM에게 간결한 증거 뷰를 제공합니다.

기능 개요

지원 입력:

• output.xml: Robot / Rebot 6.0.x / 6.1+ / 7.x

• output.json: Robot / Rebot 7.2+

제공되는 MCP 기능:

• Tools

  • parse_result

  • get_view

  • search_messages

• Resources

  • rf://runs/{run_id}/summary

  • rf://runs/{run_id}/tests/{test_id}

지원되는 뷰:

• summary

• failure_path

• step_window

주요 참고 사항

• 이 프로젝트는 MCP stdio server입니다.

• LLM은 wheel을 직접 호출하지 않습니다.

• 올바른 사용법: MCP 호스트가 rf-log-mcp 프로세스를 시작하고, stdio를 통해 도구와 리소스를 호출합니다.

식별자 설계

• 외부 run_id: 정수 기본 키

• 내부 content_hash: 파일 내용 해시, 서비스 내부 중복 제거용으로만 사용

권장 절차:

1. 먼저 parse_result(path)를 호출합니다.

2. 반환된 정수 run_id를 저장합니다.

3. 이후에는 이 run_id를 일관되게 사용합니다.

빠른 시작

1. 의존성 설치

uv sync

2. 소스 코드에서 직접 실행

uv run python -m rf_log_mcp

3. MCP 설정 예시

{
  "mcpServers": {
    "rf-log-mcp": {
      "command": "uv",
      "args": ["run", "python", "-m", "rf_log_mcp"]
    }
  }
}

패키징 및 설치

빌드

uv build

빌드 후 생성물:

• dist/rf_log_mcp-0.1.0-py3-none-any.whl

• dist/rf_log_mcp-0.1.0.tar.gz

wheel 설치

uv pip install dist/rf_log_mcp-0.1.0-py3-none-any.whl

설치 후 바로 실행 가능:

rf-log-mcp

설치된 패키지의 MCP 설정 예시

{
  "mcpServers": {
    "rf-log-mcp": {
      "command": "rf-log-mcp",
      "args": []
    }
  }
}

Windows 명시적 경로 예시

{
  "mcpServers": {
    "rf-log-mcp": {
      "command": "D:\\project\\rf_log_mcp\\.venv\\Scripts\\rf-log-mcp.exe",
      "args": []
    }
  }
}

일반적인 호출 흐름

1단계: 결과 파일 파싱

parse_result(path="tests/fixtures/single_failure_611.xml")

일반적인 반환값:

{
  "ok": true,
  "run_id": 1,
  "source_format": "xml"
}

2단계: 요약 가져오기

get_view(run_id=1, view="summary")

3단계: 실패 경로 가져오기 또는 메시지 검색

get_view(run_id=1, view="failure_path")
search_messages(run_id=1, query="timeout")

환경 변수

RF_LOG_MCP_DB

기본 SQLite 데이터베이스 경로를 덮어쓰는 데 사용됩니다.

PowerShell 예시:

$env:RF_LOG_MCP_DB="D:\data\rf-log-mcp\store.sqlite3"
rf-log-mcp

MCP 설정 예시:

{
  "mcpServers": {
    "rf-log-mcp": {
      "command": "rf-log-mcp",
      "args": [],
      "env": {
        "RF_LOG_MCP_DB": "D:\\data\\rf-log-mcp\\store.sqlite3"
      }
    }
  }
}

로컬 디버깅

stdio 전송을 시작하지 않고 서비스 출력만 확인하려면 다음을 사용하세요:

uv run python debug_service.py --fixture tests/fixtures/single_failure_611.xml --action summary
uv run python debug_service.py --fixture tests/fixtures/single_failure_72.json --action failure_path --selector s1-t2
uv run python debug_service.py --fixture tests/fixtures/errors_and_long_72.json --action search --query "collected line" --limit 2

자주 묻는 질문

1. 왜 wheel을 LLM에 직접 전달할 수 없나요?

LLM은 Python 패키지 파일 자체가 아니라 MCP 서버 프로세스를 호출하기 때문입니다.

2. 왜 정수 run_id 사용을 권장하나요?

더 짧고 LLM, 다중 턴 대화 및 수동 조사에 더 적합하기 때문입니다. 긴 해시는 내부 중복 제거용으로만 유지됩니다.

3. get_view / search_messages에 파일 경로를 전달할 수 있나요?

네, 가능합니다. 해당 파일이 이미 파싱된 경우, 서비스는 경로를 해당 run_id로 변환한 후 조회합니다. 하지만 여전히 parse_result()가 반환하는 정수 run_id를 우선적으로 사용하는 것을 권장합니다.

4. 어떤 경우에 이 프로젝트를 직접 사용할 수 없나요?

사용 중인 LLM 플랫폼이:

• MCP를 지원하지 않거나

• 로컬 프로세스 시작을 지원하지 않는 경우

직접 연결할 수 없으며, 별도의 통합 계층을 구현해야 합니다.

개발 체크리스트

uv run ruff check .
uv run pytest