logicmonitor

LogicMonitor MCP サーバー

LogicMonitor REST API v3 と連携する Model Context Protocol（MCP）サーバーです。306 個の構造化ツール、15 個のワークフロープロンプト、26 個のリソースを通じて、AI アシスタントが LogicMonitor の監視データを利用できます。オプションの連携機能として、Granite TTM 予測と自然言語サマリー向けの IBM watsonx.ai、あらゆるプロバイダーに対応する Terraform IaC、HuggingFace のローカル Granite モデルへのフォールバックがあります。

Claude Desktop、Claude Code、Cursor、Continue、Cline など、MCP 対応のあらゆるクライアントで動作します。

クイックスタート

1. LogicMonitor の Bearer Token を取得します：

• LogicMonitor ポータルにログインします
• Settings → Users and Roles → API Tokens に移動します
• API 専用の新しいユーザーを作成するか、既存のユーザーにトークンを追加します
• Bearer token をコピーします

2. MCP クライアントを設定します：

Claude Code（CLI）の場合：

claude mcp add logicmonitor \
  -e LM_PORTAL=yourcompany.logicmonitor.com \
  -e LM_BEARER_TOKEN=<your-bearer-token> \
  -- uvx --from lm-mcp lm-mcp-server

IBM watsonx.ai との連携（オプション — Granite TTM 予測と自然言語サマリーを追加）の場合：

claude mcp add logicmonitor \
  -e LM_PORTAL=yourcompany.logicmonitor.com \
  -e LM_BEARER_TOKEN=<your-bearer-token> \
  -e WATSONX_API_KEY=<your-ibm-cloud-api-key> \
  -e WATSONX_URL=https://us-south.ml.cloud.ibm.com \
  -e WATSONX_PROJECT_ID=your-watsonx-project-id \
  -- uvx --from "lm-mcp[ibm]" lm-mcp-server

Terraform IaC（オプション — terraform plan/apply/generate ツールを追加）の場合：

claude mcp add logicmonitor \
  -e LM_PORTAL=yourcompany.logicmonitor.com \
  -e LM_BEARER_TOKEN=<your-bearer-token> \
  -e TF_WORKSPACE_DIR=/path/to/terraform/workspaces \
  -- uvx --from lm-mcp lm-mcp-server

HuggingFace のローカルモデル（オプション — ローカルの Granite TTM と自然言語サマリーを追加。クラウド API は不要）の場合：

claude mcp add logicmonitor \
  -e LM_PORTAL=yourcompany.logicmonitor.com \
  -e LM_BEARER_TOKEN=<your-bearer-token> \
  -- uvx --from "lm-mcp[huggingface]" lm-mcp-server

Claude Desktop の場合は、設定ファイルに追加します（下記のMCP クライアントの設定を参照してください）。

3. 動作を確認します：

claude mcp list

次のように表示されます：logicmonitor: uvx --from lm-mcp lm-mcp-server - ✓ Connected

4. プロンプトでテストします：

"Show me all critical alerts in LogicMonitor"

v4.2.1 の新機能

修正リリースです。LMv1 ポータルで書き込みを含む認証が再び機能するようになりました。署名は LogicMonitor のドキュメントに記載された手順に従い、送信される正確なバイト列を対象にします。ツールのエラーは isError: true としてクライアントに届き、失敗として監査されます。各ツールはそれぞれのスキーマに従って呼び出せるようになり、あらゆる設定で stdio が起動し、/readyz はポータルを呼び出さなくなりました。リリースには Python 3.11 から 3.13 までのテストスイートの通過が必須となり、コンテナはハッシュチェック、ダイジェスト固定のベースイメージ、固定の非 root UID を使用して uv.lock からインストールするようになりました。

v4.2.0

v4.2.0 の新機能

強化されたマルチポータルモードが登場しました。1 つのサーバーで複数の顧客ポータルを扱い、実行時に list_portals、use_portal、current_portal、reload_portals でアクティブなポータルを選択できます。ポータルごとにサーバー（および貼り付けるトークン）を 1 つ用意する代わりに、MCP クライアントへの登録は 1 つで済みます。認証情報は age 暗号化されたボルトに保存され、ボルトのレコードで別途指定されていない限り、各ポータルは読み取り専用です。また、このモードは意図的に stdio 専用となっており、共有 HTTP トランスポートでの起動をサーバーが拒否します。このリリースでは依存関係も全面的に更新され、ロックファイル全体で 53 件の Dependabot アラートが解消されました。

v4.1.0

v4.1.0 の新機能

ネイティブの OTLP メトリクスに対応しました。LogicMonitor の新しい OTLP Metrics 機能（機能フラグで有効化、Prometheus を基盤とする）は、UI がダッシュボードの Advanced Metrics Widget のみで、Metrics Explorer はまだない初期段階として提供されています。次の 4 つのツールにより、このデータをプログラムから初めて利用できるようになりました。検出用の get_otlp_metric_names、get_otlp_metric_labels、get_otlp_label_values と、時系列行列を返す完全な PromQL 範囲クエリ用の query_otlp_metrics です。これら 4 つのツールは、実際の OTel コレクター（Kubernetes cAdvisor とアプリケーションメトリクス）からデータを取り込んだ、機能フラグ有効のポータルで実環境検証済みです。また、機能が無効なポータルからの応答を分かりやすい利用可能性の通知に変換し、行列の応答が大きい場合は等間隔のダウンサンプリングでサイズを抑えて、LLM で扱いやすくします。

## v4.0.0 の新機能

メジャーリリースです。 すべてのツールが、実在することが確認され、稼働中のポータルで検証されたエンドポイントをラップするようになりました。導入当初から存在しない API パスを呼び出していた 6 つのツール（get_cloud_cost_accounts、get_cost_summary、get_resource_cost、get_remediation_status、get_remediation_history、get_batchjob_history）を削除しました。コスト推奨ツールは、動作する /cost-optimization API を利用するようになりました。Service Insight ツールは、レガシーの v1 websites API ではなく、実際の Service Insight オブジェクト（deviceType 6 のデバイスと BizService グループ）を照会するようになりました。Automated Diagnostics & Remediation の機能がすべて利用可能になりました。get_diagnostic_remediation_assignments と get_diagnostic_remediation_results（スクリプト出力を含む構造化された実行記録で、監査ログのスクレイピングに代わります）、execute_diagnostic、診断および修復ソースの完全な CRUD とインポート／エクスポート、新しいアクションチェーン／アクションルール名前空間（set_action_rule_status 切り替えを含む 11 個のツール）を利用できます。update_logicmodule に 2 つの新しいソースタイプが追加され、適用モードも実際に適用を行うようになりました（以前は、サブツール自身の確認ガードに引っかかっていました）。run_report の実行は get_report_execution でポーリングできるようになり、get_alert_details でメッセージ本文全体を取得できるようになりました。また、レポート一覧ツールで NextGen レポートを確認できます。

