Skip to main content
Glama
deenesjakoruzh
jnot807

Juicebox MCP

by jnot807
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Juicebox MCP

Juicebox のソーシングデータを Claude に読み込むローカル MCP サーバー — 保存済み検索とそのスコアリング結果を、ログイン済みの自分の Juicebox セッションを使って読み取ります。

完全に自分のマシン上で動作します。セッションが外部に出ることはなく、すべての呼び出しは自分自身として、自分のシート上で実行されます。

読み取りはエクスポートクレジットを消費しません。 読み取りツールが返すものはすべて、検索結果ページがすでに描画しているのと同じ無料のサーフェスから取得されます。書き込みを行うツールは 1 つだけで、その旨が明記されています: jb_run_search はワークスペースに実際の保存済み検索を作成します。

インストール

オプション A — デスクトップ拡張機能（最も簡単）

Releases から juicebox-mcp.mcpb をダウンロードし、ダブルクリックするか、Claude Desktop → 設定 → 拡張機能 にドラッグ＆ドロップします。

貼り付ける API キーはありません。インストール後、以下の一度だけのブラウザ手順を実行してください。

オプション B — ソースから

git clone https://github.com/jnot807/juicebox-mcp.git
cd juicebox-mcp
npm install          # also downloads the Chromium build (see note)
npm run login        # a real browser opens — sign in to Juicebox yourself
npm run check        # proves the session works headless

次に Claude Code に登録します:

claude mcp add -s user juicebox -- node "$(pwd)/server.js"

-s user を付けるとすべてのセッションで利用可能になります。付けない場合、登録は実行したディレクトリに限定されます。

一度だけのブラウザダウンロード

これは実際の Chromium を駆動するもので、そのバイナリは node_modules の一部ではありません — 共有キャッシュ（macOS では ~/Library/Caches/ms-playwright）への約 500MB の一度きりのダウンロードです。

npm install は postinstall ステップで自動的に取得します。デスクトップ拡張機能のユーザーは手動で一度実行する必要があります。拡張機能には node_modules は同梱されますが、そのキャッシュは同梱されないためです:

npx patchright install chromium

これがない場合、サーバーは実行ファイルが見つからないというスタックトレースを投げるのではなく、平易な言葉でその旨を伝えます。

サインイン

認証はキーではなく、実際のサインインです。npm run login でブラウザウィンドウが開きます。通常どおり Juicebox にサインインしてください。セッションはその後 session/（gitignore 済み、chmod 600）に保存され、ヘッドレスで再利用されます。

npm run check が失敗し始めたら、再度サインインしてください — セッションは期限切れになります。

Related MCP server: JobSpy MCP Server

ツール

ツール

機能

jb_list_searches(projectId?)

プロジェクトの保存済み検索（id + 名前）。

jb_get_results(searchId, limit?, minMatchRate?)

検索のランク付けされた候補 — 名前、LinkedIn URL、役職、会社、所在地、matchRate、基準ごとの判定、および描画されたカードから読み取った日付付きの experience[] + education。1 回の呼び出しで最大約 500 件。

jb_count(queryInput, searchId?)

検索を実行せずにフィルターセットの規模を測る — チューニングの基本プリミティブ。queryInput は収穫したテンプレートに対する PATCH です。レスポンスの noEffect を確認してください。

jb_run_search(prompt, need?)

書き込みを行います。 自然言語プロンプトから新しい検索を作成・実行し、その候補を返します。ワークスペース全体から見える保存済み検索が残るため、使用前に確認してください。

experience[] は過去の雇用主を見る唯一の方法です。API ペイロードは現在のものしか保持しないため、対象企業の出身者はこれなしでは見えません。

デフォルトで読み取るプロジェクト

ハードコードされたものはありません。サインイン時にプローブが /projects を読み込み、これは自分のシートが見えるプロジェクトへリダイレクトされ、その id が session/session-meta.json の defaultProjectId として保存されます。

これは一度だけ書き込まれ、その後は放置されます。リダイレクトはアプリが最後に開いていたプロジェクトに従うため、毎回それを信頼すると、projectId なしのツール呼び出しが昨日とは異なるプロジェクトを読むことになります。

解決順序:

  1. JUICEBOX_PROJECT_ID（環境変数 — デスクトップ拡張機能のオプションの「デフォルトプロジェクト」フィールドが設定するもの）

  2. JUICEBOX_VALIDATOR_PROJECT（環境変数 — 認証チェックもそのプロジェクトに固定します）

  3. session/session-meta.json の defaultProjectId（ディスカバリーで設定）

