ステータス: 実験的。本番システムに対して使用する場合は注意してください。

ABAP ADT MCP サーバー

ADT（ABAP Development Tools）を介してSAP ABAPシステムへの完全な読み書きアクセスをAIエージェントに提供するMCPサーバーです。認証にはSPNEGO/Kerberosシングルサインオン、X.509クライアント証明書、またはOAuth 2.0ベアラートークンを使用し、設定にパスワードは一切含めません。ユーザー名とパスワードによるフォールバックも引き続き利用できますが、推奨されません。

abap-adt-apiをラップし、ADT自体にはないRFC対応ファンクションモジュールの呼び出しをSAP Gateway JSON-RPC 2.0サービス経由で追加します。

128のツール — オブジェクトCRUD、ソース編集、ロック、トランスポート、有効化、構文チェック、コード補完、ABAPユニット、ATC、DDIC、abapGit、リファクタリング、トレース、デバッガ、RFC呼び出し。

クライアントが実際に表示する数は、2つの点でより少なくなります。プロファイル（ABAP_MCP_PROFILE）は、コンテキストの代わりにサーフェスを提供します。coreは9ツール、allは129ツールを一覧表示します。これは、オンデマンドでツールスキーマを取得できないクライアントの場合、毎ターン約2,700トークンに対して約17,800トークンになります。また、サーバーは何かを一覧表示する前にシステムが何をサポートしているかを問い合わせるため、abapGitプラグインがないリリースでは、400を返す10のツールが提供されることはありません。DEVでは116が残ります。

これは、mario-andreschakによるmcp-abap-abap-adt-apiのSSOフォークです。主な違いは、Basic認証の代わりのKerberos SSO、JSON-RPC/RFCツール、ツール定義から派生したルーター、そして文書化されたツールリファレンスです。

ドキュメント

Related MCP server: ABAP-ADT-API MCP-Server

機能

• 2つのパスワードレスログオンモード — ログオン中のWindowsユーザーのチケットを使用したSPNEGO/Kerberos、またはKerberos IDを持たないサービスユーザーまたはテクニカルユーザー向けのX.509クライアント証明書。どちらの場合もSAPパスワードは保存も送信もされず、セッションの有効期限が切れると自動的に復旧します。

• 名前によるオブジェクトの読み取り — readAbapObjectは、1回の呼び出しで名前をソースに解決します。ADT URLを検出したり手動で作成したりする必要はありません。

• テーブルの説明 — describeAbapTableは、フィールド、DDICタイプ、キーフラグ、チェックテーブルを返します。

• オブジェクト管理 — ABAPオブジェクトの検索、読み取り、作成、変更、削除、有効化。

• 命名規則の調査 — searchPackagesは、パターン（["ZPP_*","Z_PP*"]）でパッケージを検索し、各パッケージをタイプごとにグループ化されたオブジェクトに1回の呼び出しで展開します。

• ソースワークフロー — ロック → 編集 → 構文チェック → 有効化 → ロック解除。トランスポート処理付き。

• コードインテリジェンス — 補完、定義、使用箇所参照、ABAP Doc、プリティプリンター、ATC、ABAPユニット、リファクタリング（名前変更、メソッド抽出）。

• RFCファンクションモジュールの呼び出し — callFunctionViaJsonRpcは、RFC対応ファンクションモジュールを実行し、システムから読み取った実際のシグネチャに対してリクエストを検証します。

• 単一LUWでのRFCバッチ呼び出し — callFunctionsViaJsonRpcは、複数のファンクションモジュールを単一のリクエストで送信します。これにより、更新BAPIとそのBAPI_TRANSACTION_COMMITが1つのLUWを共有できます。

• データアクセス — tableContentsとアドホックなrunQuery SELECT。

• 実行中システムの表示 — listLoggedOnUsersはTH_USER_LIST（SM04の背後にあるデータ）から「誰がログオンしているか」に応答し、readProfileParametersはRZ11値を1ラウンドトリップで読み取り、checkLogonConfigurationはシステムが実際に受け入れる認証を通知します。

• バンドルされたエージェントスキル — skills/の下にある54のスキル。ABAP（Clean ABAP、RAP、CDS、ATC、abapGit…）と一般的なエンジニアリング（TDD、コードレビュー、バグ診断）用で、リソースとして、またreadSkillを介して提供されます。

