Lawang Onboard について
Lawang Onboardは、IBM Bobを使うエンジニア向けの権限対応型コードベースオンボーディングMCPサーバーです。役割に応じてコードや履歴を絞り込み、引用付きの説明と非表示情報の記録を提供します。
主な機能
- 01役割とスコープによるフィルタリング
- 02コードと履歴の検索
- 03モジュールマップと機能の追跡
- 04設計判断とレビューの説明
- 05セットアップガイドと着手タスク
- 06非表示項目のレポート
活用シーン
- 01新しいエンジニアのコードベース理解
- 02コード内での機能の流れの追跡
- 03コードパスの背景にある判断の確認
- 04新しいコントリビューター向けタスクの選定
MCP 対応
stdioまたはstreamable HTTPで、MCPクライアントに9つのツールを提供します。Bearer tokenが呼び出し元の役割とスコープを決め、モデルに渡す前に情報をフィルタリングします。
設定
リモートサーバーはインストール不要です。クライアントを選んで設定をコピーするか、ワンクリックで導入できます。
https://lawang-onboard.samsulhadi.com/mcpclaude mcp add --transport http gablooge-lawang-onboard https://lawang-onboard.samsulhadi.com/mcp{"mcpServers":{"gablooge-lawang-onboard":{"type":"http","url":"https://lawang-onboard.samsulhadi.com/mcp"}}}Cursor で開く{"servers":{"gablooge-lawang-onboard":{"type":"http","url":"https://lawang-onboard.samsulhadi.com/mcp"}}}VS Code で開く{"mcpServers":{"gablooge-lawang-onboard":{"type":"http","url":"https://lawang-onboard.samsulhadi.com/mcp"}}}{"mcpServers":{"gablooge-lawang-onboard":{"serverUrl":"https://lawang-onboard.samsulhadi.com/mcp"}}}コマンドはターミナルで実行し、JSON は各クライアントの MCP 設定に貼り付けて再起動します。認可が必要なサーバーは初回接続時にログインを求めます。
https://lawang-onboard.samsulhadi.com/mcp認証が必要ghcr.io/gablooge/lawang-onboard:0.1.1stdioツール
詳細
Lawang Onboard