v3.9.x 以前を含むすべてのリリース履歴は、CHANGELOG.md にあります。v3.8.0 のネットワークインテリジェンスツールについては、専用のリファレンス documentation/networking-intelligence.md をご覧ください。

機能

306 個のツールで、LogicMonitor API の幅広い機能を網羅しています（LM 277 個 + AAP 18 個 + Terraform 10 個 + watsonx 1 個）。

コア監視機能

• アラート管理：アラートの照会、確認、複数アラートの一括確認、メモの追加、ルールの表示
• デバイス管理：完全な CRUD — デバイスとグループの一覧表示、作成、更新、削除
• メトリクスとデータ：データソース、インスタンス、メトリクスデータ、グラフの照会。手動データソースインスタンスの CRUD。
• ダッシュボード管理：ダッシュボード、ウィジェット、グループの完全な CRUD
• SDT 管理：スケジュール済みダウンタイムの作成、一覧表示、一括作成／削除
• コレクター管理：コレクターとコレクターグループの一覧表示

拡張機能

• Web サイト監視：合成チェックと Web サイトグループの完全な CRUD
• レポート管理：レポートの一覧表示、表示、実行、スケジュール管理
• エスカレーション管理：エスカレーションチェーンと受信者グループの完全な CRUD
• アラートルール：アラートルーティングルールの完全な CRUD
• ユーザーとロールの管理：ユーザー、ロール、アクセスグループ、API トークンの表示
• Ops 管理：監査ログ、Ops メモ、ログイン／変更監査
• 自動診断と修復：割り当て済みソースの解決、スクリプト出力を含む構造化された実行結果、診断／修復ソースの CRUD、手動実行、アクションチェーンとルール
• ネイティブ OTLP メトリクス（プレビュー）：機能フラグで有効化される OTLP メトリクスストアに対する、メトリクスとラベルの検出、および PromQL の範囲クエリ

AI 分析ツール

生の監視データを実用的なインサイトに変換する、サーバーサイドのインテリジェンス機能です。

• アラートの相関分析：デバイス、データソース、時間的な近さに基づいて関連するアラートを自動的にクラスタリングします。手動での多数の API 呼び出しを、集約された単一のビューに置き換えます。
• アラート統計：重大度別のアラート件数、上位 10 件のデバイスとデータソース、傾向分析用の時間区分別分布を集計します。
• メトリクスの異常検出：データ分布に基づいて自動選択される複数の異常検出手法（z スコア、IQR、MAD）を提供します。
• メトリクスのベースライン：メトリクスの動作をベースラインスナップショットとして保存し、現在のパフォーマンスをベースラインと比較して変化を検出します。
• スケジュール分析：外部のスケジューラーや Webhook から分析ワークフロー（アラート相関分析、RCA、トップトーカー、ヘルスチェック）をトリガーするための HTTP API エンドポイントです。

ML／統計分析ツール

キャパシティプランニング、トレンド分析、運用スコアリングに使える純粋な Python 統計手法です。

• メトリクス予測: 線形回帰、Holt-Winters の三重指数平滑法、IBM Granite TTM（watsonx.ai 経由、オプション）を自動選択し、信頼区間としきい値超過の予測を行います
• メトリクス相関: 複数のメトリクス系列を対象に Pearson 相関行列を算出し、強い相関を強調表示します
• エラーバジェット追跡: SLO に基づいてエラーバジェットを計算し、バーンレート、枯渇予測、ステータス分類を行います
• 変化点検出: CUSUM アルゴリズムでレジームシフトと平均水準の変化を特定します
• アラートノイズスコアリング: Shannon エントロピーとフラップ検出でアラートノイズを定量化（0～100）し、調整に関する推奨事項を提示します
• 季節性検出: 自己相関に基づき、標準的な間隔で周期性を検出し、ピーク時間帯を特定します
• 可用性計算: アラート履歴から SLA 形式の稼働率を算出し、MTTR、インシデント件数、デバイスごとの内訳を提示します
• 影響範囲分析: デバイス障害シナリオにおける下流への影響を、トポロジーに基づいてスコアリングします
• 変更相関分析: アラートの急増と監査／変更ログを相互参照し、変更に起因するインシデントを特定します
• トレンド分類: メトリクスを安定、増加、減少、循環、または変動に分類します
• デバイス健全性スコアリング: Z スコア分析と設定可能な重みを使って、複数のメトリクスを合成した健全性スコア（0～100）を算出します

複合ワークフローツール

複数のサブツールを組み合わせ、1 回の呼び出しで実行できる多段階の分析ツールです。各ツールは detail_level（"summary" または "full"）に対応し、必要に応じて summarize=true を指定すると、IBM Granite による平易な英語の要約を生成します（watsonx.ai が必要です）。また、サブツールが失敗しても部分的な結果を返します。

• トリアージ: アクティブなアラートの相関分析、ノイズのスコアリング、影響範囲の分析、最近の変更との相互参照を行います
• 健全性チェック: デバイス健全性スコア、監視範囲、異常検出、アクティブなアラート、過去 30 日間の可用性を確認します
• キャパシティプラン: データソースごとの予測、トレンド分類、季節性検出、変化点分析を行います
• ポータル概要: アラート統計、コレクターの健全性、アクティブな SDT、アラートクラスター、ノイズ評価、ダウン状態のデバイスを表示します
• 診断: アラートの詳細、デバイスのコンテキスト、相関分析、影響範囲、健全性スコアリング、根本原因分析を行います
• LogicModule の更新（安全な部分更新）: update_logicmodule(type, id, changes, mode) は、現在の完全な定義をエクスポートして changes をディープマージし、必須フィールドを検証したうえで、ドライランの差分（デフォルト）を返すか、マージを適用します。過去 2 件のインシデントで本番の Groovy スクリプトを消失させた、完全置換による空白化を防ぎます。configsource、datasource、eventsource、logsource、propertysource、topologysource に対応しています。
• 検索ツール: 名前と説明を対象に、カテゴリで絞り込んですべてのツールをキーワード検索します