すべてのツールは明示的な projectId も受け取り、これが常に優先されます。

Juicebox のプロジェクト id は c5PheL2fANnX6uBQVUdo のような約 20 文字のキーです — URL の /project/<id>/ の部分です。UUID を渡すと、存在しないプロジェクトへ黙って移動するのではなく、説明付きでサーバーが拒否します。

ツールが備える 2 つのルール

  • verdictFound: false → unknown、決して否定ではありません。 「証拠が見つからない」と「証拠がノーと言っている」は異なる判定です。これらを同一視すると、実際には誰も確認できなかった基準で候補のスコアが下がります。

  • 広いスキル用語はランキングを薄めます。 スキルは OR 重み付けです。カスタマーサクセス検索での「Account Management」のような人口全体にわたる用語は、プールを約 3.4 倍に膨らませます。一般的な用語を落とし、1 つの必須要件をスキルフィルターに昇格させてください。

サーバー稼働中にスクリプトを実行する

ブラウザプロファイルを共有することはできません: session/profile/ は単一書き込み者であり、MCP サーバーは稼働中は常にそれを保持します。それを開こうとする 2 番目のプロセスは認証チェックに失敗します — これは「セッション期限切れ」として報告され、再ログインを繰り返す堂々巡りに陥ります。

診断には、チェックポイントから新しいコンテキストを構築してください。ロックなし、同じセッション:

const { chromium } = require('patchright');
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({ storageState: 'session/storage-state.json' });

仕組みと落とし穴

結果ページは初回読み込み時にサーバーサイドレンダリングされるため、/api/profiles/results は操作時にのみ発火します。クライアントはページャーを微調整してアプリ自身にリクエストを発行させ、その後レスポンスをキャプチャします — これには表示中のページだけでなく、ランク付けされたセット全体が含まれます。

client.js を編集する人を噛むであろう 3 つの点:

  1. addInitScript は絶対に使わないでください。 Patchright は検出対策としてこれを黙って no-op にします — エラーもなく、スクリプトが実行されないだけです。page.on('response') を使用してください。

  2. API の linkedin_url は暗号化されています（hex:hex）、profiles[].url と profileDetails.id も同様です。実際の URL は描画されたカードから取得され、正規化された full_name で結合されます — ライブ検索で 100% と測定されています。

  3. ページネーション途中でリストが空白になります。 null のページャー読み取りは「まだ移動中」を意味し、「失敗」ではありません。遷移中にページャー変更検出に何かをゲートすることは、以前の 2 つのバグの原因です。

壊れたとき

これは Juicebox の内部 API に依存しています。安定性の契約はなく、予告なく変更される可能性があります。

  • npm run check が失敗 → セッション期限切れ: npm run login。

  • サーバーが Chromium がないと言う → npx patchright install chromium。

  • jb_get_results が source: "dom-fallback" を返す → API キャプチャが壊れました。matchRate と基準が失われます。RESULTS_PATH がまだ一致するか確認してください。

  • jb_get_results が joinedLinkedInUrls: 0 を報告する → カードのマークアップが変更されました。harvestCards / rewindToFirstPage を見直してください。

  • 検索リストが空 → プロジェクトページのマークアップが変更されました。listSavedSearches を参照してください。

要件

  • Node.js 18 以降

  • サインインできる Juicebox アカウント

  • Chromium ダウンロード用に約 500MB の空きディスク

ライセンス

MIT。Juicebox とは提携しておらず、Juicebox による承認も受けていません。

Available Tools

4 tools
jb_countA

Size a filter set WITHOUT running a search — the tuning primitive. Free and side-effect free, so permute filters and compare before committing to a run. The endpoint is VERIFIED DETERMINISTIC (same body, same count on repeat), which is what makes the comparisons below trustworthy.

queryInput is a PATCH, not a whole body. It is merged over a ~164-key template harvested live from a saved search, because a PARTIAL body does not error — it returns result:0, which reads exactly like "nobody matches your filters". Pass only the keys you want to change. Use searchId to choose which saved search supplies the template; the response echoes baseline (the unpatched count).

ALWAYS CHECK noEffect IN THE RESPONSE. Unrecognised keys and wrong value shapes are dropped SILENTLY, so an unchanged count means the key name is probably wrong, NOT that the filter does not matter. Measured example: coSizes (company headcount) is ignored in all eight shapes tried, including [{name:"51-200"}], ["51-200"], [{title,tag}] and [{min,max}]. Its real shape is still unknown — set the filter in the Juicebox UI and capture the request before trusting it.

