ooligo
mcp-server

Claude向けWorkable MCPサーバー

Difficulty
中級
Setup time
90min
For
recruiter · recruiting-ops · talent-acquisition · recruiting-engineer
Recruiting & TA

Stack

Workablehttps://mcp.workable.com/mcp で自社の Model Context Protocol サーバーをホストしています。つまり「自分で作るか」という問いはすでに決着済みで、接続するだけです。残る問いは、94 個あるツールのうちどれをリクルーターのアシスタントに触らせるか、です。Workable は 2026-05-13 に 38 ツールでサーバーを公開し、2026-07-20 に 94 ツールへ拡張しました。この拡張で、パフォーマンスレビュー、アカウントと権限の管理、候補者プロフィールの更新に書き込みアクセスが加わりました。apps/web/public/artifacts/mcp-server-workable-recruiting/ のアーティファクトバンドルがその問いへの答えです。最小権限のゲートウェイ (README.mdpyproject.tomlsrc/workable_gateway/policy.pysrc/workable_gateway/server.py) で、33 ツールを素通しし、13 ツールを人間による 2 段階承認の後ろに置き、残る 48 ツールを拒否します。

使うべき場面

リクルーターがすでに Claude で隣接する作業 — アウトバウンドの下書き、スコアカードの要約、採用マネージャー向けの報告 — をしていて、それでも「この候補者は今どのステージか」「今週動いていない応募はどれか」「この req の面接ループには誰が入っているか」を確認するために Workable へ戻り続けているなら、ホスト版サーバーをすぐ接続してください。接続はコマンド 1 つで、費用はかかりません。Workable は MCP サーバーを全サブスクリプションプランに追加料金なしで含めています。

その上にゲートウェイを重ねるのは、許可リストを中央で効かせる必要があるときです。リクルーター個人の settings.json は本人のマシン上でクライアントが適用するもので、本人が編集できます。ゲートウェイのプロセスは recruiting-ops が一度だけ適用します。これを動かすかどうかが、方針と好みの差です。必要になる規模は、1 つの Workable アカウントを共有する 5 人以上のリクルーティングチームで、「アシスタントがユーザーを無効化してよいと誰が決めたのか」といずれ誰かが尋ねる組織です。

使うべきでない場面

クライアント側がすでにコネクター単位でツールを制限していて、使う人を信頼できるなら、ゲートウェイは飛ばしてください。サーバーは飛ばしません。Claude Code は MCP ツールを mcp__<server>__<tool> として扱い、settings.jsonpermissions.deny を尊重します。バンドルには同じポリシーをその形式で表現した claude-code-permissions.example.json が入っており、同じ policy.py から生成しています。インフラ費用はゼロで、最初の一手としてはこれが正解です。ゲートウェイに進むのは、レスポンスのマスキング、中央の監査ログ、特定の引数に紐づいた承認トークンが要るときだけです。この 3 つはクライアント側の deny list では得られません。

Workable アカウントが採用だけでなく人事の記録システムでもあるなら、このワークフロー全体を飛ばしてください。Workable のサーバーは候補者と同じエンドポイントから、従業員、休暇、勤怠、パフォーマンスレビューの全サイクルまでカバーします。そのアカウントに接続したアシスタントは、止める仕組みがなければ get_employee_documents 経由で雇用契約書に、get_timeoff_balances 経由で欠勤記録に到達します。この判断の責任者がまだ決まっていないなら、先に リクルーティング向け AI ポリシー を承認してください。

リクルーターが 1 人だけでチーム全体という場合も飛ばしてください。その規模ならホスト版コネクター単体で足ります。ゲートウェイの導入とポリシーレビューはおよそ 1 営業日の作業で、まだ誰も求めていないガバナンスを買うことになります。

導入

完全な手順は apps/web/public/artifacts/mcp-server-workable-recruiting/README.md にあります。短くまとめると、pip install -e . を実行し、WORKABLE_ACCOUNT に Workable のサブドメインを設定し、絶対パスでゲートウェイを登録し、初回呼び出し時にブラウザーで認可します。Workable のサーバーは RFC 8414 の認可サーバーメタデータを公開し、RFC 7591 の動的クライアント登録を受け付けるため、手作業で用意する client ID もローテーションする API key もありません。