• 自己文書化 — 以下のガイドは、MCPリソース（abap-adt://guides/…）およびreadServerGuideツールを介してサーバー自体によって提供されるため、エージェントはセッションを離れることなく、ワークフローや引数をタスクの途中で調べることができます。

前提条件

• ADT経由で到達可能なSAP ABAPシステム。 /sap/bc/adtがSICFでアクティブである必要があります。RFCツールの場合、/sap/gw/jsonrpcもアクティブである必要があり（SAP_GWFND）、ユーザーには呼び出すファンクショングループのS_RFCが必要です。

• パスワードなしでログオンする方法。次のいずれか：

  • 動作するKerberosログイン — SAPシステムがSPNEGOを受け入れ、有効なチケット（klist）を保持している必要があります。これがデフォルトであり、出荷時の状態ではWindowsが必要です。ブートストラップはC:\Windows\System32\curl.exe --negotiateをシェルアウトします。これにはcurlのSchannel/SSPIバックエンドが必要です。他のプラットフォームでは、SSO_CURL_PATHをGSS-APIサポート付きでビルドされたcurlを指すように設定します。

  • X.509クライアント証明書 — Kerberos IDを持たないサービスユーザーまたはテクニカルユーザー向け。curlもWindowsも必要ありません。SAP側の設定が必要です：ICMポートが証明書を要求する必要があり（icm/server_port_<n>のVCLIENT。これはicm/HTTPS/verify_clientをオーバーライドします）、発行元CAがSTRUSTで信頼され、CERTRULEがユーザーにマッピングされている必要があります。完全なセットアップ（このサーバーからそれらを確認する方法を含む）はdocs/Authentication.mdにあります。

  • OAuth 2.0クライアント — KerberosレルムもICMも設定する必要のないSAP BTP ABAP環境、またはSOAUTH2を介してADTを公開するオンプレミスシステム向け。BTPサービスキーはすでにその1つです。§11を参照してください。

• Node.js（LTS）とnpm — node -vとnpm -vで確認します。

インストール

git clone --recurse-submodules https://github.com/Ciltress/sap-abap-mcp.git
cd sap-abap-mcp
npm install
npm run build

--recurse-submodulesは重要です。一般的なエンジニアリングスキルはサブモジュールにあり、これがないとそのディレクトリは空になり、サーバーが提供するスキルが35つ少なくなります。すでにクローンしましたか？ git submodule update --init --recursiveを実行してください。

npmのnpx mcp-abap-abap-adt-apiパッケージはアップストリームサーバーであり、SSOブートストラップやRFCツールは含まれません。代わりに、このリポジトリをソースからビルドしてください。

設定

.env.exampleを.envにコピーし、システム情報を入力します：

SAP_URL=https://your-sap-server.example.com:44301
SAP_USER=YOUR_SAP_USER
SAP_CLIENT=100
SAP_LANGUAGE=EN

SAP_URLとSAP_USERは必須です。SAP_CLIENTとSAP_LANGUAGEはオプションですが推奨されます。4つのログオンモードのうち3つは、SAP_PASSWORDを一切必要としません。

.envをコミットしないでください。すでに.gitignoreに含まれています。

クライアントに合わせたサーバーのサイジング

3つのABAP_MCP_*変数が存在する理由は1つだけです：オンデマンドでツールスキーマを取得できないクライアントは、毎ターン、ツールリスト全体のコストを支払うことになります。 Claude Codeはスキーマを遅延取得するため、デフォルトのままにしておく必要があります。128kウィンドウの8Bモデルは、会話が始まる前にコンテキストの6分の1を消費しており、それが「同じプロンプトが半分しか機能しない」理由です。

ABAP_MCP_PROFILE — 未設定の場合はallと見なされるため、既存のセットアップは変更されません。

件数にはhealthcheckが含まれます。healthcheckは「どのプロファイルで実行中か」に答えるツールであるため、すべてのプロファイルの外側にあります。

プロファイルは利便性のためのフィルタではありません。アクティブなプロファイルに含まれないツールはリストに表示されずかつルーティングもされないため、呼び出すことができません。つまりanalystは、メニューが小さいというだけでなく、ソースを編集するものが何もないことを保証するものです。プロファイル外の呼び出しは「不明なツール」ではなく、その旨を伝えるエラーになるため、再試行しても意味がありません。認識されないプロファイル名は、allにフォールバックするのではなく、起動時にサーバーを停止させます。9を要求したものに129のツールを黙って提供することは、プロファイルが存在するまさにその防止したい障害です。