権限を考慮した AI オンボーディング。 IBM Bob 内で動作するオンボーディングコパイロットです。新しいエンジニアにコードベースを説明し、閲覧を許可された範囲だけを見せます。
IBM Bob 2.0 Hackathon(lablab.ai、2026 年 9 月 25 日~27 日)向けに、チーム Lawang Onboard が開発しました。
課題
新しいエンジニアや、特定のモジュールを担当するために採用された契約社員が、コードベースが今のような構成になった理由を理解するには、何週間もかかります。答えはコミットメッセージ、アーキテクチャ決定記録、プルリクエストのレビューなどに散在していますが、初日からそれらを読む人はいません。アクセス権もすべて許可するか、すべて拒否するかの二択です。新しいメンバーは、AI アシスタントがコンテキストに取り込める情報を含めてすべてを見られるか、誰かから説明を受けるまで待つしかありません。
できること
IBM Bob でリポジトリを開き、Onboard モードに切り替えて質問します。
/tour:モジュールごとに、閲覧できる範囲を示すマップです。/trace webhook:webhook がどのようにレコードになるのかを、順を追って説明します。/why internal/ingress:そのパスに関する決定やレビューを説明します。- 「最初に何を担当できますか?」
Bob はコードとその履歴をもとに回答し、使用したすべての項目を引用します。コンテキストの各要素にはスコープがあり、エンジニアのロールはスコープのセットに対応します。そのロールは接続時のトークンから取得され、Lawang Onboard MCP サーバーはモデルが情報を見る前にフィルタリングします。契約社員のセッションから、最初から与えられていない情報が漏れることはありません。また、すべての回答の末尾に、非表示にした情報を記載します。
Withheld: path:cmd (68), path:internal/core (314), path:migrations (56), path:repo (86),
private:growth (18), private:security (6) | total hidden: 399
| 契約社員 | メンテナー |
|---|---|
![]() | ![]() |
結果
2026 年 9 月 26 日に契約社員ロールで測定しました。質問ごとに Bob の新しいタスクを 1 つ実行し、サーバーを開発していないチームメンバーが測定しました。詳細な報告:docs/benchmark.md。
| 結果 | |
|---|---|
| オンボーディングに関する 10 個の質問 | 10 問中 10 問正解。回答あたり平均 36 秒、0.16 Bobcoins |
| 手作業での回答との比較 | 3 問で 46 秒対 210 秒。うち 1 問は手作業では回答できませんでした |
情報漏えいテスト(プロンプトインジェクション、直接の get、別のロールだと偽る、検索、「推測」) | 5 件すべて阻止。ロールのスコープ外の情報はモデルに届きませんでした |
| Bob によるコードレビュー | 実際の問題を 2 件検出(認証されていないデモ API、get による存在確認オラクル)。どちらも修正し、再確認済み |
| 非表示件数 | 毎回、roles.yaml とコーパスに基づく独立した再集計と一致 |
| 情報漏えいテスト | 11 個のテスト関数を 3 つすべてのロールで実行し、仕込んだインジェクション項目もテスト。CI で go test -race ./... を実行 |
仕組み
IBM Bob (Onboard mode: rules, skills, slash commands)
| MCP over stdio or HTTPS, bearer token
v
onboard server (Go)
token -> role -> scopes -> one filter function -> tools -> audit log
|
corpus/*.jsonl (610 items: files, docs, ADRs, commits, PRs, reviews, issues, each with scopes)
- スコープは
roles.yamlで定義します。パスの glob(最初に一致したものを適用)、ラベル(growthラベルが付いた issue は非公開になります)、種別があります。各項目には、その項目が必要とするすべてのスコープが必要です。スコープのない項目は、誰にも表示されません。 - ツール:
whoami、map_system、search、get、trace_feature、why、setup_guide、starter_tasks、withheld。各ツールはまずフィルタリングを行い、閲覧できる項目だけを使って回答を作成します。非表示の ID と存在しない ID には、同じ回答を返します。 - Onboard モードでは MCP ツールとスキルのみを使用でき、ファイルシステムにはアクセスできません。そのため Bob がコードを見る方法は、フィルタリング済みの情報だけです。ルールでは、最初に
whoamiを呼び出すこと、項目 ID を引用すること、コーパスのテキストをデータとして扱うこと、提案には提案であると明記すること、最後に Withheld 行を付けることを定めています。 - トークンは一定時間で比較し、不明、空、または曖昧なトークンは拒否します。デモページの API でも同じトークンを使います。
設計メモ:docs/design.md。
試す
- ライブデモ: https://lawang-onboard.samsulhadi.com(ロールトークンを貼り付けると、そのロールから見える内容を確認できます)。
- クライアントを接続: IBM Bob、Claude Code、Cursor、VS Code を以下に設定しています。公開イメージを介した stdio 接続、またはホストされたサーバーを介した HTTPS 接続が可能です。
MCP クライアントを接続する
server.json では2つの接続方法が定義されており、どちらを使っても9つのツールは同じです。
| トランスポート | アドレス | 必要なもの |
|---|---|---|
| stdio | -stdio を指定して実行するイメージ ghcr.io/gablooge/lawang-onboard:0.1.1 | Dockerと、自分で決めるシークレット |
| streamable-http | https://lawang-onboard.samsulhadi.com/mcp | サーバー運用者から提供されるロールトークン |
0.1.1 はプルするタグです。イメージ内のバイナリは引き続き 0.1.0 を serverInfo.version として報告するため、クライアントにはその値が表示される場合があります。stdioでは、あなたが運用者です。任意のシークレットを選んで1つのロールに割り当て、ONBOARD_TOKEN に同じ値を設定します。どのロールを選ぶかで表示内容が決まり、イメージにはLawangのデモコーパスが含まれているため、ほかに設定するものはありません。HTTPSではトークンをこちらで用意するため、必要な場合はお問い合わせください。
コミットするファイルにシークレットを含めないでください。以下のBob、Claude Code、Cursorの設定例は環境変数から読み取るため、クライアントを起動する前に環境変数をエクスポートしてください。以下のVS Codeの設定例は環境変数を読み取らず、代わりにVS Codeが一度だけ入力を求めます。2つの値は意図的に同じです。一方はロールを指定し、もう一方はこのクライアントがどのロールを名乗るかを示します。
read -rs ONBOARD_TOKEN && export ONBOARD_TOKEN # typed, so it stays out of your shell history
export ONBOARD_TOKEN_CONTRACTOR="$ONBOARD_TOKEN"
次に、使用するクライアントを選びます。各設定例には、参照元のドキュメントと、そのページを確認した日付が記載されています。これらのクライアントは設定形式が変更されるため、設定例が動作しない場合はページを確認してください。
IBM Bob
stdioを使うローカルサーバーの場合は .bob/mcp.example.json を .bob/mcp.json にコピーし、ホストされたサーバーの場合は .bob/mcp.remote.example.json をコピーして、トークンを設定します。その後、MCP サーバーを再読み込みし、Onboard モードに切り替えて /tour と入力してください。どちらのファイルにもトークンがそのまま記載されますが、.gitignore によってGitの対象外になります。ローカルの場合、これは「ローカルで実行する」に記載された手順が想定する形式です。scripts/use-role.py がトークンをそのファイルの env オブジェクトに書き込みます。リモートの場合は env オブジェクトがなく、スクリプトも変更しないため、自分でトークンを headers に貼り付けます。以下の設定例では、代わりにトークンを環境変数に格納します。
公開イメージをstdioで使用する場合(Goツールチェーンは不要です):
{
"mcpServers": {
"lawang-onboard": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "ONBOARD_TOKEN", "-e", "ONBOARD_TOKEN_CONTRACTOR",
"ghcr.io/gablooge/lawang-onboard:0.1.1", "-stdio"],
"env": {
"ONBOARD_TOKEN": "${env:ONBOARD_TOKEN}",
"ONBOARD_TOKEN_CONTRACTOR": "${env:ONBOARD_TOKEN_CONTRACTOR}"
}
}
}
}
これならファイルには変数名だけが記載され、シークレットが含まれることはありません。その背景にあるBobの仕様を3点紹介します。これは2026年10月12日時点(同じMCPクライアントを搭載するBob IDE 2.2.1およびBob Shell 2.0.5)で確認したものです。
- Bobは
${env:NAME}を自身の環境変数から展開します。envとheadersで動作を確認しており、argsもエントリー内で同じ方法で処理されます。${NAME}のようにenv:を省略すると展開されず、その文字列がそのまま渡されます。古いメモから${VAR}をコピーする前に知っておくとよいでしょう。 envオブジェクトは実際に機能します。Bobはstdioサーバーに、固定の許可リスト(HOME、LOGNAME、PATH、SHELL、TERM、USER)とエントリー独自のenvのみを渡し、それ以外は渡しません。そのため、-e ONBOARD_TOKENだけでは何も渡されず、イメージはonboard: ONBOARD_TOKEN is not setと表示して終了します。両方の部分を指定してください。- Bobを起動する前に環境変数をエクスポートしてください。別のターミナルで後から設定しても、すでに起動しているBobには反映されません。
Claude Code
claude mcp add のリファレンスに記載されている2つのコマンドです(2026年10月12日閲覧)。--env の値とヘッダーの値は、サーバーの起動時に環境変数から展開されるため、設定に書き込まれるのはシークレットそのものではなく ${...} のテキストです。-- 以降は変更されずにサーバーに渡されます。そのため、docker run のフラグをそのまま使えます。
イメージを使った stdio 接続:
claude mcp add --env 'ONBOARD_TOKEN=${ONBOARD_TOKEN}' \
--env 'ONBOARD_TOKEN_CONTRACTOR=${ONBOARD_TOKEN_CONTRACTOR}' --transport stdio lawang-onboard \
-- docker run -i --rm -e ONBOARD_TOKEN -e ONBOARD_TOKEN_CONTRACTOR \
ghcr.io/gablooge/lawang-onboard:0.1.1 -stdio
ホスト型サーバーを使った HTTPS 接続:
claude mcp add --transport http lawang-onboard https://lawang-onboard.samsulhadi.com/mcp \
--header 'Authorization: Bearer ${ONBOARD_TOKEN}'
どちらもローカルスコープに書き込まれるため、このプロジェクトでのみ有効です。すべてのプロジェクトで使うには、--scope user を追加してください。シングルクォートが重要です。シェルによってトークンが展開され、保存されるコマンドに含まれるのを防ぎます。CLI 2.1.293 でデフォルトのスコープを確認したところ、エントリーはこのプロジェクトのパスの下にある ~/.claude.json に保存され、${...} のテキストがそのまま記録されました。また、変数をエクスポートした状態では claude mcp list に Connected と表示され、エクスポートしていない状態では、不足している変数名とともに Failed to connect と表示されました。
HTTPS のエントリーについて、知っておくべき見落としやすい失敗が1つあります。「空として読み取られる認証情報変数」の項目には、一部の認証情報らしい名前は、リモートサーバーの url と headers で展開されず、空として読み取られると記載されています。名前の一覧ではなく、例を挙げた3つのカテゴリが示されており、それらに該当しない名前は記述どおりに展開されると説明されています。ONBOARD_TOKEN は該当せず、受信したヘッダーを記録するローカルエンドポイントを使って測定したところ、CLI 2.1.293 では展開されました。値が空として読み取られると、ヘッダーは Bearer のみで送信され、このサーバーは 401 を返します。手早く確認するには claude mcp list を使ってください。変数名を特定するには、claude --debug-file /tmp/claude-debug.log を実行し、"never expanded toward a remote server" を検索します。
Cursor
プロジェクト内の .cursor/mcp.json、またはすべてのプロジェクトで使う場合は ~/.cursor/mcp.json の mcpServers に記述します。Cursor は command、args、env、url、headers 内の ${env:NAME} を解決します。Cursor の MCP ドキュメントより(2026年10月12日閲覧)。
イメージを使った stdio 接続です。このページの stdio フィールドの表では、type は必須で値は "stdio" とされていますが、stdio の例には記載されていません。そのため、このスニペットでは表に従っています。
{
"mcpServers": {
"lawang-onboard": {
"type": "stdio",
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "ONBOARD_TOKEN", "-e", "ONBOARD_TOKEN_CONTRACTOR",
"ghcr.io/gablooge/lawang-onboard:0.1.1", "-stdio"],
"env": {
"ONBOARD_TOKEN": "${env:ONBOARD_TOKEN}",
"ONBOARD_TOKEN_CONTRACTOR": "${env:ONBOARD_TOKEN_CONTRACTOR}"
}
}
}
}
ホスト型サーバーを使った HTTPS 接続:
{
"mcpServers": {
"lawang-onboard": {
"url": "https://lawang-onboard.samsulhadi.com/mcp",
"headers": { "Authorization": "Bearer ${env:ONBOARD_TOKEN}" }
}
}
}
リモートエントリーは url と任意の headers で構成されます。ドキュメントにはトランスポートフィールドが記載されておらず、Cursor がストリーミング可能な HTTP を自動的に判断します。
VS Code
ワークスペース内の .vscode/mcp.json、またはユーザープロファイル内の同じファイルの servers に記述します。MCP 設定リファレンスに記載されているフィールドと変数(2026年10月12日閲覧)は、stdio では type、command、args、env、envFile、リモートサーバーでは type、url、headers です。このページには ${input:id} と ${workspaceFolder} の説明はありますが、${env:NAME} の説明はありません。そのため、トークンは inputs エントリーから取得します。VS Code は初回使用時に一度だけ入力を求め、その後のために保存します。ここでは、エクスポート済みの環境変数は読み取られません。
イメージを使った stdio 接続:
{
"inputs": [
{
"type": "promptString",
"id": "onboard-token",
"description": "Lawang Onboard role token",
"password": true
}
],
"servers": {
"lawang-onboard": {
"type": "stdio",
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "ONBOARD_TOKEN", "-e", "ONBOARD_TOKEN_CONTRACTOR",
"ghcr.io/gablooge/lawang-onboard:0.1.1", "-stdio"],
"env": {
"ONBOARD_TOKEN": "${input:onboard-token}",
"ONBOARD_TOKEN_CONTRACTOR": "${input:onboard-token}"
}
}
}
}
ホスト型サーバーを使った HTTPS 接続です。上のブロックにある inputs 配列をファイルに残してください。このエントリーだけでは ${input:onboard-token} が未解決のままになり、VS Code が設定を拒否します。
{
"servers": {
"lawang-onboard": {
"type": "http",
"url": "https://lawang-onboard.samsulhadi.com/mcp",
"headers": { "Authorization": "Bearer ${input:onboard-token}" }
}
}
}
同じページでは、ワークスペースのルートに配置するポータブルな .mcp.json についても説明されています。このファイルでは servers の代わりに mcpServers を使い、上記の Bob と Cursor のブロックと同じ形式です。code --add-mcp コマンドは別のページである VS Code の MCP サーバーに記載されています(2026年10月12日閲覧)。その例では、エスケープした二重引用符を使った JSON 引数を1つ渡し、name、command、args のみを扱っています。そのため、env または headers を含むエントリーにはファイルを使ってください。
このサーバーは MCP Registry にも io.github.gablooge/lawang-onboard として登録されています。
Bob でのみ得られるもの
9 つのツールは、どのクライアントでも同じです。異なるのは、それらを取り巻くガイダンスです。オンボードモードのルール、4 つのスキル(tour、trace、why、first-week)、および 3 つのスラッシュコマンドは、Bob 独自の形式で .bob/ に保存されており、このサーバーはまだそれらを MCP 経由で提供していません。そのため、このサーバーに接続した Claude Code、Cursor、または VS Code のユーザーは、9 つのツールを利用できますが、残りのガイダンスは自分で補う必要があります。最初の呼び出しは whoami にすること、ツアーではこのロールから閲覧できるモジュールをすべて対象にし、結果を統合すること、すべての主張に項目 ID を付けること、回答の末尾に Withheld 行を付けることなどです。これらのクライアントも、フィルター済みコーパスを使ってオンボーディングの質問に回答し、ツール呼び出しには Bob とまったく同じフィルターを適用します(下記の制限を参照)。ただし、ツアーをツアーとして実行するわけではありません。プロトコルにはこのガイダンスを提供する仕組みがありますが、ここでは何も登録されていません。公開済みイメージに対して prompts/list を実行すると、空のリストが返されます。4 つのスキルを MCP プロンプトとして提供し、どのクライアントからでも呼び出せるようにすることが、PLAN.md で未完了の唯一の P2 項目です。
明確にしておくべき制限が 1 つあります。これは設定で解決できるものではありません。このサーバーがモデルにとって唯一のコード参照手段である間だけ、フィルターは有効です。 Bob のオンボードモードはファイルシステムにアクセスできないよう設定されているため、モデルが参照できるのはフィルター済みコーパスだけです。Claude Code、Cursor、VS Code はデフォルトで作業ツリーを読み取るため、ファイルを開けるモデルはそのファイルをこちらに要求する必要がありません。チェックアウトされているファイルも、roles.yaml の内容も、すべてモデルに見えてしまいます。こちらが提供するものによってこの動作が変わることはなく、こちら側のオプションで変更することもできません。あるロールから見えるものを確認したい場合は、ファイルアクセスのないクライアントやモードから接続するか、クローンのないマシンから接続してください。それ以外の場合、差し控え件数が示すのはコーパスの内容であり、それは依然として正しいものの、ディスクの内容ではありません。
ローカルで実行する
Go 1.25 が必要です。
cp .env.example .env # set the three role tokens
cp .bob/mcp.example.json .bob/mcp.json
scripts/use-role.py contractor # writes that role's token into .bob/mcp.json
IBM Bob でフォルダーを開き、MCP サーバーを再読み込みして、オンボードモードを選択して質問してください。Bob はサーバーを stdio 経由で起動します。
ウェブページと HTTP エンドポイントを使う場合:
set -a; . ./.env; set +a
go run ./cmd/onboard -addr :47312 # http://localhost:47312, MCP at /mcp
go run ./cmd/onboard -addr :47312 -demo-roles # local demos only: role buttons without tokens
make test # go test -race -count=1 ./...
ホスティング(Docker と Cloudflare Tunnel、make up):docs/deploy.md。
Go ツールチェーンをまったく使わない場合は、公開済みイメージを実行してください。MCP クライアントを接続するの各クライアント向けのコード例が、その方法を示しています。
独自のリポジトリで使う
デモはLawangについて回答しますが、サーバー自体にLawang固有の要素はありません。読み込むのはコーパスとロールファイルだけです。エクスポートにはPython 3とgit、サーバーにはGo 1.25またはDockerが必要です。以下のコマンドはすべて、このリポジトリのクローン内で実行し、作成したものはすべてgitが無視するlocal/の下に置きます。
-
エクスポート。 ローカルのリポジトリクローンを指定します。
make corpus REPO=../myrepo GITHUB=me/myrepo OUT=local/corpusクローンからファイル、ドキュメント、コミットを、GitHubからプルリクエスト、レビュー、イシューを書き出します(公開リポジトリではトークンは不要です。非公開リポジトリまたは大規模なリポジトリの場合は
GITHUB_TOKENを設定してください)。GITHUB=の後に何も指定しないと、GitHubをスキップし、ネットワーク呼び出しを行いません。組織が所有するリポジトリの場合は、スクリプトを直接実行して--owner <your login>を追加してください。エクスポートで削除されるものと、削除されないもの。 固定リストにある形式のトークン(GitHub、Slack、AWSのキーID、Stripe、Google、GitLab、npm、JWT、ベアラー値、PEM秘密鍵)、URL内のパスワード、設定ファイルでキー名が
password、secret、tokenまたはapi_keyで終わる場合に同じ行にあるリテラル値を置換します。ただし、その値が変数名(DB_PASSWORD_VAR)または参照(var.db_password)のように見える場合は除きます。コミットメッセージとGitHubのテキストでは、メールアドレスとIPアドレスも置換し、所有者とボット以外のすべての作成者を<user>として記録します。シンボリックリンク、ロックファイル、ミニファイ済みファイル、node_modules、vendor、third_party、名前にsecret、credentialまたはpasswを含む設定ファイルは除外します。 削除されないもの:コミットやプルリクエストのテキストに書かれた@mentionsや名前、ログイン名を含むGitHubのnoreplyアドレス、認識できない形式のシークレット、中立的なキー名で保存されたシークレット、ソースコード内で代入されたシークレット(.pyファイル内のPASSWORD = "..."など)です。したがって、これは網羅的な保証ではなく、あくまで一種の網です。件数は表示され、local/corpus/manifest.jsonに保存されます。共有する前にコーパスを確認してください。未加工のGitHubの応答は一切サニタイズされず、コーパスと並んでlocal/.corpus-raw/にキャッシュされます。このディレクトリはgitで自動的に無視され、マウントも提供もされません。 -
誰が何を見られるかを指定します。
cp roles.example.yaml local/roles.yamlディレクトリ構成に合わせてglobを編集してください。すべての行にコメントがあります。テンプレートのままでは、一覧に記載し忘れたディレクトリはメンテナーロールにのみ表示されます。他のロールの対象範囲に、最後のルールのスコープ(
unlisted:repo)を含めない限り、この設定が維持されます。そうしない場合に何が変わるかは、ファイルのヘッダーに記載されています。 -
実行。 各ロールにはトークンが必要です。
token_envで指定された環境変数に設定してください。トークンがない場合でもページは読み込まれますが、すべての呼び出しが401を返します。cp .env.example .env # then set ONBOARD_TOKEN_MAINTAINER, _EMPLOYEE and _CONTRACTORGoを使う場合:
set -a; . ./.env; set +a go run ./cmd/onboard -addr :47312 -corpus local/corpus -roles local/roles.yamlまたは公開済みのイメージを使い、デモの設定に重ねて両方をマウントします。
docker run --rm -p 47312:47312 --env-file .env \ -v "$PWD/local/corpus:/app/corpus:ro" -v "$PWD/local/roles.yaml:/app/roles.yaml:ro" \ ghcr.io/gablooge/lawang-onboard:0.1.1MCPエンドポイントは
http://localhost:47312/mcp、ページは/です。stdioの場合は、MCPクライアントを接続するにあるクライアントのdocker runエントリーを使い、引数に2つの-vマウントを追加して、絶対パスを指定してください(シェルがないため、$PWDは展開されません)。-pは不要です。
利用できる機能は、リポジトリの内容によって異なります。ツアー、検索、get、trace_feature、whyはどのエクスポートでも動作します。setup_guideはREADME、Makefile、.github/workflows/を読み込みます。starter_tasksにはGitHubのイシューとlabel_areasエントリーが必要です。
IBM Bob の使用方法
IBM Bob は、製品のランタイムであると同時に、それを構築したツールでもあります。Onboard モード、そのルール、
4 つのスキル(tour、trace、first-week、why)、および 3 つのスラッシュコマンドがユーザーインターフェースです。Plan モードでサーバーを設計し、Agent モードですべてのコードとテストを作成し、Ask モードで情報漏えいがないか確認し、Onboard モードでベンチマークを実行しました。Bob のタスクは 36 件、チームの Bobcoin 80 枚のうち 46.6 枚を使用しました。すべてのタスクのスクリーンショットは bob_sessions/ にあり、台帳にも記録されています(Samsul、Ryan)。詳細と、Bob の外で行った作業については、docs/submission/bob-usage.md をご覧ください。
データとプライバシー
DATA_SOURCES.md と PRIVACY.md をご覧ください。デモ用コーパスにはチーム独自のオープンソースリポジトリ、 gablooge/lawang を使用しています。クライアント、機密情報、個人情報、ソーシャルメディアのデータは使用していません。 役割は合成データです。
チーム
- Samsul Hadi(リード)
- Ryan Rizki
ライセンス
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。