本当に重要なのはその前の段階です。どの Workable メンバーとして認可するかを決めてください。MCP セッションはサインインしたユーザーのロールと担当求人をそのまま引き継ぎます。Workable 自身の表現では、AI はそのユーザーがすでに閲覧を許可されているデータしか読めず、操作もできません。権限モデルのように聞こえますが、これを最初に導入するのが誰かを考えてください。recruiting-ops のリードは管理者です。自分のアカウントで認可すればゲートウェイに管理者スコープを渡すことになり、残る壁は許可リストだけになります。代わりに、権限セットを絞った専用の Workable メンバーを作ってください。get_permission_sets がアカウントに定義済みのものを一覧します。

何を遮断するか

src/workable_gateway/policy.py が 94 ツールを 3 段階とマスキング対象リストに振り分けます。段階判定はデフォルト拒否です。だからこそ、Workable が 2026-07-20 の 1 回のリリースで追加した 37 ツールは、人間が分類するまで暗いままになります。9 週間で 65% 増えた表面に対しては、これが望ましい挙動です。

48 ツールは即座に拒否します。理由ごとに 6 グループです。メンバー管理の 4 ツールは、権限セットを付与できるエージェントが次のセッションで自分の到達範囲を広げられるため外します。部門の 4 ツールは、merge_department に逆操作がなく、リクルーティングのレポートが部門で切られているため外します。誤った統合はエラーを出さずにファネルの履歴を書き換えます。承認系の 5 ツール — オファー、requisition、休暇 — は、承認が名前のある個人による権限行使であり、委譲すると「人が決めた」という証跡が消えるため外します。勤怠の 6 ツールは給与に隣接しており、bulk_create_time_entries は 1 回の誤った推論を大量の給与誤りに変えるため外します。パフォーマンスレビューの 15 ツールは submit_review が確定操作だからです。Workable のドキュメントは 2 回目の送信が失敗すると記しており、タイムアウトした呼び出しをエージェントが再試行することがまさにその危険です。HRIS の読み取り 14 ツールは、従業員文書に契約書、報酬通知書、ビザや医療の書類が入っているため外します。

13 ツールは承認ゲートの後ろに置きます。候補者と requisition への書き込みで、move_candidatedisqualify_candidate から create_requisition までです。_gateway_confirm なしで呼ぶと、書き込みではなく dry run が返ります。その dry run の _gateway_token はツール名と厳密な引数のハッシュなので、「候補者 41 を Onsite へ移動」の承認を「候補者 88 を Offer へ移動」として再利用することはできません。

33 ツールは素通しです。読み取り 32 個に加えて add_comment — 追記型で、誰の操作か追跡でき、Workable の画面から削除できる唯一の書き込みです。それに加えて server.py が独自ツールを 3 つ定義します。workable_policy_report は、拒否された呼び出しが再試行ループではなく「それはブロックされています、Workable の画面で行ってください」という応答になるためのものです。workable_pipeline_snapshot は、ステージ別件数と停滞している候補者を 1 回のページング走査で返します。workable_stage_move_review は候補者の現在のステージを解決し、リクルーターが依頼ではなく差分を承認できるようにします。

設計上の判断

アカウントはモデルに選ばせず固定する。 get_accounts 以外のすべての Workable ツールは account サブドメインを受け取ります。2 つのアカウント — 本番のブランドともう 1 つ、あるいはサンドボックス — にアクセスできるユーザーは、間違ったテナントから自信ありげで正しそうな答えを受け取ります。ゲートウェイは転送するすべての呼び出しに WORKABLE_ACCOUNT を注入し、モデルが別の値を入れた呼び出しを拒否します。アカウントが 2 つなら、ゲートウェイのプロセスも 2 つです。

429 での再試行ではなくトークンバケット。 Workable の OAuth 2.0 バケットは 10 秒あたり 50 リクエストで、超えると X-Rate-Limit-Reset 付きの HTTP 429 を返します。「公開中の全求人の候補者を全部見せて」という質問は get_jobs と req ごとのページング get_candidates に展開され、およそ 2 秒でそれを使い切ります。その後で再試行するアシスタントは同じ壁に真っすぐ突っ込みます。WORKABLE_RATE_PER_SEC のデフォルトは 4/s で、持続レートの 5/s を下回り、同じトークンを使うテナント内の他の処理に余裕を残します。