coreが小さいのは、1つのツールeditAbapSourceが書き込みサイクルそのものです: ロック、書き込み、アクティベート、ロック解除。ステップが失敗してもロックは解放されます。4つの個別ステップはdevとallに残ります。

ABAP_MCP_MAX_RESPONSE_BYTES — ツールリストはプロファイルが縮小できる固定コストですが、回答は無制限です。coreではツールリスト全体が約11KBであるのに対し、adtDiscovery1件は約42KBです。未設定の場合はプロファイルに従います(core 24,000バイト、analyst 32,000、dev 48,000、allは上限なし)。0で無効になります。

予算を超えた回答は保留され、有効なJSONに置き換えられます — status:"truncated"、元のbytes、budget、2,000バイトのpreview、そしてnextStepです。解析できない切断された断片に置き換えられることは決してありません。そのような断片はパースできず、同じ再試行を招くだけだからです。

ABAP_MCP_GATE — サーバーは何かをリストする前に、システムが何をサポートしているかを問い合わせ、ADTコレクションが存在しないツールを除外します。DEVでは、それは10個のabapGitツールと3個のサービスバインディングツールで、これらはそうしないとHTTP 400を返すことになります。プロセスごとに1回のディスカバリの往復を要し、リストを短くすることしかできず、失敗した場合はすべてのツールがリストされたままになります。ABAP_MCP_GATE=offでスキップされます。

healthcheckは、アクティブなプロファイル、responseBudgetBytes、および除外されたものをすべて報告します。

Kerberosの代わりに証明書

サービスユーザーまたは技術ユーザーの場合は、証明書を追加します — それだけでモードが切り替わります:

SAP_USER=CLAUDEAGENT                                 # the user CERTRULE maps the certificate to
SAP_CERT_FILE=C:\Users\svc_agent\SNC\sec\claudeagent.p12
SAP_CERT_PASSPHRASE=<PKCS#12 password / PSE PIN>

これは相互TLSであり、SNCではありません — ADTはHTTPSです。RFC/SNCですでに動作している証明書は再利用でき、そのCERTRULEマッピングも引き継がれますが、SNC0 ACLは関与せず、ICMにはicm/HTTPS/verify_clientが必要です。docs/Authentication.mdでは、その違い、sapgenpse export_p12 / OpenSSL 3の落とし穴、拒否された証明書の読み方について説明しています。

BTPおよびSOAUTH2向けのOAuth 2.0クライアント

SAP BTP ABAP環境、または認可サーバーの背後でADTを公開するオンプレミスシステム向けです。クライアントIDを設定するとモードが切り替わります:

SAP_OAUTH_TOKEN_URL=https://your-tenant.authentication.eu10.hana.ondemand.com/oauth/token
SAP_OAUTH_CLIENT_ID=sb-abap-agent!t1234              # 'clientid' in a BTP service key
SAP_OAUTH_CLIENT_SECRET=<'clientsecret'>

オンプレミスの場合、エンドポイントはSAPホスト自体にあります — https://<host>:<port>/sap/bc/sec/oauth2/token — そしてクライアントはSOAUTH2に登録されているものです。

トークンは一度だけログオンします。 その後は、他のモードと同様に、SAPセッションCookieがすべてのリクエストを運びます — つまり、5分で期限切れになるトークンでも問題ありません。AS ABAP上のOAuth 2.0クライアントはSU01のユーザーであることに注意してください: 誤ったSAP_OAUTH_CLIENT_SECRETはパスワードと同様にlogin/fails_to_user_lockにカウントされるため、拒否されたトークン要求は決して再試行されません。認可コードフローは実装されていません — ブラウザが必要であり、stdioで起動されたサーバーにはブラウザを開く方法がないためです。一度手動で完了させ、リフレッシュトークンを渡してください。docs/Authentication.md §11に詳細があります。どの失敗がラッチされ、その理由も含めて。

他に何もない場合のパスワード

Kerberosも証明書もないシステム向け — サンドボックス、トライアル、ドメイン外の何か:

SAP_USER=CLAUDEAGENT
SAP_PASSWORD=<the password>

最後の手段であり、他の2つと交換可能ではありません。 チケットがない、またはマッピングされていない証明書は単に拒否されます。誤ったパスワードはlogin/fails_to_user_lockにカウントされ、このサーバーだけでなく、そのユーザーを使用するすべてのコンシューマーに対してユーザーをロックします。実装はそのため、拒否されたパスワードの再試行を拒否します — 呼び出されるツールがいくつであっても、1回の失敗したログオンがラッチされます。無人運転には証明書を推奨します。docs/Authentication.md §10に詳細があります。