APM トレースツール

LogicMonitor APM（アプリケーションパフォーマンス監視）のサービス検出と RED メトリクスに対応します。

• サービス検出: トレース対象のすべてのサービスを一覧表示し、個々のサービスの詳細とプロパティを確認します
• オペレーション一覧: 各サービス内で監視されているエンドポイント／ルートを検出します
• RED メトリクス: サービス単位とオペレーション単位で、継続時間、エラー件数、オペレーション件数を確認します
• アラート連携: トレース対象の任意のサービスのアクティブなアラートを表示します
• プロパティの確認: OTel 属性、名前空間情報、自動検出されたメタデータを確認します

Ansible Automation Platform との統合

Ansible Automation Platform（AAP）を通じた、オブザーバビリティ主導の修復を実現する18個のツールです。LogicMonitor のアラートを自動修復プレイブックに接続します。

• ジョブテンプレート：ジョブテンプレートの一覧表示、詳細確認、追加変数やホスト制限を指定した起動
• ジョブ実行：ジョブの起動、ステータス確認、出力の表示、実行のキャンセルまたは再起動
• ワークフロー：ワークフローテンプレートの起動、複数ステップからなる自動化シーケンスの監視
• インベントリとホスト：インベントリの一覧表示、対象を絞った修復に向けたホストの詳細確認
• プロジェクトと認証情報：利用可能なプロジェクトと認証情報の参照（シークレットが公開されることはありません）
• 書き込み保護：launch_job、launch_workflow、cancel_job、relaunch_job の実行には LM_ENABLE_WRITE_OPERATIONS=true が必要です
• Jinja2 の安全性：テンプレートインジェクションを防ぐため、すべての extra_vars 入力を検証します

AAP ツールはオプションです。AWX_URL と AWX_TOKEN が設定されている場合のみ表示されます。修復テンプレートについては、サンプルプレイブックを参照してください。

IBM watsonx.ai との統合

watsonx.ai 経由で IBM Granite 基盤モデルを使用する、オプションの AI を活用した機能強化です。watsonx.ai プロジェクトを含む IBM Cloud アカウントが必要です（Lite／無料プランにも対応しています）。

• Granite TTM による予測：IBM Granite Tiny Time Mixer（TTM）を使用した、ML による時系列予測です。forecast_metric で method="ttm" を指定すると、季節性や非線形パターンを検出する96ステップの予測を実行できます。512件以上のデータポイントが必要です。データが不十分な場合は、統計手法に自動でフォールバックします。
• Granite による自然言語の要約：複合ワークフローツール（triage、diagnose、health_check、capacity_plan、portal_overview）で、シフト引き継ぎ用の平易な要約を生成します。summarize=true を渡すと、構造化された出力に IBM Granite が生成した分析の要約が追加されます。
• watsonx_summarize：任意の JSON データを受け取り、Granite 4.0 経由で簡潔な自然言語の要約を生成するスタンドアロンツールです。あらゆる MCP ツールの出力の要約に役立ちます。

watsonx ツールはオプションです。WATSONX_API_KEY と WATSONX_PROJECT_ID が設定されている場合のみ表示されます。IBM SDK の依存関係を含めるには、lm-mcp[ibm] をインストールしてください。

セットアップ：

1. cloud.ibm.com で無料の IBM Cloud アカウントを作成します
2. IBM Cloud カタログから watsonx.ai Runtime（Lite プラン、無料）をプロビジョニングします
3. watsonx.ai プロジェクトを作成し、Runtime インスタンスを関連付けます
4. cloud.ibm.com/iam/apikeys で IBM Cloud API キーを生成します
5. MCP サーバーに WATSONX_API_KEY、WATSONX_URL、WATSONX_PROJECT_ID を設定します

Terraform 統合

あらゆる Terraform プロバイダーを使用した Infrastructure as Code ワークフロー向けの 11 個のツールです。AI エージェントは HCL を作成したり、既成のスクリプトを使用したり、既存の LM リソースをリバースエンジニアリングしたりできます。

• terraform_init：ワークスペースを初期化し、プロバイダーをダウンロードします（書き込み権限が必要です）
• terraform_validate：HCL 構成の構文をチェックします
• terraform_plan：構造化 JSON 出力で変更をプレビューします（書き込み権限が必要です：プロバイダーとデータソースがライブ API を呼び出します）
• terraform_apply：変更を適用します（三重ゲート：書き込み権限 + 構成フラグ + confirm パラメーター）
• terraform_destroy：インフラストラクチャを破棄します（同じ三重ゲート）
• terraform_import：既存のリソースを Terraform の状態にインポートします
• terraform_state_list / terraform_state_show：現在の状態を確認します
• terraform_output：Terraform の出力を表示します
• terraform_write_config：ワークスペースディレクトリに HCL ファイルを書き込みます
• terraform_generate：logicmonitor/logicmonitor プロバイダーを使用して、既存の LM ポータルリソースを HCL としてエクスポートします

Terraform ツールはオプションです。TF_WORKSPACE_DIR が設定されている場合にのみ表示されます。別途 terraform CLI をインストールする必要があります。

terraform サブプロセスは、サーバーの環境から PATH、HOME、TMPDIR、TF_*、プロキシ設定（HTTP_PROXY、HTTPS_PROXY、NO_PROXY とそれらの小文字形式）、CA 設定（SSL_CERT_FILE、SSL_CERT_DIR）のみを引き継ぎます。そのため、LM_BEARER_TOKEN や AWS_SECRET_ACCESS_KEY などのサーバーおよびクラウドの認証情報が、プロバイダーやデータソースのコードに渡されることはありません。logicmonitor プロバイダーは、サーバーの LMv1 構成から LM_API_ID、LM_API_KEY、LM_COMPANY（およびそれらの TF_VAR_lm_* 形式）を取得します。他のプロバイダーは、HCL から渡される TF_VAR_* 変数、または ~/.aws/credentials などの HOME 配下のファイルから認証情報を取得します。バックエンドブロックでは変数を読み取れないため、バックエンドの認証情報は HOME 配下のファイル、または terraform_init の backend_config キー（profile、access_key、sas_token など）から取得します。

