de en es ja ko ru zh

job-search-mcp

Name: job-search-mcp
Author: Servation

by Servation

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

job-search-mcp

Un asistente personal de búsqueda de empleo para Claude Desktop. Le pides a Claude que encuentre trabajos; busca en los portales de empleo reales, puntúa cada uno de 0 a 100 según lo bien que encaje contigo y los muestra en un tablero clasificado que puedes triar con un clic. Todo se ejecuta localmente: no se necesitan claves de API ni cuentas.

Es una aplicación MCP: un pequeño servidor con el que Claude Desktop se comunica, más un tablero integrado que se renderiza directamente en el chat.

Alcance: está ajustado para roles de ingeniería de software en EE. UU. (las fuentes integradas y los filtros de rol se dirigen a empleadores tecnológicos de EE. UU.). Otros campos o regiones devolverán resultados escasos.
Funciona en: construido y probado para Claude Desktop. También debería funcionar en otros clientes MCP que ejecuten un servidor local (stdio) y rendericen interfaces de aplicación MCP, como VS Code (Copilot), Cursor o Goose (sin probar). Los clientes solo remotos (ChatGPT, Claude en web/móvil) no pueden lanzar un servidor local, por lo que no funcionarán.

Qué hace

Busca en portales de empleo reales — LinkedIn más 8 fuentes de ATS/empleo (Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Hacker News, RemoteOK, Remotive), usando tus roles objetivo y ubicación.
Puntúa cada trabajo para ti — Claude lee la descripción completa y le da una puntuación de ajuste de 0 a 100 con una razón de una línea, sopesando tus habilidades, años de experiencia, ajuste de seniority y el rol.
Te permite triar rápido — Aplicar / Omitir en cada tarjeta, o en masa ("descartar todo lo que esté por debajo de 60").
Recuerda — mantiene una lista corta en curso, un rastreador de lo que has solicitado y no te mostrará el mismo trabajo dos veces (durante 6 meses).

Related MCP server: Jobless MCP

Configuración

1. Informa a Claude Desktop sobre ello. Abre tu archivo de configuración:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Añade esto bajo "mcpServers" — npx obtiene el paquete publicado por ti, sin necesidad de clonar ni compilar:

{
  "mcpServers": {
    "job-search": {
      "command": "npx",
      "args": ["-y", "@servation/job-search-mcp"]
    }
  }
}

2. Cierra y vuelve a abrir Claude Desktop por completo (en Windows, sal desde la bandeja del sistema; cerrar la ventana no es suficiente). Eso es todo.

npm install
npm run build

Luego apunta la configuración a dist/main.js de esta carpeta en su lugar:

{
  "mcpServers": {
    "job-search": {
      "command": "node",
      "args": ["D:\\job-search-mcp\\dist\\main.js"]
    }
  }
}

Cómo usarlo

Solo habla con Claude. Por ejemplo:

"Guarda mi perfil" — pega primero tu currículum; Claude extrae tus habilidades, roles, años y ubicación para que las búsquedas y la puntuación se adapten a ti.
"Encuentra trabajos de ingeniero backend en California, nivel senior, publicados esta semana."
"Encuentra trabajos con pocos solicitantes" — añade el filtro de solicitantes tempranos de LinkedIn.
"Descarta todo lo que esté por debajo de 60."
"Muestra a lo que he aplicado."
"Vuelve a puntuar el tablero."

Un primer uso típico: guarda tu perfil → "busca trabajos" → Claude los puntúa y muestra el tablero clasificado → tú aplicas/omites.

El tablero

El tablero es una lista corta en curso. Un trabajo permanece en él hasta que Aplicas (se mueve a tu rastreador) o Omites (oculto para siempre). Las nuevas búsquedas omiten automáticamente los trabajos que ya están en el tablero, en tu rastreador, descartados o mostrados en los últimos 6 meses, para que nunca veas el mismo anuncio dos veces seguidas.

Haz clic en Aplicado u Omitir en una tarjeta, o pídele a Claude que lo haga. Triado en el widget, se mantiene.

Herramientas (para referencia)

Rara vez las llamas por su nombre — Claude elige la correcta — pero esto es lo que hay bajo el capó:

Tool	Qué hace
`find_jobs`	Busca en los portales tus roles/ubicación (con filtros opcionales: seniority, tipo, reciente, remoto, salario, solicitantes, fuente).
`evaluate_jobs`	Claude puntúa los trabajos encontrados de 0 a 100 para ajuste (se ejecuta automáticamente después de una búsqueda).
`show_board`	Muestra el tablero clasificado (o tu rastreador `saved`).
`set_status`	Aplicar / Omitir / guardar un solo trabajo (también los botones de la tarjeta).
`bulk_status`	Tria muchos a la vez por puntuación o fuente, p. ej. descarta todo lo que esté por debajo de 60.
`whats_promising`	Lista el tablero actual como texto (todos los trabajos puntuados + cualquier cosa aún sin puntuar).
`review_saved`	Tu rastreador: trabajos que has guardado o a los que has aplicado.
`rescore_board`	Vuelve a puntuar cada trabajo del tablero desde cero.
`clear_jobs`	Ordena: limpia restos sin puntuar o todo el tablero (nunca toca aplicados/descartados).
`save_profile`	Guarda tu perfil de currículum (impulsa la búsqueda y la puntuación).

Dónde viven tus datos

Un archivo JSON en tu máquina: sin nube, no se envía nada a ningún sitio excepto a los portales de empleo que buscas:

Instalado: ~/.job-search-mcp/jobs.json
Ejecutando desde el código fuente: ./data/jobs.json
Anula con la variable de entorno JOB_SEARCH_MCP_DATA.

Opcional: modo LinkedIn Premium

Por defecto, LinkedIn usa sus endpoints públicos de invitado: sin inicio de sesión y sin riesgo de inicio de sesión de cuenta, y ya obtienes descripciones completas de los trabajos. Ten en cuenta que el acceso automatizado aún se ejecuta desde tu propia IP y va contra el Acuerdo de Usuario de LinkedIn incluso en modo invitado, así que úsalo bajo tu propio criterio. Si quieres datos más ricos/Premium, puedes usar tu cuenta con sesión iniciada añadiendo un bloque env a la configuración del servidor:

"job-search": {
  "command": "npx",
  "args": ["-y", "@servation/job-search-mcp"],
  "env": {
    "LINKEDIN_LI_AT": "<your li_at cookie>",
    "LINKEDIN_JSESSIONID": "ajax:1234567890123456789"
  }
}

Obtén ambas cookies desde una pestaña linkedin.com con sesión iniciada → DevTools → Application → Cookies.

⚠️ Aviso: esto va contra los Términos de Servicio de LinkedIn y puede hacer que tu cuenta sea marcada o restringida. Las cookies también caducan aproximadamente cada mes y los endpoints internos de LinkedIn cambian sin previo aviso. Si algo falla, vuelve automáticamente al modo invitado. Deja fuera el bloque env para mantenerte completamente seguro (solo invitado).

Cómo funciona la puntuación

Claude (el modelo anfitrión) hace la puntuación directamente: lee cada descripción y juzga el ajuste, lo cual está bien calibrado. Se mantiene una fórmula determinista (computeMatchScore en scoring.ts) como respaldo para cualquiera que ejecute un modelo local más débil que tiende a sobreclasificar todo; no está activa por defecto.

Desarrollo

npm run typecheck    # type-check UI + server + harness
npm run build        # build the UI bundle (vite single-file) + compile the server (tsc)
npm run serve:stdio  # run the server from source (tsx) for local testing
npm run harness      # work on the review UI without Claude Desktop (see harness/)
npm run canary       # check every job source is still returning postings

El servidor es solo stdio (main.ts → server.ts); la interfaz es una aplicación React empaquetada en un único archivo HTML incrustado (src/mcp-app.tsx → dist/mcp-app.html) que el servidor sirve como recurso ui://.