MCPクライアントに登録する

クライアントにビルド済みエントリポイントを絶対パスで指定します:

{
  "mcpServers": {
    "sap-abap-dev-100": {
      "command": "node",
      "args": ["C:/path/to/sap-abap-mcp/dist/index.js"],
      "env": {
        "SAP_URL": "https://your-sap-server.example.com:44301",
        "SAP_USER": "YOUR_SAP_USER",
        "SAP_SYSTEM_ID": "DEV",
        "SAP_CLIENT": "100",
        "SAP_LANGUAGE": "EN"
      }
    }
  }
}

クライアントのenvブロックは.envより優先されます。npm run startを実行してサーバーを手動で起動するか、npm run devを実行してMCP Inspector経由で操作します。

毎ターンすべてのツールスキーマを運ぶクライアントの場合は、同じブロックにプロファイルを追加します:

"env": { "…": "…", "ABAP_MCP_PROFILE": "core" }

Dockerの場合

サーバーはstdioを介してMCPを話すため、公開するポートはありません — クライアントがコンテナを起動し、stdin/stdoutを介して通信します。

docker build -t abap-adt-mcp .

{
  "mcpServers": {
    "sap-abap-dev-100": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "--env-file", "C:/path/to/.env", "abap-adt-mcp"]
    }
  }
}

4つのログオンモードはすべてここで動作しますが、資格情報はコンテナに与えられなければならないものであり、--env-fileはdotenvではありません — Dockerは引用符を削除せず、exportを読み取らず、末尾の# commentも削除しないため、dotenvなら除去していた値がそのまま届きます。.env内のWindowsパスは、マウントされたパスに置き換える必要があります。Kerberosはコンテナから最も多くのものを必要とするモードで、OAuthは最も少なくて済みます: トークンはネットワーク経由で取得されるため、何もマウントする必要がありません。

証明書モード — キーマテリアルを読み取り専用でマウントし、SAPの証明書に署名するCAも一緒にマウントします:

docker run -i --rm --env-file .env \
  -v /host/certs:/certs:ro \
  -e SAP_CERT_FILE=/certs/agent.p12 \
  -e SAP_CA_FILE=/certs/corporate-root.pem \
  abap-adt-mcp

Kerberosモード — イメージにはGSS-APIとkinitに対してビルドされたcurlが含まれているため、残るのはレルムと資格情報です:

docker run -i --rm --env-file .env \
  -v /etc/krb5.conf:/etc/krb5.conf:ro \
  -v /host/agent.keytab:/krb5/agent.keytab:ro \
  -e SAP_KRB_KEYTAB=/krb5/agent.keytab \
  -e SAP_KRB_PRINCIPAL=SVC_AGENT@CORP.EXAMPLE.COM \
  abap-adt-mcp

OAuth 2.0モード — マウントするものはありません。資格情報は取得されます:

docker run -i --rm --env-file .env \
  -e SAP_OAUTH_TOKEN_URL=https://your-tenant.authentication.eu10.hana.ondemand.com/oauth/token \
  -e SAP_OAUTH_CLIENT_ID='sb-abap-agent!t1234' \
  -e SAP_OAUTH_CLIENT_SECRET=<clientsecret> \
  abap-adt-mcp

パスワードモード — 最後の手段!

docker run -i --rm --env-file .env \
  -e SAP_USER=YourUser \
  -e SAP_PASSWORD=YourPassword \ 
  abap-adt-mcp

それに手を伸ばす前に知っておくべき3つのこと:

• キータブであって、自分のチケットではない。 コンテナは、対話型ログオンが行うようにセッションの資格情報を借用できません。Linuxホストでは、すでに持っているチケットキャッシュをマウントできます(-v /tmp/krb5cc_1000:/krb5/ccache:ro -e KRB5CCNAME=FILE:/krb5/ccache)が、ホストのものと一緒に期限切れになります。Windowsホストからはどちらも機能しません: TGTはLSAキャッシュに存在し、ファイルに書き出すことができないためです — これが一切不要な証明書モードを使用してください。キータブは、無人で実行できる唯一の資格情報であり、チケットの有効期間を超えて存続する唯一のものです。