ステージごとの呼び出しではなく 1 回の走査。 workable_pipeline_snapshot は候補者を 1 度だけページングし、行からステージを集計します。上限は WORKABLE_PAGE_CAP(5 ページ、500 候補者)です。求人のステージが 4 でも 14 でもコストは一定で、レスポンスに page_cap_reached を立てるので、部分的な件数はモデルが部分的だと伝えられます。

マスキングはリクエストだけでなくレスポンスにも。 search_employees を塞いでも、get_candidate が EEO レポート用に収集している自己申告フィールドを返すのは止まりません。policy.REDACT_FIELDS はキー名で再帰的にフィールドを空にします。Workable は候補者の詳細を入れ子にし、詳細検索の行を独自のキーの下に返すからです。

実際のコスト

サーバー自体は $0 です。Workable の公開時と拡張時のアナウンスはどちらも、全サブスクリプションプランに追加料金なしで含まれると述べています。ただし Advanced Search の 3 ツールは Premier+ と Enterprise プラン限定です。ここが面白い数字で、Workable は自社製品内の AI をクレジットで課金しています。現在公開されているバンドルは 5,000 クレジットで $600、10,000 で $1,000、50,000 で $4,750 — 1 クレジットあたり $0.095 から $0.12 です。Workable の AI に質問するとクレジットを消費します。MCP サーバー経由で Claude に質問すると Anthropic のトークンを消費し、Workable のクレジットはゼロです。すでに Claude のシートを払っているチームにとって、リクルーティングの Q&A をこの線の向こう側へ動かすのは実質的な移転であり、差し引きゼロではありません。

その代わりに払うもの: ゲートウェイの導入と初回検証におよそ 90 分、そしてポリシーレビューは 3 時間近くになります。人事データの判断を持つ人を巻き込むためです。直接コネクターだけならコマンド 1 つ、10 分ほどです。

失敗モード

拒否された書き込みを、通る言い回しが見つかるまでアシスタントが再試行する。 ガード: モデルが段階を名指しして止まれるように workable_policy_report を用意し、拒否メッセージは代替ツールを提案せず Workable の画面を指します。試してください。README のステップ 3 はアシスタントにメンバーの無効化を依頼し、試行ではなく拒否が返ることを期待します。

古い承認が別の引数に対して再利用される。 ガード: _gateway_token はツール名だけでなく引数もハッシュします。dry run の後で候補者 ID を書き換えるとトークンは無効になり、承認をやり直すことになります。

マスキングがカスタムフィールドを取りこぼす。 policy.py のフィールド一覧は汎用的なもので、自己申告の属性はアカウントごとに異なります。ガード: README の TODO リストの項目 1 が、get_account_custom_attributesget_candidate_detailed_fields で実際の属性キーを取得することです。本番アカウントに接続する前に行ってください。それが済むまで、マスキングは未検証のものとして扱ってください。

履歴書とメモが第三者に届く。 get_candidate_files は ALLOW 段階に置いています。履歴書を読むことこそが業務だからです。その結果、GDPR と CCPA の対象データが Anthropic を経由します。ガード: AI ポリシーの承認と、その流れを明記した処理活動の記録です。誰かに問われた後ではなく、コネクターを稼働させる前に行ってください。

挙げるべき代替案

分かりやすい比較対象は Greenhouse の MCP ワークフロー のパターンで、あちらはベンダーがホストしていないためバンドル自体がサーバーです。ここでのトレードオフはそれではありません。Workable の REST API の上に自前サーバーを作るのは、94 個のエンドポイントを再実装し、OAuth フローを自分で抱えて、無料の一次提供物と競うということです。やめてください。

比較検討に値するのはブローカーです。Composio と Zapier はどちらもホスト版の Workable MCP エンドポイントを掲載しており、どちらも OAuth トークンを保持する 2 社目のベンダーを経路に置き、タスク単位またはシート単位の独自価格が乗ります。他のコネクターですでにそこに標準化しているときだけ選んでください。そうでなければ順位はこうです。大半のチームには Workable のホスト版サーバーとクライアント側の deny rules、許可リストをリクルーターが編集できない場所で効かせる必要があるならホスト版サーバーとこのゲートウェイ。この線がどこに引かれるかの背景は、MCP の書き込みアクセスと付与の判断MCP サーバー解説 を参照してください。

Files in this artifact

Download all (.zip)