var_file とローカルバックエンドの path は、シンボリックリンクを含め、ワークスペース内に解決される必要があります。terraform_init の backend_config は、local、s3、azurerm バックエンドのキーを含むオブジェクトを受け取り、名前によるエンドポイントおよびプロキシの上書きを拒否します。TF_TIMEOUT を超過したコマンドには SIGINT が送信され、状態を保存してロックを解放するために 30 秒間待機した後、強制終了されます。タイムアウトした apply または destroy は、ロックがまだ保持されている可能性と、状態が不完全である可能性を報告します。

3 つの利用方法：

1. エージェントが作成：AI が自然言語から HCL を生成し、ワークスペースに書き込み、プランを作成して適用します
2. 既成のスクリプト：TF_WORKSPACE_DIR を既存の .tf ファイルに設定し、エージェントがそれらを操作します
3. リバースエンジニアリング：terraform_generate で LM リソースを HCL としてエクスポートし、状態にインポートします

HuggingFace ローカルフォールバック

watsonx.ai API の認証情報が設定されていない場合、TTM 予測と NL 要約は HuggingFace transformers 経由でローカルの Granite モデルに自動的にフォールバックします。lm-mcp[huggingface] でインストールしてください。

優先順位： watsonx.ai API（リモート） > HuggingFace ローカル > 統計／線形

• TTM モデル：ibm-granite/granite-timeseries-ttm-r2（コンテキスト 512、予測 96）
• LLM モデル：ibm-granite/granite-3.3-2b-instruct（パラメーター数 2B、CPU で実行）
• モデルは初回の推論呼び出し時に遅延読み込みされます（初回ダウンロード：約 500MB の TTM、約 4GB の LLM）
• WatsonxClient と同じインターフェイスを使用するため、既存の watsonx ツールはどちらのバックエンドでも動作します

LogicModules

• DataSources：データソース定義をクエリしてエクスポートします
• ConfigSources：定義をクエリし、Config Archive からデバイス設定データを取得し、差分を表示し、オンデマンド収集を開始し、変更履歴を監査します
• EventSources：イベント検出モジュールをクエリしてエクスポートします
• PropertySources：プロパティ収集モジュールをクエリ、作成、エクスポートします
• TopologySources：トポロジーマッピングモジュールをクエリしてエクスポートします
• LogSources：ログ収集モジュールをクエリしてエクスポートします
• インポートのサポート：JSON 定義から LogicModules をインポートします

高度な機能

• コスト最適化：コストに関する推奨事項、推奨カテゴリ、アイドル状態のリソース（LM Envision）
• ネットワークトポロジー：デバイスの隣接関係、インターフェース、フロー、接続
• バッチジョブ：バッチジョブの実行履歴を表示、管理します
• ログ／メトリクスの取り込み：LMv1 認証を使用してログとメトリクスを送信します

MCP プロトコルの機能

• リソース：API リファレンス用の 26 個のスキーマ／列挙型／フィルター／ガイドリソース
• プロンプト：15 個のワークフローテンプレート（インシデントのトリアージ、RCA、キャパシティ予測、修復の実行など）
• 補完：ツール引数の自動補完

Claude Code Skills

Claude Code 用に事前構築されたスラッシュコマンドワークフローです。複数のツールを連携させ、ガイド付きの運用ランブックを実行します。

スキル	コマンド	説明
アラートトリアージ	/lm-triage	アクティブなアラートを調査し、ノイズをスコアリングし、クラスターを関連付け、影響範囲を評価して、対処します
デバイスの健全性	/lm-health <device>	包括的な健全性チェック — メトリクス、異常、健全性スコア、可用性、トポロジー
ポータル概要	/lm-portal	シフト引き継ぎ用のポータル全体のスナップショット — アラート、コレクター、SDT、ダウン中のデバイス
キャパシティ計画	/lm-capacity <device>	トレンド分析、季節性の検出、しきい値超過の予測、適正規模への調整
APM 調査	/lm-apm [service]	サービスの検出、オペレーションレベルの RED メトリクス、アラートの関連付け
修復	/lm-remediate	アラートを診断し、プレイブックを検索または生成し、AAP ジョブを起動して、修正を確認します

Skills はリポジトリに含まれています。リポジトリをクローンし、Claude Code で /lm-triage を実行して開始してください。

運用機能

• セキュリティ優先：デフォルトでは読み取り専用です。書き込み操作には明示的なオプトインが必要です
• レート制限への対応：指数バックオフとジッターを使用して自動再試行します
• サーバーエラーからの復旧：冪等なリクエスト（GET、PUT、DELETE）では、5xx サーバーエラー時に自動再試行します。5xx が返された POST または PATCH は、サーバー側ですでに適用されている可能性があるため再送信しません。タイムアウトや接続切断は再送信せず、報告します
• ページネーションのサポート：オフセットベースのページネーションで大規模な結果セットを処理します
• セッションの永続化：再起動後も維持される、ファイルベースのセッション変数を任意で使用できます

マルチポータルモード（任意）

ポータルごとにサーバーエントリ（とトークン）を用意する代わりに、単一のサーバーエントリから複数の顧客ポータルを操作できます。LM_MULTI_PORTAL=true を設定し、サーバーの接続先を認証情報ボールトに指定します。ツール一式は一度だけ読み込まれ、実行時にアクティブなポータルを切り替えられます。管理には 4 つのツールを使用します：list_portals、use_portal、current_portal、reload_portals。認証情報は環境変数ではなく、age で暗号化されたボールト（またはテスト用のプレーンテキスト JSON ファイル）から取得されます。また、各ポータルは書き込み可能として明示的に指定されていない限り、読み取り専用です。そのため、アシスタントはどのポータルも閲覧できますが、誤って変更することはありません。マルチポータルモードはstdio のみで動作し（HTTP トランスポートではサーバーの起動が拒否されます）、Terraform ツールは使用できません。変更されていない単一ポータルの動作（LM_MULTI_PORTAL なし、固定の LM_PORTAL とトークン）は従来どおりです。詳しくは MULTIPORTAL.md を参照してください。

インストール

PyPI 経由（推奨）

# Using uvx (no install needed)
uvx --from lm-mcp lm-mcp-server

# Using pip
pip install lm-mcp

ソースから

git clone https://github.com/ryanmat/mcp-server-logicmonitor.git
cd mcp-server-logicmonitor
uv sync