• SAPの証明書を検証するか、検証していないことを認識してください。 イメージはパブリックCAバンドルのみを信頼するため、ホストが信頼する内部CAはここでは不明であり、ハンドシェイクはUNABLE_TO_GET_ISSUER_CERT_LOCALLYで失敗します。ルートCAをマウントし、SAP_CA_FILEをそれに向けてください。デスクトップの.envを丸ごと持ち込むと、代わりにこれを隠してしまいます: NODE_TLS_REJECT_UNAUTHORIZED=0は開発用設定であり、デプロイされたイメージにあるべきものではありません。

• --recurse-submodulesクローンからビルドしてください。 skills/Developmentはサブモジュールです。これがないと、イメージには35個少ないスキルが同梱されます。

イメージがAlpineではなくDebianなのには1つの理由があります: AlpineのcurlはGSS-APIなしでビルドされており、そのようなcurlは失敗しません — 単にトークンを送信しないだけで、SAPは期限切れチケットと同じ401を返します。何が欠けているかは、セッションが試行される前に、起動時にstderrで示されます。コンテナに最終的にどの資格情報になったかを尋ねるには、サーバーの代わりにコマンドを与えます:

docker run --rm --env-file .env -v /host/agent.keytab:/krb5/agent.keytab:ro \
  -e SAP_KRB_KEYTAB=/krb5/agent.keytab abap-adt-mcp klist

docs/、skills/、AGENTS.mdは意図的にイメージにコピーされます — サーバーは実行時にこれらを読み取ってreadServerGuide、readSkill、abap-adt://リソースを提供します。docs/Authentication.md §7に、モードごとの完全なコンテナ設定があります。

複数のシステム

サーバーはその生涯を通じて1つのシステムと1つのクライアントにバインドされます — どちらも実行時に切り替えることはできません。したがって、システム/クライアントごとに1つのエントリを登録し、それぞれにSAP_SYSTEM_IDを指定します:

"sap-abap-dev-100": { "env": { "SAP_SYSTEM_ID": "DEV", "SAP_CLIENT": "100", "…": "…" } },
"sap-abap-dev-200": { "env": { "SAP_SYSTEM_ID": "DEV", "SAP_CLIENT": "200", "…": "…" } },
"sap-abap-q01-100": { "env": { "SAP_SYSTEM_ID": "Q01", "SAP_CLIENT": "100", "…": "…" } }

各サーバーは、接続時に返すMCP instructionsで自身を宣言します:

このサーバーはSAPシステムDEV、クライアント100 (https://…:44301) にバインドされています。 実行時にシステムやクライアントを切り替えることはできません — どちらも起動時の環境によって固定されています。リクエストが別のシステムやクライアントを指定している場合は、そのために設定されたMCPサーバーを使用してください。登録されていない場合は、ここで動作するのではなく、その旨を伝えてください。

これにより、エージェントは「DEVクライアント200でこれを確認してください」というリクエストを、何も呼び出さずに正しいサーバーにルーティングできます。healthcheckは、直接問い合わせる必要があるサーバーに対して同じIDを報告します。

宣言はチェックされます。 SAPはログオン時に設定するセッションCookie (SAP_SESSIONID_DEV_100) にシステムとクライアントを指定するため、サーバーは実際に接続されている先を認識します。それがSAP_SYSTEM_IDと一致しない場合 — たとえば、間違ったホストを指すコピー＆ペーストされたエントリ — healthcheckはWARNINGを保持し、起動時に大声でログに記録されます。注意に値します。なぜなら、すべてのツールが引き続き完璧に動作するからです。ただ、間違ったシステム上で動作しているだけです。

クイックツアー

任意のオブジェクトを名前で読み取ります — URLディスカバリは不要です:

{"tool":"readAbapObject","args":{"objectName":"ZCL_MY_CLASS"}}
{"tool":"describeAbapTable","args":{"tableName":"T000"}}

命名規則全体を調査します — パターンは自動的に正規化されるため、zpp_labはZPP_LAB*になります:

{"tool":"searchPackages","args":{"patterns":["ZPP_*","Z_PP*"]}}
// -> each package with its objects grouped by type, sub-packages, and a `truncated` flag

ファンクションモジュールを呼び出します — 最初にシグネチャが読み取られ、リクエストはそれに対して検証されます:

{"tool":"readAbapFunctionModule","args":{"functionModuleName":"STFC_CONNECTION"}}
{"tool":"callFunctionViaJsonRpc","args":{"functionModuleName":"STFC_CONNECTION",
                                         "inputParameters":{"REQUTEXT":"hello"}}}

BAPIとそのコミットは1つのバッチで移動する必要があります。そうしないと、コミットは独自のLUWに置かれ、BAPIの変更は失われます:

{"tool":"callFunctionsViaJsonRpc","args":{"calls":[
  {"functionModuleName":"BAPI_USER_LOCK","inputParameters":{"USERNAME":"DEVUSER"}},
  {"functionModuleName":"BAPI_TRANSACTION_COMMIT","inputParameters":{"WAIT":"X"}}
]}}

完全な書き込みサイクル(ロック → 変更 → チェック → アクティベート → ロック解除)、デバッガ、ATC、その他すべてのワークフローはdocs/MCP-Tools.md §4にあります。

ABAPオブジェクトを操作する

3つのツールで必要なもののほとんどをカバーでき、それぞれがADT URLではなく名前を受け取ります:

{"tool":"readAbapObject",   "args":{"objectName":"ZCL_MY_CLASS"}}
{"tool":"describeAbapTable","args":{"tableName":"T000"}}
{"tool":"searchPackages",   "args":{"patterns":["ZPP_*","Z_PP*"]}}

readAbapObject は、メタデータ と ソースを一度の呼び出しで返します。名前が複数のオブジェクトに属する場合 — ZPP_EXT_LABEL_DATA は関数グループと関数モジュールの両方です — より具体的な方を選択し、ambiguous:true と alternatives で通知します。objectType を渡すと選択肢を強制できます。ソースを持たないオブジェクトは、hasSource:false と適切なツールへのポインタを返します。

describeAbapTable は、フィールド名、DDIC型、長さ、キーフラグ、データ要素、ドメイン、チェックテーブルを返します。チェックテーブルは外部キー参照先であり、2つのテーブルがどのように結合するかを確認する最も手軽な方法です。objectStructure はテーブルに対してフィールドを返さず、tableContents は定義ではなく行を返すため、どちらも「このテーブルはどのような定義か」という問いに答えません。

クライアントのシステムプロンプトに入れておく価値のあるルール

• 名前指定ツールを優先する。 中間結果が必要な場合のみ、searchObject → objectStructure → getObjectSource にフォールバックする。/sap/bc/adt/... パスを手作りしてはならない。

• 効率的に選択する。 SAP のテーブルは大きい。SELECT は常に WHERE 句で制約し、すべてのキーフィールドが既知の場合は SELECT SINGLE、それ以外の場合は UP TO n ROWS を使用する。

SELECT vgbel FROM vbrp WHERE vbeln = @lv_vbeln INTO @DATA(lv_vgbel) UP TO 1 ROWS.
  EXIT.
ENDSELECT.

SAP はファイルシステムから切り離されています。ソースを読み取っても、それはツール結果として返されるだけであり、ローカルファイルに書き込んでも SAP 側では何も変わりません。ローカルコピーは差分確認に役立つだけで、それ以上でもそれ以下でもありません。

以前の README には GetTable, GetStructure、GetTypeInfo が列挙されていました。これらはこのサーバーではなく、別の mcp-abap-adt プロジェクトに属します。

開発

npm run build          # tsc -> dist/
npm test               # jest: parser, tool catalogue, JSON-RPC handler (no SAP system needed)
npx tsc --noEmit       # type check only

テストは src/__tests__ に置かれ、完全にオフラインで実行されます — JSON-RPCスイートは、疑似 SAP Gateway ノードに対してハンドラをエンドツーエンドでテストします。

実際のシステム（Kerberos チケットが必要）では、エンドツーエンドの確認は次のとおりです。

npm run build
node scripts/live-jsonrpc-check.mjs      # add NODE_TLS_REJECT_UNAUTHORIZED=0 for an internal CA

これは、クライアントとまったく同様に、ビルド済みサーバーを MCP stdio 経由で駆動し、読み取り専用のファンクションモジュールのみを呼び出します。

ツールの追加は1ファイルの変更だけで済みます。docs/MCP-Tools.md §10 を参照してください。

トラブルシューティング

詳細は docs/MCP-Tools.md §8 を参照してください。

コントリビューション

1. リポジトリをフォークする

2. git checkout -b feature/your-feature-name

3. 変更を行い、npm test と npx tsc --noEmit を成功した状態に保つ

4. git commit -m "Add some feature" と git push origin feature/your-feature-name を実行する

5. プルリクエストを開く

ライセンス

MIT ライセンスです。アップストリームプロジェクトと原作者: mario-andreschak。