Si trabajas en la interfaz, usa harness/. Es un sustituto local de Claude Desktop que renderiza el widget contra un almacén de trabajos sintético y un puente real ui/*. Abrir dist/mcp-app.html en una pestaña del navegador solo te da "Conectando…", y las cosas que más probablemente se rompan (apertura de enlaces, temas, el refresco posterior al montaje) están mediadas por el anfitrión, por lo que solo aparecen con un anfitrión al otro lado.

Si una fuente de empleo se apaga, npm run canary te dice cuál. Los slugs de empresa se pudren a menudo, por lo que la solución suele estar en el registro remoto de slugs que updateCompanyDirectoriesFromRegistry() vuelve a leer en tiempo de ejecución, en lugar de en una nueva versión.

Available Tools

10 tools

bulk_statusBulk TriageA

Triage MANY board jobs at once by score and/or source — e.g. dismiss every scored job under 60. Applies status to all scanned (board) jobs matching the filters; the server selects them, so you do NOT need the individual job ids. below_score/above_score match SCORED jobs only (use clear_jobs for un-evaluated ones). Provide at least one filter. Returns text; call show_board afterward to display.

Name	Required	Description
`notes`	No	Optional note to attach to every matched job.
`source`	No	Restrict to one source.
`status`	Yes	Status to apply to every match.
`above_score`	No	Match scored jobs with matchScore AT OR ABOVE this.
`below_score`	No	Match scored jobs with matchScore BELOW this (e.g. 60).

TDQS

A4.8/5.0

Behavior5/5

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

Discloses key behavioral traits: it applies status to all scanned board jobs matching filters, server selects jobs (no need for IDs), returns text, and recommends post-call action (call show_board). No annotations exist to contradict.

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?

Three sentences with no wasted words. First sentence gives purpose and example, second explains mechanism, third clarifies scope and provides follow-up instruction. Efficient and well-organized.

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 bulk operation with 5 params, no output schema, and no annotations, the description covers essential behavioral aspects (selection, return format, post-call step). Could mention error handling or rate limits, but not required for basic usage.

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?

Schema coverage is 100% (baseline 3). Description adds value by clarifying that `below_score`/`above_score` match only SCORED jobs (linking to `clear_jobs`), and implies that at least one filter is needed.

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 tool's purpose with a specific verb ('Triage') and resource ('board jobs'), and gives an example ('dismiss every scored job under 60'). It distinguishes itself from sibling 'clear_jobs' by noting the scoping to scored jobs only.

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?

Explicitly states when to use (bulk triage by score/source) and when to use alternatives ('use clear_jobs for un-evaluated ones'). Also provides a usage constraint: 'Provide at least one filter'.

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

clear_jobsClear JobsA

Clear jobs from the review board. which='unscored' (default) removes only the not-yet-evaluated leftovers; which='all' clears the whole board. Saved/applied jobs (the tracker) and dismissed jobs are NOT affected — dismissed jobs still won't be re-sourced. Returns text; call show_board to display.

Name	Required	Description	Default
`which`	No	'unscored' (default) clears un-evaluated jobs; 'all' clears the whole board.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that saved/applied and dismissed jobs are not affected, and that dismissed jobs remain dismissed. The return type ('text') is mentioned. It could add details on reversibility or permissions but is fairly transparent.

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 three concise sentences with no wasted words. It is front-loaded with the core action and provides necessary details efficiently.

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?

Given the tool's simplicity, the description covers primary behavior, return type, and exclusions. It is mostly complete but could mention error scenarios or permissions for full completeness.

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

Parameters3/5

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

The schema coverage is 100% with enum descriptions. The description adds minimal extra context ('not-yet-evaluated leftovers' vs 'un-evaluated in schema). Baseline 3 is appropriate as it doesn't significantly enhance parameter meaning.

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 tool clears jobs from the review board, distinguishing between 'unscored' (only un-evaluated jobs) and 'all' (entire board). This differentiates it from siblings like 'evaluate_jobs' or 'bulk_status'.

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 details when to use each 'which' option and notes that dismissed jobs are unaffected, providing implicit guidance. However, it does not explicitly compare this tool to siblings like 'set_status' or 'rescore_board' for alternative actions.

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

evaluate_jobsEvaluate JobsA

Score one or more sourced jobs for THIS candidate (holistic). YOU assign each job a 0-100 fit score directly, using the candidate summary (shown in find_jobs / whats_promising) and the job description. Weigh the must-have requirements, the candidate's actual skills and years of experience (a role demanding far more seniority/years than the candidate has should score LOWER), domain fit, and standout strengths. Calibrate and use the FULL range — do not bunch everything at 80+: 80-100 = strong fit and realistic; 60-79 = good with real gaps; 40-59 = partial/stretch (e.g. wrong level); below 40 = poor or wrong field. Pass { job_id, score, reason } per job. Use the EXACT bracketed ids; do not invent them. Score every job in one call. Returns text; call show_board afterward to display the ranked board.

Name	Required	Description	Default
`evaluations`	Yes	One entry per job to score.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided; description discloses the scoring behavior, range usage, and return type ('Returns text'). However, does not explicitly state if it modifies state or requires permissions.

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

Conciseness4/5

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

Moderate length but well-structured with clear instructions, front-loaded purpose, and every sentence adds value. Slightly wordy but necessary for complex scoring guidelines.

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?

Covers the scoring criteria, calibration, and post-call step. Lacks explicit return format details, but overall complete given the complexity and no output schema.

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?

Schema coverage is 100% with good field descriptions. Description adds contextual meaning about scoring logic, calibration, and post-call actions, going beyond schema details.

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?

Clearly states it scores one or more sourced jobs for a candidate, assigning 0-100 fit scores. Distinct from siblings like find_jobs (finding) and show_board (displaying).

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?

Explicitly says to use after finding jobs ('sourced jobs'), instructs to score all jobs in one call, and recommends calling show_board afterward. Also provides calibration advice.

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

find_jobsFind JobsA

Source live jobs (LinkedIn + Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Hacker News, RemoteOK, Remotive), dedup them, and return them as text with full descriptions. Uses the saved profile's roles/location by default; pass query/location/filters to override. This returns UNSCORED jobs and does NOT show a card UI — immediately score all of them with evaluate_jobs (a 0-100 fit score + reason each), then show_board once, to present the single ranked board. Do not just list them back.

Name	Required	Description
`limit`	No	Max jobs to return/persist this run (default 15).
`query`	No	Role/keyword filter, e.g. 'backend java spring'. Overrides the profile's target roles.
`remote`	No	Workplace type (LinkedIn); also sets remote preference.
`sort_by`	No	LinkedIn result ordering.
`sources`	No	Restrict to these sources (default: all).
`job_type`	No	Employment type (LinkedIn).
`location`	No	Location filter, e.g. 'California' or 'Remote'. Overrides the profile's search location.
`max_years`	No	Candidate's years of experience for this search (overrides the saved profile); also defaults the seniority filter.
`salary_min`	No	Minimum annual salary filter (LinkedIn), e.g. 100000.
`date_posted`	No	Recency filter (LinkedIn).
`verify_urls`	No	If true, network-verify each job URL (slower). Default false.
`max_applicants`	No	Surface low-applicant LinkedIn jobs (uses LinkedIn's early-applicant filter, ~under 25). Exact applicant-count filtering requires the LinkedIn cookie.
`experience_level`	No	Seniority filter (LinkedIn).

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description covers key behaviors: dedup, returns text, no card UI, uses saved profile by default. It mentions verify_urls performance implication but lacks details on rate limits or auth. Overall transparent enough for agent decision-making.

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 concise—two sentences plus a workflow directive. It front-loads the purpose and packs necessary guidance without fluff. Every sentence adds value.

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?

Given 13 parameters, no output schema, and multiple siblings, the description adequately explains the tool's output format (text), the workflow, and default behavior. Could mention the default limit value (15) but schema covers it. Overall complete for practical use.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are well-documented there. The tool description adds context about defaults and overrides, but this is minimal extra value. Baseline 3 is appropriate.

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 it sources live jobs from multiple platforms, deduplicates them, returns text with full descriptions, and distinguishes its role from sibling tools like evaluate_jobs and show_board. It specifies the action and resource precisely.

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 provides explicit workflow instructions: the tool returns unscored jobs, and the agent must then call evaluate_jobs and show_board. It also explains how to override default profile settings. This clearly tells when and how 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.

rescore_boardRe-score BoardA

Re-score the WHOLE board from scratch — every job, INCLUDING ones that already have a score. Use this when the user asks to 'rescore'/'re-evaluate' the board or after the scoring approach changed. Returns all board jobs with their ids + descriptions; call evaluate_jobs with a FRESH { job_id, score, reason } for EACH (do not skip already-scored ones), then call show_board. Set include_saved=true to also re-score the saved/applied tracker.

Name	Required	Description	Default
`include_saved`	No	Also re-score the saved/applied tracker jobs (default false).

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully discloses that it rescore from scratch, includes already scored jobs, returns job ids+descriptions, and requires subsequent actions. It also explains the include_saved parameter behavior transparently.

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

Conciseness4/5

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

The description is concise (3 sentences) and front-loaded with the main action. However, it could be slightly more structured (e.g., separate sections) but each sentence adds necessary value.

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 composite nature (involves a whole-board rescore, returns data, and requires follow-up calls), the description covers the action, trigger conditions, return format, and required subsequent steps (evaluate_jobs and show_board). No output schema needed because return is clearly described.

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?

Schema coverage is 100% for the single parameter. The description adds meaning by explaining the effect of setting include_saved=true to also re-score the saved/applied tracker, which goes slightly beyond the schema comment.

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 're-score the whole board from scratch' and specifies the resource 'board'. It distinguishes from sibling tools like evaluate_jobs by noting it rescore every job including already scored ones, and sets context for when to use it.

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?

Explicitly says when to use: 'when the user asks to rescore/evaluate the board or after the scoring approach changed.' It also provides direct guidance: 'call evaluate_jobs with FRESH... then call show_board,' and warns not to skip already scored jobs.

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

review_savedReview Saved JobsA

List the tracker as text: jobs marked saved (interested) or applied, with their status, score, and notes. Use this to see what you're tracking or have applied to. To DISPLAY the tracker widget, call show_board with view='saved'.

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It accurately portrays a read-only listing behavior without mentioning destructive or side effects. It could briefly note that the output is plain text, but overall transparency is high.

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?

Three sentences, each purposeful. The first sentence defines the output, the second states usage, the third points to an alternative. No wasted words.

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?

Given no parameters or output schema, the description covers the key aspects: what is listed (saved/applied jobs), the fields included (status, score, notes), and the differentiation from show_board. It could mention ordering or limits, but is sufficient for a simple list tool.

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 tool has zero parameters, and schema coverage is 100% (vacuously). Per calibration, baseline is 4. The description does not need to add parameter info.

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 tool lists jobs marked as saved or applied with their status, score, and notes. It specifies the resource ('tracker') and action ('list'), and distinguishes from the sibling tool show_board, which displays a widget.

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 explicitly tells when to use this tool ('to see what you're tracking or have applied to') and when not to, by directing to an alternative ('To DISPLAY the tracker widget, call show_board with view='saved'').

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

save_profileSave Resume ProfileA

Extract the candidate's profile from their resume text (which the user pastes in chat) and save it. Pull: full name; core technical skills; suggested target roles; preferred/search location; total years of professional experience (integer); and pass the resume text as rawText. The profile is used by find_jobs (target roles + location) and by scoring (years of experience drives the experience penalty), so set yearsOfExperience accurately. Merges with any existing profile.

Name	Required	Description
`name`	No	Candidate's full name.
`skills`	No	Core technical skills.
`rawText`	No	The full resume text, stored for reference.
`targetRoles`	No	Suggested target job titles.
`prefersRemote`	No	Whether the candidate prefers remote.
`searchLocation`	No	Preferred location, e.g. 'California' or 'Remote'.
`blockedCompanies`	No	Companies to exclude from sourcing.
`yearsOfExperience`	No	Total years of professional experience (integer).

TDQS

A4.4/5.0

Behavior4/5

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

Without annotations, the description covers the core behavior: extraction, saving, merging, and downstream impact. It does not disclose rate limits or auth needs, but the simple save operation is sufficiently transparent for an AI agent.

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 four sentences with no wasted words. The first sentence immediately states the core action, and subsequent sentences add necessary context efficiently.

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?

Given no annotations and no output schema, the description adequately covers purpose, behavior, and linkage to other tools. It could mention what happens with missing fields or the return value, but overall it is sufficient.

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 description adds meaning beyond the input schema by explaining how yearsOfExperience drives the experience penalty and that the tool merges with existing profiles. It omits two parameters (prefersRemote, blockedCompanies) from the explanation, but schema coverage is high at 100%.

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 tool extracts a candidate's profile from resume text, saves it, and lists the specific fields pulled. It also explains the profile's downstream use by find_jobs and scoring, distinguishing it from sibling tools.

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 explains that the profile is used for job finding and scoring, implying when to use. It mentions merging behavior, but does not explicitly exclude alternative tools or provide when-not-to-use guidance.

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

set_statusSet Job StatusA

Triage a job by id: 'saved' (interested/tracking), 'applied' (also stamps the date), 'dismissed' (skip), or 'discovered' (undo back to the board). Moves it between the scanned/saved/dismissed lists and persists. Optionally attach notes. Called by the review UI; also usable directly.

Name	Required	Description
`notes`	No	Optional notes to attach to the job.
`job_id`	Yes	The job's id.
`status`	Yes	New triage status.

Output Schema

Name	Required	Description
`jobs`	Yes
`view`	No
`count`	Yes
`scored`	Yes
`profile`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

The description discloses the effects of each status (e.g., 'applied' stamps date, 'discovered' undoes to board) and that the tool persists changes. With no annotations, these details are essential and well-covered.

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?

Three sentences front-load the purpose and progressively add details: status list, behavior, notes, and usage context. No wasted words.

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 presence of an output schema, the description covers all necessary context: parameter semantics, behavioral side effects, and typical usage (review UI). It is fully sufficient for an agent to select and invoke the tool correctly.

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 schema coverage is 100%, the description adds significant value by explaining the meaning and behavioral impact of each status enum value and the optional notes parameter, going beyond the schema's simple type 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 clearly states the tool's purpose: triage a job by setting its status to one of four enumerated values, each with a specific meaning. It distinguishes from sibling tools like bulk_status by focusing on a single job.

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

Usage Guidelines3/5

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

It indicates the tool is called by the review UI and usable directly, but does not explicitly specify when to use it versus alternatives like bulk_status. No when-not-to-use guidance is provided.

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

show_boardShow BoardA

Display the job board (or the saved/applied tracker) as an interactive widget. Call this ONCE, at the end of a request, after doing the work (find_jobs/evaluate_jobs/bulk_status/clear_jobs/whats_promising are text-only and do NOT render). view='board' (default) shows the ranked board; view='saved' shows the tracker.

Name	Required	Description	Default
`view`	No	'board' (default) = the ranked board; 'saved' = the applied/saved tracker.

Output Schema

Name	Required	Description
`jobs`	Yes
`view`	No
`count`	Yes
`scored`	Yes
`profile`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Discloses it renders interactive widget, no side effects implied. With no annotations, description carries burden; could mention idempotency but not required for display 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?

Two sentences, front-loaded with action and context. No extraneous words.

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?

Handles single parameter, output schema exists, description covers usage and view options. Complete for its simplicity.

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?

Schema coverage 100%. Description adds clarity on default view and what each view shows beyond enum values.

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?

Clearly states it displays a board/tracker as interactive widget. Distinguishes from siblings by noting text-only tools do NOT render.

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?

Explicitly says call once at end of request after other work. Specifies views and default. Contrasts with text-only siblings.

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

whats_promisingWhat's PromisingA

List the current job board as text: every scored job (with its id) and any UNSCORED jobs with their ids + descriptions so you can evaluate them. To score the unscored ones, call evaluate_jobs with the EXACT bracketed ids shown. Use this to review jobs already found (find_jobs only returns brand-new ones). To re-score jobs that ALREADY have a score, use rescore_board instead. To DISPLAY the board widget to the user, call show_board (this returns text for you to act on).

Name	Required	Description	Default
`limit`	No	Max unscored jobs to surface for evaluation (default 15).

TDQS

A4.4/5.0

Behavior4/5

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

Despite no annotations, the description discloses that the tool returns text with job details and provides instructions for scoring. It implies a read-only operation, which is consistent. Could be slightly more explicit about side effects, but the context suggests no mutation.

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

Conciseness4/5

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

The description is a single paragraph that efficiently covers purpose, usage, and alternatives. It is front-loaded with the main action. Every sentence adds value, though slightly verbose; still very effective.

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 no output schema and one optional parameter, the description fully explains what the tool returns (textual listing of jobs) and how to use it in the broader workflow (evaluating, rescoring, displaying). It covers all necessary context for an agent to use it correctly.

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

Parameters3/5

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

The only parameter 'limit' is fully described in the input schema (max unscored jobs, default 15). The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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 tool lists the current job board with scored and unscored jobs. It uses specific verb 'list' and resource 'job board', and distinguishes from siblings like find_jobs (brand-new jobs) and rescore_board (rescoring already scored jobs).

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?

Explicitly states when to use: 'Use this to review jobs already found (find_jobs only returns brand-new ones).' Also specifies alternatives: rescore_board for re-scoring, show_board for displaying to user, evaluate_jobs for scoring unscored jobs.

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.

10 tool updatesv0.1.1Jul 1, 2026
- First observedbulk_status
- First observedclear_jobs
- First observedevaluate_jobs
- First observedfind_jobs
- First observedrescore_board
- First observedreview_saved
- First observedsave_profile
- First observedset_status
- First observedshow_board
- First observedwhats_promising

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored 2026-07-01 03:35 across 10 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: bulk_status for bulk triage, clear_jobs for clearing, evaluate_jobs for scoring single jobs, find_jobs for sourcing, rescore_board for re-evaluating all, review_saved for tracker text, save_profile for profile, set_status for individual triage, show_board for display, and whats_promising for listing. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., bulk_status, evaluate_jobs, save_profile). The only minor deviation is 'whats_promising' using a contraction, but it still follows the pattern and is easily readable.

Tool Count5/5

10 tools is well within the ideal 3-15 range for a focused job search server. Each tool addresses a necessary function without bloat, and the count feels natural for the domain.

Completeness4/5

The tool set covers the core workflow: sourcing (find_jobs), scoring (evaluate_jobs, rescore_board), triaging (bulk_status, set_status, clear_jobs), tracking (review_saved), display (show_board), and profile management (save_profile). Minor gaps like no explicit profile update tool exist, but save_profile merges, so it's almost complete.

Maintenance

ActivityStale

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

SckianA
com.sckian
AI job matching in your assistant: ranked offers, tailored resumes, application tracking.
Workplace & Productivity
151
https://sckian.com/mcp
HopeHireC
in.hopehire
Tailor resumes, score ATS fit, find hiring leads, and send cold outreach, from your agent.
App Automation Email
1681
https://hopehire.in/mcp
ApplyKoala
com.applykoala
Job search for your AI: save jobs, research companies, keep stories, track applications.
Search Project Management Note Taking
1
https://applykoala.com/mcp
CareerCorner
ai.careercorner
Your personal career coach. Scanning jobs for you, daily.
Search Web Scraping App Automation
1
https://careercorner.ai/api/mcp

Related MCP Servers

JobSpy MCP Server
Web Scraping Search
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.
Updated 3 months ago (2026-08-20 10:23 UTC)
6
MIT
Jobless MCP
Search App Automation
bendza
A
license
Not graded
quality
B
maintenance
Personalized job search inside Claude. Get ranked job matches based on your actual skills, not keywords.
Updated 5 months ago (2026-05-22 18:01 UTC)
2
MIT
JobPilot MCP
Browser Automation Search App Automation
TheCodeDaniel
A
license
A
quality
D
maintenance
Transforms Claude into an AI job-hunting assistant that searches remote job boards, scores roles against your CV, generates tailored cover letters, and logs everything to a Notion tracker.
Updated 7 months ago (2026-03-25 11:49 UTC)
11
MIT
job-search-mcp
Search Web Scraping
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.
Updated 3 months ago (2026-08-02 21:12 UTC)
MIT