SOME FILTERS EXPAND RATHER THAN RESTRICT, which is the opposite of the intuition and was measured on one search (baseline 1413): dropping industries gives 1387 and dropping coTags gives 1247 — REMOVING them SHRINKS the pool, so they act as OR-expanders and cannot be used to narrow onto a category. An unrecognised industry ("mining & metals") returns the same 1387 as an empty list. What actually restricts: skills (removing all four widened 1413 to 4526), yearsOfExp (20 gives 881), selectedLocs, and criteria. Note this REVISES the older claim that broad skill terms widen the pool — specific skills restrict hard, broad ones merely fail to restrict. The practical rule is unchanged: drop skill terms that describe the whole population, and promote the ONE hard requirement to a skill (e.g. "AI Agents", not prose about being AI-first).

NameRequiredDescriptionDefault
searchIdNoSaved search to harvest the template from (from jb_list_searches). Defaults to the first saved search on the project. Pick the one whose titles/locations you want as your starting point.
projectIdNoJuicebox project id — a ~20-character key like c5PheL2fANnX6uBQVUdo, taken from the /project/<id>/ part of a Juicebox URL. Optional: omit it to use the default project discovered at sign-in.
queryInputYesPATCH over the harvested template — only the keys you are changing. Verified keys: jobTitles[{title,tag}], pastJobTitles, skills[{title,tag}], industries[{name}], coTags[{title,name,tag}], selectedLocs[{name,country,continent,type,...}], selectedCos, timezones, revenueRanges, fundingStages, yearsOfExp (number), criteria[{text,id}], excludeDncCountries (bool), coSizes (present but IGNORED in every shape tried).

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the entire behavioral burden, and it excels. It reveals that the endpoint is deterministic, that partial bodies are silently merged over a template, that unrecognized keys are dropped silently, and that filter behavior can be counterintuitive (some expand rather than restrict). It even provides measured examples showing how to detect silent failures via the noEffect flag. This is exemplary transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but every sentence carries critical, non-redundant information. It front-loads the core purpose and safety properties, then layers in warnings and measured data. No filler or repetition exists; each paragraph adds actionable knowledge an agent needs to use the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (nested objects, no output schema) and the absence of annotations, this description is remarkably complete. It covers expected behavior, failure modes (silent drops, noEffect), practical examples, and even guidance on filter semantics that only become apparent through experimentation. An agent has everything it needs to call this tool correctly and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already describes each parameter, the description adds value by clarifying that queryInput is a PATCH over a template, enumerating the verified key shapes (e.g., 'skills[{title,tag}]'), and explicitly flagging coSizes as ignored in every tested shape. It also explains how searchId selects the template and the meaning of the echoed 'baseline.' This goes well beyond the schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and object: 'Size a filter set WITHOUT running a search — the tuning primitive.' This immediately distinguishes it from running a search and states its role as a sizing/measurement tool. It also explicitly contrasts with the sibling jb_run_search by saying 'before committing to a run,' leaving no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance ('permute filters and compare before committing to a run') and explains the side-effect-free nature that makes this safe for experimentation. It also instructs on selecting the saved search template via searchId and warns about the partial-body PATCH semantics. This is far more than typical usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jb_get_resultsA

Pull a saved search's ranked candidates — up to ~500 in one call. Returns name, LinkedIn URL, title, company, location, a numeric matchRate (0-100, banded) and per-criterion verdicts. Costs NO export credits: this is the same free surface the results page renders.

READING THE RESULTS: at the top of a ranked list every candidate meets every criterion, so criteria-met count does NOT discriminate up there — use matchRate and depth. A criterion with verdictFound=false is reported as result "unknown": that means no evidence was found, NOT that the candidate fails it. Never treat an unknown as a negative.

If the search has never been executed, this errors — open it in the app and press "Run search" once.

