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が呼び出すのは MCPサーバープロセス であり、Pythonパッケージファイルそのものではないためです。

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