Docker デプロイ

HTTP トランスポートを使用したリモート／共有デプロイの場合：

cd deploy
cp .env.example .env
# Edit .env with your credentials, including LM_HTTP_AUTH_TOKEN (required)

# Run with docker-compose
docker compose up -d

# With TLS via Caddy
docker compose --profile tls up -d

サーバーは、コンテナオーケストレーション用のヘルスエンドポイントを公開します。

• GET /health - すべてのコンポーネントのステータスを含む詳細なヘルスチェックです（有効時はLM API接続チェックも追加されます。LM_HTTP_AUTH_TOKENを提示する呼び出し元、またはトークンが設定されていない場合に利用できます）
• GET /healthz - ライブネスプローブ（200 OKまたは503）
• GET /readyz - レディネスプローブ（ローカルチェックのみ。LM APIは呼び出しません）

/mcpおよび/api/v1/*へのPOSTリクエストでは、Content-Type: application/jsonを送信する必要があります。それ以外のボディタイプは415になります。/healthzと/readyzを除くすべてのルート（/healthを含む）は、サーバーが想定するHost名（ループバック名、ワイルドカードではないLM_HTTP_HOST、およびLM_HTTP_ALLOWED_HOSTS）からのリクエストにのみ応答し、それ以外は400で拒否します。この2つのプローブは、ポッドIP経由でのプローブが引き続き機能するよう、任意のHostを受け入れます。composeファイルではすべてのプロファイルでLM_HTTP_AUTH_TOKENが必要であり、CaddyのtlsプロファイルではDOMAINが許可ホストとして渡されます。

Kubernetes

deploy/k8s/deployment.yamlは、公開済みのghcr.ioイメージを実行する、ベンダーに依存しないDeploymentとServiceです。AKS、EKS、GKE、OpenShift、または通常のKubernetesで動作し、作成したKubernetesシークレットから認証情報を読み込み、上記のエンドポイントにライブネスプローブとレディネスプローブを設定します。ファイルの先頭に記載されているシークレットを作成した後、kubectl apply -f deploy/k8s/deployment.yamlで適用してください。

設定

環境変数

変数	必須	デフォルト	説明
LM_PORTAL	はい	-	LogicMonitor ポータルのホスト名（例：company.logicmonitor.com）
LM_BEARER_TOKEN	はい*	-	API Bearer トークン（10 文字以上）
LM_ACCESS_ID	いいえ	-	LMv1 API アクセス ID（取り込み API 用）
LM_ACCESS_KEY	いいえ	-	LMv1 API アクセスキー（取り込み API 用）
LM_ENABLE_WRITE_OPERATIONS	いいえ	false	書き込み操作（作成、更新、削除）を有効にします
LM_API_VERSION	いいえ	3	API バージョン
LM_TIMEOUT	いいえ	30	リクエストのタイムアウト（秒、範囲：5～300）
LM_MAX_RETRIES	いいえ	3	レート制限されたリクエスト、および冪等なリクエスト（GET、PUT、DELETE）に対するサーバーエラーの最大再試行回数。5xx を受け取った POST または PATCH は再送されません（範囲：0～10）
LM_RETRY_AFTER_CAP_SECONDS	いいえ	120	再試行間の最大待機時間。サーバーの Retry-After によりバックオフ時間はこの上限まで延長されますが、短縮されることはありません
LM_TRANSPORT	いいえ	stdio	トランスポートモード：stdio（ローカル）または http（リモート）
LM_MULTI_PORTAL	いいえ	false	1 つのサーバーから複数の顧客ポータルを提供し、実行時に use_portal で選択します。stdio のみ。
LM_VAULT_FILE	いいえ	-	age で暗号化されたポータル保管庫へのパス（マルチポータル）
LM_AGE_KEY	いいえ	-	保管庫を復号する age ID へのパス（マルチポータル）
LM_PORTALS_FILE	いいえ	-	暗号化されていない JSON ポータルマップ（マルチポータル、テスト専用。両方が設定されている場合は暗号化された保管庫が優先されます）
LM_HTTP_HOST	いいえ	0.0.0.0	HTTP サーバーのバインドアドレス。LM_TRANSPORT=http の場合、127.0.0.1、::1、localhost 以外のアドレスでは、LM_HTTP_AUTH_TOKEN または LM_HTTP_ALLOW_UNAUTHENTICATED=true が必要です。設定されていない場合、サーバーは起動を拒否します。
LM_HTTP_PORT	いいえ	8080	HTTP サーバーのポート
LM_CORS_ORIGINS	いいえ	-	カンマ区切りの CORS オリジン（デフォルト：なし）
LM_HTTP_AUTH_TOKEN	いいえ	-	/mcp および /api/v1/* でこの Bearer トークンを必須にします（16 文字以上）。LM_HTTP_ALLOW_UNAUTHENTICATED=true が設定されていない場合、デフォルトの 0.0.0.0 を含む、ループバック以外の LM_HTTP_HOST で起動するには必要です。ヘルスエンドポイントと / はプローブ用に公開されたままです。HTTP トランスポートのみ。
LM_HTTP_ALLOWED_HOSTS	いいえ	-	/healthz と /readyz を除くすべてのルートでサーバーが受け入れる、カンマ区切りの Host 名。127.0.0.1、::1、localhost、およびワイルドカードではない LM_HTTP_HOST に加えて指定します（例：リバースプロキシが転送するパブリック名）。HTTP トランスポートのみ。
LM_HTTP_ALLOW_UNAUTHENTICATED	いいえ	false	別の方法（認証プロキシ、プライベートネットワークなど）で保護されたリスナーの場合に、LM_HTTP_AUTH_TOKEN なしでループバック以外の LM_HTTP_HOST での起動を許可します。HTTP トランスポートのみ。
LM_SESSION_ENABLED	いいえ	true	セッションコンテキストの追跡を有効にします
LM_SESSION_HISTORY_SIZE	いいえ	50	履歴に保持するツール呼び出し数
LM_LOG_LEVEL	いいえ	warning	ログレベル：debug、info、warning、error のいずれか。記録は stderr に出力されます。書き込み監査行（成功時は info、失敗時は warning）では、password、token、api_key、extra_vars などの認証情報に該当するキーの引数値、ssh.pass や snmp.community などの LogicMonitor 認証情報プロパティ、および property_name がそのいずれかである場合の property_value が秘匿されます
LM_FIELD_VALIDATION	いいえ	warn	フィールド検証：off、warn、error のいずれか
LM_ENABLED_TOOLS	いいえ	-	有効にするツール名またはグロブパターンをカンマ区切りで指定します（例：get_*,triage）。LM_DISABLED_TOOLS とは同時に指定できません。
LM_DISABLED_TOOLS	いいえ	-	無効にするツール名またはグロブパターンをカンマ区切りで指定します（例：delete_*）。LM_ENABLED_TOOLS とは同時に指定できません。
LM_MCP_CATEGORIES	いいえ	-	含めるカテゴリ名をカンマ区切りで指定します：read、write、delete、export、import、session、workflow。LM_ENABLED_TOOLS／LM_DISABLED_TOOLS との共通部分を適用します。対象を絞り込むことのみ可能で、拡張はされません。ツール数に上限があるクライアント（例：Cursor の 40 ツール上限）に便利です。
LM_HEALTH_CHECK_CONNECTIVITY	いいえ	false	認証済みの呼び出し元に対して、/health に LM API の ping を含めます（/readyz には含めません）
LM_SESSION_PERSIST_PATH	いいえ	-	永続セッション変数のファイルパス（再起動後も保持されます）
LM_ANALYSIS_MAX_CONCURRENCY	いいえ	4	同時に実行できる分析ワークフロー（/api/v1/analyze とアラート Webhook）の数。以降の送信は受け付けられ、pending として待機します。1 以上。HTTP トランスポートのみ。
AWX_URL	いいえ	-	Ansible Automation Platform コントローラーの URL（例：https://aap.example.com）
AWX_TOKEN	いいえ	-	AAP の個人用アクセストークン
AWX_VERIFY_SSL	いいえ	true	AAP 接続時に SSL 証明書を検証します
AWX_TIMEOUT	いいえ	30	AAP API 呼び出しのリクエストタイムアウト（秒）
AWX_MAX_RETRIES	いいえ	3	レート制限された AAP リクエスト、および冪等なリクエストに対するサーバーエラーの最大再試行回数。5xx を受け取ったジョブの起動は再送されません。Retry-After によりバックオフ時間は最大 120 秒まで延長されます
WATSONX_API_KEY	いいえ	-	watsonx.ai 用 IBM Cloud API キー（Granite TTM と NL サマリーを有効にします）
WATSONX_URL	いいえ	https://us-south.ml.cloud.ibm.com	IBM watsonx.ai エンドポイント URL
WATSONX_PROJECT_ID	いいえ	-	IBM watsonx.ai プロジェクト ID
WATSONX_TIMEOUT	いいえ	60	watsonx.ai API 呼び出しのリクエストタイムアウト（秒）
TF_WORKSPACE_DIR	いいえ	-	Terraform ワークスペースのルートディレクトリ（Terraform ツールを有効にします）
TF_TERRAFORM_BINARY	いいえ	terraform	terraform バイナリへのパス
TF_TIMEOUT	いいえ	300	Terraform コマンドのタイムアウト（秒）
TF_AUTO_APPROVE_ENABLED	いいえ	false	terraform apply／destroy 操作を有効にします
HF_TTM_MODEL	いいえ	ibm-granite/granite-timeseries-ttm-r2	HuggingFace TTM モデル名またはパス
HF_LLM_MODEL	いいえ	ibm-granite/granite-3.3-2b-instruct	HuggingFace LLM モデル名またはパス
HF_DEVICE	いいえ	auto	推論に使用する Torch デバイス（cpu、cuda、mps、auto）
HF_CACHE_DIR	いいえ	-	HuggingFace モデルのキャッシュディレクトリ
*LM_BEARER_TOKEN、または LM_ACCESS_ID と LM_ACCESS_KEY の両方が必要です。

認証方法

Bearer トークン（推奨）：

• 設定が簡単で、ほとんどの操作で使用できます
• LM_BEARER_TOKEN を設定します

LMv1 HMAC（取り込みに必須）：

• ingest_logs と push_metrics ツールに必要です
• LM_ACCESS_ID と LM_ACCESS_KEY の両方を設定します
• Bearer トークンと併用できます

API 認証情報の取得

Bearer トークン：

1. LogicMonitor ポータルにログインします
2. Settings → Users and Roles → API Tokens に移動します
3. API 専用ユーザーを新規作成するか、既存のユーザーにトークンを追加します
4. Bearer トークンをコピーします

LMv1 認証情報：

1. Settings → Users and Roles → Users に移動します
2. ユーザーを選択し、API Tokens タブを開きます
3. Access ID と Access Key を作成するか、確認します

MCP クライアントの設定

クイックスタートでは、Claude Code について説明しています。JSON ベースのクライアント（Cursor、Claude Desktop、Cline、GitHub Copilot、Gemini CLI、OpenAI Codex）は、すべて同じブロックで同じサーバーを実行します。

{
  "mcpServers": {
    "logicmonitor": {
      "command": "uvx",
      "args": ["--from", "lm-mcp", "lm-mcp-server"],
      "env": {
        "LM_PORTAL": "yourcompany.logicmonitor.com",
        "LM_BEARER_TOKEN": "your-bearer-token"
      }
    }
  }
}

必要に応じて、LM_ENABLE_WRITE_OPERATIONS、LM_ACCESS_ID／LM_ACCESS_KEY（取り込み）、または watsonx／Terraform の変数を env に追加してください。クライアントごとの設定ファイルの場所と詳しい手順（Claude Code、Cursor、Claude Desktop、OpenAI Codex、Cline、GitHub Copilot、Gemini CLI）については、documentation/client-setup.md をご覧ください。

Cursor のツール数上限（40 個）

Cursor が読み込む MCP ツールは最初の 40 個だけなので、残りの約 240 個はエージェントから見えません。LM_MCP_CATEGORIES を使って、上限内に収まるよう厳選したサブセットを指定してください。workflow カテゴリだけでも（triage、diagnose、health_check、portal_overview、capacity_plan、さらにスコアリング／相関ツールと update_logicmodule を含めて）約 23 個のツールがあり、一般的なケースの 80％をカバーできます。

"env": {
  "LM_PORTAL": "yourcompany.logicmonitor.com",
  "LM_BEARER_TOKEN": "your-bearer-token",
  "LM_MCP_CATEGORIES": "workflow"
}

LM_MCP_CATEGORIES は LM_ENABLED_TOOLS と積集合で適用されます（対象を絞り込むだけで、拡張することはありません）。未設定の場合、サーバーは 306 個すべてのツールを返します。複数ポータルモードでは、4 個のポータルツールはカテゴリによるフィルタリングの対象外です（このモードのコントロールプレーンであるため）。また、厳選したツール数にも含まれません。LM_ENABLED_TOOLS の具体的な設定例については、documentation/client-setup.md をご覧ください。

利用可能なツール

306 個のツールで、LogicMonitor の全機能に加えて、オプションの Ansible Automation Platform、Terraform、IBM watsonx.ai との連携を利用できます。各ツールのパラメーターや読み取り／書き込みの分類を含む完全なリファレンスは、ツールレジストリから生成され、常に最新の状態に保たれる documentation/tools.md をご覧ください。

クライアントを離れることなく、実行時にツールを検索できます。

• search_tools：名前と説明をもとに、すべてのツールをキーワード検索します
• lm://guide/tool-categories リソース：306 個すべてのツールをドメイン別に分類して表示します

ツールは次のカテゴリに分類されています：アラート、アラートルール、デバイス、メトリクス、APM トレース、ダッシュボード、SDT、コレクター、Web サイト、エスカレーション、デバイスプロパティ、レポート、DataSources、LogicModules（Config／Event／Property／Topology／Log）、コスト最適化、アクション（チェーンとルール）、取り込み、ネットワークとトポロジー、バッチジョブ、Ops と監査、ユーザーとアクセス、サービス、ネットスキャン、OID、セッション、相関と分析、ベースライン、ML／統計分析、Ansible Automation Platform、修復、複合ワークフロー、エラーバジェット。

MCP リソース

サーバーは API リファレンス用に 26 個のリソースを公開します。

スキーマリソース

URI	説明
lm://schema/alerts	アラートオブジェクトのフィールド、型、説明
lm://schema/devices	デバイスオブジェクトのフィールドと型
lm://schema/sdts	SDT（Scheduled Downtime）オブジェクトのフィールド
lm://schema/dashboards	ダッシュボードオブジェクトのフィールド
lm://schema/collectors	コレクターオブジェクトのフィールド
lm://schema/escalations	エスカレーションチェーンオブジェクトのフィールド
lm://schema/reports	レポートオブジェクトのフィールド
lm://schema/websites	Web サイトチェックオブジェクトのフィールド
lm://schema/datasources	DataSource 定義のフィールド
lm://schema/users	ユーザーオブジェクトのフィールド
lm://schema/audit	監査ログエントリーのフィールド

列挙型リソース

URI	説明
lm://enums/severity	アラートの重大度レベル：critical(4)、error(3)、warning(2)、info(1)
lm://enums/device-status	デバイスのステータス値：normal(0)、dead(1) など
lm://enums/sdt-type	SDT の種類：DeviceSDT、DeviceGroupSDT など
lm://enums/alert-cleared	アラートのクリア状態：true、false
lm://enums/alert-acked	アラートの確認状態：true、false
lm://enums/collector-build	コレクターのビルドタイプ：EA、GD、MGD

フィルターリソース

URI	説明
lm://filters/alerts	アラートクエリのフィールドと演算子
lm://filters/devices	デバイスクエリのフィールドと演算子
lm://filters/sdts	SDT クエリのフィールドと演算子
lm://syntax/operators	フィルター演算子：:, ~, >, <, !:, !~, >:, <:

ガイドリソース

URI	説明
lm://guide/tool-categories	ドメインカテゴリ別に整理された全 306 個のツール
lm://guide/examples	一般的なフィルターパターンとクエリ例
lm://guide/mcp-orchestration	LogicMonitor を他の MCP サーバーと組み合わせるパターン
lm://guide/best-practices	推奨事項とアンチパターンを含む、シナリオ別のベストプラクティス
lm://guide/example-responses	レスポンス形式の理解に役立つ、主要なツールの出力例

MCP プロンプト

一般的なタスク向けの、事前に作成されたワークフローテンプレートです。

プロンプト	説明	引数
incident_triage	アクティブなアラートを分析し、パターンを特定して、根本原因を提案します	severity, time_window_hours
capacity_review	リソース使用率を確認し、容量に関する懸念事項を特定します	group_id, threshold_percent
health_check	主要なメトリクスを含む環境の健全性サマリーを生成します	include_collectors
alert_summary	重大度またはリソース別にグループ化したアラートダイジェストを生成します	group_by, hours_back
sdt_planning	メンテナンス期間の計画停止を計画します	device_ids, group_id
cost_optimization	クラウドコストを分析し、コスト削減の機会を見つけます	provider, threshold_percent
audit_review	最近の変更、ログイン、セキュリティイベントを確認します	hours_back, username
alert_correlation	デバイス間のアラートを関連付け、共通の根本原因を見つけます	severity, hours_back, device_id, group_id
collector_health	コレクターの負荷分散、バージョン、フェイルオーバーへの対応状況を評価します	group_id
troubleshoot_device	特定のデバイスのトラブルシューティングをガイドします	device_id
top_talkers	最も多くのアラートを生成している、ノイズの多いデバイスとデータソースを特定します	hours_back, limit, group_by
rca_workflow	アラート、トポロジー、変更履歴を組み合わせた根本原因分析をガイドします	device_id, alert_id, hours_back
capacity_forecast	容量の傾向を予測し、しきい値の超過を予測します	device_id, group_id, datasource, hours_back, threshold
remediate_workflow	LogicMonitor のアラートを診断し、Ansible Automation Platform を通じて修復します	alert_id, device_id
remediation	実行前の安全確認を行い、LogicMonitor の修復ソースを実行します	host_id, remediation_source_id

使用例

設定が完了したら、アシスタントに自然言語で質問します。代表的な例を以下に示します（サーバーは全306個のツールにわたって、さらに多くの内容を理解します）。

• 「LogicMonitorの最初の5台のデバイスを一覧表示して」（接続の簡易確認）
• 「過去1時間の重大なアラートをすべて表示して」
• 「アラートLMA12345を『ディスクの問題を調査中』というメモ付きで確認済みにして」
• 「デバイス123に適用されているデータソースは何ですか。また、過去1時間のCPUメトリクスを取得して」
• 「『API Health』という名前のダッシュボードを作成して、グラフウィジェットを追加して」
• 「デバイス123の2時間のメンテナンスウィンドウ（SDT）を作成して」
• 「過去4時間の重大なアラートをすべてトリアージして」
• 「デバイス123のヘルスチェックを実行してから、シフト引き継ぎ用にポータルの概要を教えて」
• 「デバイス123のメモリ使用量が90%に達する時期を予測して」
• 「デバイス789がダウンした場合、影響範囲はどのくらいですか？」
• 「今日、デバイス123で実行された診断と、スクリプトの出力を教えて」

上級ユーザー向けに、サーバーはLogicMonitorのフィルター構文を直接受け付けます。たとえば、「フィルターが 'displayName~"prod",hostStatus:"normal"' のデバイスを取得して」のように指定できます。hostStatus の値も含め、文字列値は引用符で囲みます。

開発

テストの実行

uv run pytest -v

リント

uv run ruff check src tests
uv run ruff format src tests

プロジェクト構成

src/lm_mcp/
├── __init__.py           # Package exports
├── analysis.py           # Scheduled analysis workflows and store
├── awx_config.py         # AAP connection configuration
├── config.py             # Environment-based configuration
├── exceptions.py         # Exception hierarchy
├── health.py             # Health check endpoints
├── logging.py            # Structured logging
├── server.py             # MCP server entry point
├── session.py            # Session context with optional persistence
├── registry.py           # Tool definitions and handlers (TOOLS + AWX_TOOLS)
├── validation.py         # Field validation with suggestions
├── auth/
│   ├── __init__.py       # Auth provider factory
│   ├── bearer.py         # Bearer token auth
│   └── lmv1.py           # LMv1 HMAC auth
├── client/
│   ├── __init__.py       # Client exports
│   ├── api.py            # Async HTTP client for LogicMonitor API
│   └── awx.py            # Async HTTP client for AAP controller API
├── completions/
│   └── registry.py       # Auto-complete definitions
├── prompts/
│   ├── registry.py       # Prompt definitions
│   └── templates.py      # Workflow template content
├── resources/
│   ├── registry.py       # Resource definitions
│   ├── schemas.py        # Schema content
│   ├── enums.py          # Enum content
│   ├── filters.py        # Filter content
│   ├── guides.py         # Tool categories, query examples, orchestration guide
│   ├── best_practices.py # Scenario-based best practices and anti-patterns
│   └── examples.py       # Example responses for key tools
├── transport/
│   ├── __init__.py       # Transport abstraction
│   └── http.py           # HTTP/SSE transport with analysis endpoints
└── tools/
    ├── __init__.py       # Tool utilities
    ├── alerts.py         # Alert management
    ├── alert_rules.py    # Alert rule CRUD
    ├── ansible.py        # Ansible Automation Platform tool handlers
    ├── baselines.py      # Metric baseline save/compare
    ├── collectors.py     # Collector tools
    ├── correlation.py    # Alert correlation, anomaly detection, metric correlation
    ├── cost.py           # Cost optimization
    ├── dashboards.py     # Dashboard CRUD
    ├── devices.py        # Device CRUD
    ├── escalations.py    # Escalation/recipient CRUD
    ├── event_correlation.py  # Change-alert correlation
    ├── forecasting.py    # Forecast, trend, seasonality, change points
    ├── imports.py        # LogicModule import
    ├── ingestion.py      # Log/metric ingestion
    ├── metrics.py        # Metrics and data
    ├── scoring.py        # Alert noise, availability, device health
    ├── sdts.py           # SDT management
    ├── session.py        # Session management tools
    ├── stats_helpers.py  # Shared statistical math utilities (incl. Holt-Winters, IQR, MAD)
    ├── topology_analysis.py  # Blast radius analysis
    ├── websites.py       # Website CRUD
    ├── workflows.py      # Composite workflow tools (triage, health_check, etc.)
    ├── metric_presets.py # Metric-type presets for auto-configuration
    └── ...               # Additional tool modules

examples/playbooks/
├── lm-remediate-disk-cleanup.yml
├── lm-remediate-service-restart.yml
├── lm-remediate-log-rotate.yml
└── lm-remediate-memory-cache-clear.yml

deploy/
├── Dockerfile            # Production Docker image
├── docker-compose.yml    # Full stack deployment
├── Caddyfile             # TLS proxy configuration
└── .env.example          # Environment template

トラブルシューティング

Claude Codeで「Failed to connect」と表示される

claude mcp list に ✗ Failed to connect と表示される場合、サーバーに環境変数が設定されていません。サーバーを追加する際に、-e フラグを含める必要があります。

# Remove the broken config
claude mcp remove logicmonitor

# Re-add with environment variables
claude mcp add logicmonitor \
  -e LM_PORTAL=yourcompany.logicmonitor.com \
  -e LM_BEARER_TOKEN=<your-bearer-token> \
  -- uvx --from lm-mcp lm-mcp-server

注記： シェルまたは .env ファイルに環境変数を設定しても機能しません。Claude Codeは独自の環境を持つサブプロセスとしてMCPサーバーを起動するためです。

「Write operations are disabled」と表示される

書き込み操作（確認、SDTの作成など）は、デフォルトで無効になっています。環境に LM_ENABLE_WRITE_OPERATIONS=true を設定してください。

Claude Desktopで「spawn uvx ENOENT」と表示される

Claude Desktopが uvx を見つけられません。フルパスを使用してください。

{
  "command": "/Users/yourname/.local/bin/uvx",
  "args": ["--from", "lm-mcp", "lm-mcp-server"]
}

which uvx を実行してuvxのパスを確認してください。

取り込みAPIのエラー

ingest_logs ツールと push_metrics ツールには、LMv1認証が必要です。ベアラートークンは取り込みAPIでは機能しません。設定に LM_ACCESS_ID と LM_ACCESS_KEY を追加してください。

レート制限エラー

サーバーは、レート制限されたリクエストを指数バックオフで自動的に再試行します。制限に繰り返し達する場合は、リクエストの頻度を下げるか、LogicMonitorサポートにお問い合わせください。

認証エラー

ベアラートークンが正しく、適切な権限を持っていることを確認してください。APIトークンはLogicMonitorの Settings → Users and Roles → API Tokens で管理できます。

ライセンス

MITライセンス - LICENSEファイルを参照してください。