NameRequiredDescriptionDefault
limitNoMax candidates to return (default 50, max 500).
searchIdYesSaved search id from jb_list_searches.
projectIdNoJuicebox project id — a ~20-character key like c5PheL2fANnX6uBQVUdo, taken from the /project/<id>/ part of a Juicebox URL. Optional: omit it to use the default project discovered at sign-in.
minMatchRateNoOnly return candidates at or above this matchRate.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the free/costless nature, the exact return data, the significance of verdictFound=false ('not a negative'), and the error condition for unexecuted searches. It also notes that matchRate is 'banded' and that criteria-met count doesn't discriminate at the top of a ranked list. This is rich behavioral detail well beyond structured fields, giving the agent a clear understanding of what happens when calling the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place: the first line states the action and output, the cost note is critical, the 'READING THE RESULTS' section is indispensable for correct interpretation, and the final error note is essential. It's well-structured with clear sections (purpose, cost, interpretation, error condition). No fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description enumerates the return fields and explains the semantic meaning of matchRate and verdicts (including the crucial 'unknown ≠ negative' nuance). It covers error behavior, limits, and the relationship to search execution. With four parameters fully documented in the schema and the description adding inter-tool references, an agent has everything necessary to correctly invoke and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all parameters with descriptions at 100% coverage, so the baseline is 3. The description adds meaningful context: it tells the agent that searchId comes from jb_list_searches, that projectId is a specific format and can be omitted to use a default project, and that limit has a default of 50 and max of 500. These references connect the tool to its ecosystem and clarify usage, exceeding the schema's raw field meanings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a specific verb ('Pull') and a specific resource ('a saved search's ranked candidates'), and details the exact fields returned (name, LinkedIn URL, title, company, location, matchRate, per-criterion verdicts). This clearly distinguishes it from siblings like jb_list_searches (which lists searches) and jb_count (counts). The scope is precise and non-tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states that this costs no export credits and is the same surface as the results page, giving context on when it's appropriate. It also provides a prerequisite: 'If the search has never been executed, this errors — open it in the app and press Run search once.' It doesn't explicitly name sibling alternatives, but the distinct purposes of siblings (list, count, run) make the usage boundary clear. The 'READING THE RESULTS' section adds interpretive guidance, though it's more about reading the output than choosing when to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jb_list_searchesA

List the saved searches on a Juicebox project (searchId + name). Saved searches are stable and re-runnable, so this is the entry point for pulling existing sourcing work. Defaults to the configured project.

NameRequiredDescriptionDefault
projectIdNoJuicebox project id, or a /project/{id} URL. Optional.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that saved searches are stable and re-runnable (reassuring the agent that reuse is safe), and that it defaults to the configured project. This adds useful behavioral context beyond the raw schema. It doesn't mention pagination or error behavior, but for a simple list operation this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states the purpose and output, the second adds context and default behavior. No wasted words, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter list tool with no output schema, the description is nearly complete: it explains what is returned, the stability, and the default. It could mention whether an empty list is returned when none exist, but that is minor. It doesn't need to explain return values since it already says 'searchId + name'. Missing details are negligible.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes projectId as optional and as a URL or ID (100% coverage). The description adds value by stating it defaults to the configured project, which is not in the schema. That's meaningful extra guidance for when an agent can omit the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list), the resource (saved searches on a Juicebox project), and the output (searchId + name). It also situates the tool as an entry point for pulling existing sourcing work, distinguishing it from siblings like jb_run_search or jb_get_results without needing to inspect them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says this is the entry point for pulling existing sourcing work, implying you should use this before running or fetching results. It also notes the default-project behavior, which helps an agent decide when explicitly passing projectId is unnecessary. It doesn't explicitly say 'don't use this if you want results' or name alternatives, but the use case is implied clearly enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.0
    • First observedjb_count
    • First observedjb_get_results
    • First observedjb_list_searches
    • First observedjb_run_search
Deploy Server
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

TDQS

A4.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: list saved searches, fetch ranked results, tune filter counts, and create/run a new search. No two tools overlap in function, making misselection unlikely.

Naming Consistency5/5

All tools follow the consistent pattern of 'jb_' prefix + verb_noun (list_searches, get_results, run_search) with count as a concise verb. This is predictable and uniform.

Tool Count5/5

Four tools is well-scoped for a talent sourcing server. Each tool earns its place and covers the core workflow without redundancy or bloat.

Completeness4/5

The surface covers the essential lifecycle: listing existing searches, retrieving results, tuning filters without execution, and creating new searches. Minor gaps like deleting or updating saved searches exist but are not critical for the primary use case.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • Socials MCP

    Brainrot-Creations
    A
    license
    A
    quality
    B
    maintenance
    Enables Claude to perform actions on X, LinkedIn, and Reddit via a Chrome extension, such as connecting with recruiters, finding threads, and replying to posts.
    36
    38 npm
    1
    MIT

  • JobSpy MCP Server

    chinpeerapat
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables job search and scraping across multiple job boards (LinkedIn, Indeed, Glassdoor, etc.) with advanced filtering, directly from Claude Desktop or other MCP clients.
    6
    MIT

  • job-search-mcp

    jppoamaral
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables searching and evaluating job postings from LinkedIn and freehire.me directly through Claude Desktop. Provides tools to search jobs, fetch full posting details, and assess candidate fit using eligibility scans and a scoring rubric.
    MIT