Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JobsDirect MCP Find remote senior React jobs from the last 7 days and score my CV fit."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Live demo: https://jobs-direct-mcp.vercel.app (mock mode, runs fully in the browser) · deploys automatically on every push to main
An MCP server that lets Claude Desktop, Cursor or any MCP client search six job portals, score how well you fit each posting, and prepare the application: a tailored resume, a cover letter, a Word file and a tracker entry. It runs locally; your CV never leaves your machine.
MCP server | Python 3.10+ · FastMCP · httpx · BeautifulSoup · python-docx |
Web demo | React 18 · TypeScript · Tailwind CSS · Vite, deployed on Vercel |
Portals | LinkedIn · Himalayas · Remote.co · CareerHound · HiredChina · Kariyer.net |
Tool | What it does |
| Searches one or all portals. Filters by workplace (remote/hybrid/onsite) and posting age, and drops postings that say they are closed. |
| Full description, criteria and open/closed status for a LinkedIn job ID or any posting URL. |
| 4-tier ATS score (0-100) with a verdict and the reasons behind it. |
| Re-ranks your own CV bullets by relevance, lists matched and missing keywords, flags bullets without a metric. It does not invent experience. |
| Short letter citing your two most relevant achievements. |
| Saves Markdown as a Word document. |
| Fetch + score + resume + letter in one call. |
| Add, update and list applications in |
| Indicative junior/mid/senior bands for US, EU, UK, Türkiye and remote. |
Fit (0-100) =
Tier 1 Industry affinity 40 your industry keywords vs. the employer's
Tier 2 Qualifications gate 20 degree level + years of experience (a "3-5 years" range counts as 3)
Tier 3 Skills overlap 30 tools and methods the posting names that your CV also names
Tier 4 Language & eligibility 10 a missing required language fails the gate; clearance / citizenship
wording asks you to confirm work authorisationVerdicts: STRONG_MATCH (80+), MODERATE_MATCH (60+), WEAK_MATCH, plus gate verdicts that override the
number: CLOSED (closure notice or a past deadline, in English or Turkish), LANGUAGE_GATE_FAILED,
VERIFY_ELIGIBILITY, NOT_ELIGIBLE and POOR_DOMAIN_FIT. A posting for crypto trading will not score
well for a heavy-machinery project manager just because both mention "Agile".
Related MCP server: job-tracker
git clone https://github.com/weblinkify/jobs-direct-mcp
cd jobs-direct-mcp
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e .Add it to your MCP client (claude_desktop_config.json, Cursor mcp.json, …):
{
"mcpServers": {
"jobsdirect": {
"command": "/ABSOLUTE/PATH/jobs-direct-mcp/.venv/bin/jobsdirect",
"env": { "JOBSDIRECT_OUTPUT_DIR": "~/Desktop" }
}
}
}On Windows the command is C:\\path\\jobs-direct-mcp\\.venv\\Scripts\\jobsdirect.exe. Files (Word exports, the
tracker CSV) go to JOBSDIRECT_OUTPUT_DIR, else your Desktop, else ~/JobsDirect.
I'm looking for remote senior frontend roles in Europe. My CV is attached.
1. search_jobs for "senior frontend react" on all portals, last 7 days.
2. evaluate_job_fit for each result against my CV and pick the top 2.
3. tailor_resume and generate_cover_letter for the best one, then export_to_docx.
4. track_application with status "saved".cd frontend
npm install
npm run dev # http://localhost:5173The demo uses sample postings (fictional companies) but the scoring and writing are real: the browser runs a TypeScript port of the Python engine. Edit the profile and every posting re-scores. Tracked applications stay in your browser's local storage and export to CSV.
The two engines stay identical: fixtures/generate.py writes fixtures/ats_cases.json from the Python
code, and both tests/test_parity.py and frontend/src/__tests__/parity.test.ts assert against it.
Import the repo in Vercel and set Root Directory to frontend. frontend/vercel.json handles the
rest (Vite build, SPA rewrite, cache and security headers). No environment variables are needed.
pip install -r requirements-dev.txt
pytest -q # Python: engine, portals (mocked HTTP), writer, tracker, MCP wiring
python fixtures/generate.py # after changing jobsdirect/ats.py
cd frontend && npm test && npm run buildPortal markup changes from time to time. Each portal fails on its own and is reported in
portal_errors, so one broken source does not stop a search.
Respect each site's terms of use and rate limits; this tool fetches only public pages, one request per search.
Salary bands are indicative planning numbers, not live market data.
MIT
Score candidate-to-job fit 0-100 with the 4-tier ATS engine.
Tiers: industry/domain affinity (40), degree + years gate (20), skills overlap (30), language and work-authorisation gate (10, a missing required language fails the gate).
| Name | Required | Description | Default |
|---|---|---|---|
| job_description | Yes | Full posting text. | |
| work_authorized | No | True if the candidate may work where the job is (no sponsorship needed). | |
| candidate_profile | Yes | Resume / profile text. | |
| candidate_languages | No | e.g. ["English", "Turkish"]. Omit to detect from the profile. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden; it does disclose genuinely useful behavior — the weighted tier structure and the hard fact that a missing required language fails the gate. However, it omits key runtime semantics: whether the score is deterministic or model-judged, and what happens when work_authorized is null (unknown vs. treated as unauthorized), which directly changes the gate outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first front-loads the action and output range, the second compactly enumerates the four weighted tiers. No filler, no repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full schema coverage, return values and inputs are covered elsewhere; the description supplies the scoring model on top of that. The remaining gap is tool-selection context and null-handling semantics, which are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does add some meaning by explaining that language and work authorisation feed a pass/fail gate worth 10 points, which frames how candidate_languages and work_authorized are used — but it says nothing about the null/default handling those parameters expose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (score candidate-to-job fit), an explicit output scale (0-100), and the named mechanism (4-tier ATS engine). The tier breakdown makes the operation unambiguous. It does not explicitly contrast with siblings like prepare_job_application or tailor_resume, but the function is clearly distinct from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus the sibling tools, nor on prerequisites (e.g., must the job be retrieved via get_job_details first, or is it a pre-application screen?). The reader must infer usage entirely from the name and tier list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save Markdown text (resume, cover letter, report) as a Word .docx in the output folder.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| filename | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It does disclose two useful traits: input must be Markdown, and output lands in the 'output folder'. It does not say whether it overwrites existing files, whether Markdown formatting is preserved, or whether permissions/errors are surfaced — meaningful gaps for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words. Brevity is achieved without awkwardness, though it leaves behavior under-specified rather than fully economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. Still, for a 3-parameter mutation tool with no annotations and zero schema coverage, the description should at least clarify naming behavior and overwrite/formatting expectations, which it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only alludes to 'content' as Markdown text. It never mentions 'title' or the optional 'filename' parameter, nor how the file is named when filename is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (save as Word .docx) and the source format (Markdown text), with example document types in parentheses. It's clear what the tool produces, but it doesn't differentiate from siblings — though none of the listed siblings are export tools, so the risk is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the parenthetical document types (resume, cover letter, report) and the Markdown-to-.docx conversion step, giving the agent a reasonable sense of when to reach for it. There is no explicit statement of when not to use it or how it relates to siblings like generate_cover_letter or tailor_resume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a short cover letter that cites the candidate's two most relevant achievements.
| Name | Required | Description | Default |
|---|---|---|---|
| job_title | Yes | ||
| company_name | Yes | ||
| candidate_name | No | ||
| hiring_manager | No | ||
| job_description | Yes | ||
| candidate_profile | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says the letter is short and cites two achievements, but says nothing about what happens when candidate_name or hiring_manager is null, whether the output is generated text or a file, or whether it is persisted. For a generation tool with zero annotation coverage, that is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the key constraint front-loaded; no filler. It is arguably too terse rather than bloated, which costs it little here but leaves the definition under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation isn't required. But with 0% schema coverage, no annotations, and four required plus two optional parameters, the description leaves too much unspecified for an agent to invoke confidently – notably the role of nullable parameters and any formatting or length expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across six parameters, so the description must compensate. It implies that candidate_profile and job_description drive achievement selection, but says nothing about company_name, job_title, or the two nullable optional parameters (candidate_name, hiring_manager) and how they affect the letter's salutation or personalization.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (draft) and resource (cover letter) plus a notable constraint (short, citing two most relevant achievements). However, it doesn't distinguish this from the closely related sibling tailor_resume or clarify its place in the prepare_job_application workflow. Purpose is understandable but sibling differentiation is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no prerequisites, and no alternatives named. An agent must infer from sibling names (tailor_resume, prepare_job_application) whether to call this tool or those; the description offers no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full description, criteria and open/closed status for a job ID (LinkedIn) or any posting URL.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id_or_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The 'get' verb and stated return content (description, criteria, status) imply a safe read, and the accepted-input note is useful, but there is no disclosure of rate limits, auth requirements, or error behavior for missing/invalid IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that states the return content before the input constraint, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, and the one parameter is well clarified. The only real gap is the absence of explicit routing guidance relative to search_jobs, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is undocumented in the schema, so the description must compensate. It does so well by clarifying that job_id_or_url accepts either a LinkedIn job ID or any posting URL, which meaningfully extends the bare parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (get) and resource (job details) plus the specific fields returned: full description, criteria, and open/closed status. It is distinguishable from search_jobs since it operates on a known job ID or URL rather than performing a search, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool takes a job ID or posting URL, so an agent knows it's for looking up an already-known job. However there is no explicit when-to-use guidance or condition selecting it over search_jobs or evaluate_job_fit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Indicative junior/mid/senior annual salary bands for a role in US, EU, UK, Türkiye or remote.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | ||
| location | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose that figures are 'indicative' (approximate, not authoritative) and that output is split into three seniority bands across a fixed location set. It says nothing about currency, data freshness, or what a missing location yields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with zero filler, front-loading the returned data and its dimensionality (seniority levels, locations) before the scoping qualifiers. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure needn't be described, and the data scope is clear. But for a compensation tool the currency basis (local vs. USD) and the behavior of the default-null location are meaningful omissions an agent would want before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does enumerate the accepted location values (US, EU, UK, Türkiye, remote) — a constraint absent from the schema's free-form string — but gives no format guidance for 'role' and does not explain what happens when the nullable location is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource precisely — junior/mid/senior annual salary bands — and scopes it by role and location, so an agent can tell it apart from the job-search, fit-evaluation and application siblings. It is a noun phrase without an explicit verb, but 'Lookup' in the name plus the stated data content makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus siblings such as search_jobs or evaluate_job_fit, no prerequisites, and no exclusions. The only usage signal is implicit in the data it returns (e.g., useful when assessing compensation for a posting), which the agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One call: fetch the posting, score fit, tailor the resume and draft the cover letter.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id_or_url | Yes | ||
| candidate_name | No | ||
| candidate_profile | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral-disclosure burden. It lists the pipeline steps but does not say whether documents are saved, whether profile data is modified, what permissions are needed, or how partial failures are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that enumerates the four pipeline actions without filler. Every phrase contributes to explaining the composite operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a multi-step composite tool with no annotations and 0% schema parameter coverage, so the description should do more to explain orchestration behavior and parameter expectations. The output schema reduces the need to describe return values, but the description still leaves important operational context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters, and the description does not explain job_id_or_url, candidate_profile, or the optional candidate_name. Parameter names imply some meaning, but the description does not compensate for the missing schema documentation, especially for the format and content expected in candidate_profile.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific composite operation: fetch a posting, score fit, tailor a resume, and draft a cover letter in one call. It distinguishes the tool as a one-call orchestration rather than a single-step job search or document tool, though it does not explicitly name which sibling tools it replaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "One call" implies this should be used when the agent wants the full application-preparation pipeline in a single step. However, it gives no explicit guidance on when to use this instead of the individual siblings such as evaluate_job_fit, tailor_resume, or generate_cover_letter, nor does it state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search open job postings.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per portal (1-25). | |
| query | Yes | Keywords, e.g. "senior project manager". | |
| portal | No | linkedin, himalayas, remote_co, careerhound, hiredchina, kariyer, or all. | all |
| location | No | City/country or "Remote" (used by LinkedIn). | Remote |
| workplace | No | Optional LinkedIn filter: remote, hybrid or onsite. | |
| max_age_days | No | Only postings from the last N days (default 14) to skip stale listings. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only says 'open job postings.' It does not disclose that the tool queries multiple external portals, whether results are aggregated or deduplicated, authentication requirements, rate limits, or error behavior across portals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. However, its extreme brevity borders on under-specification rather than optimal conciseness for a multi-portal search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, queries multiple named job portals, and has an output schema, but the description does not mention multi-portal behavior, result aggregation, or freshness semantics. While the schema and output schema carry substantial detail, the description leaves key operational context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all six parameters, including portal options, limit per portal, and max_age_days. The description adds no additional parameter meaning, which is acceptable given the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Search open job postings.' This distinguishes it from sibling tools like get_job_details or evaluate_job_fit, but it does not explicitly mention those alternatives or clarify the boundary between searching and retrieving details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It merely restates the purpose, leaving the agent to infer that this is the entry point for job discovery before using get_job_details or evaluate_job_fit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-rank the candidate's own CV bullets by relevance to the job, list matched/missing keywords, and flag bullets that need a metric. Returns Markdown (feed it to export_to_docx).
| Name | Required | Description | Default |
|---|---|---|---|
| target_role | No | ||
| candidate_cv | Yes | ||
| target_company | No | ||
| job_description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the output format and next tool, but says nothing about whether the operation is read-only, whether it mutates or stores anything, permission requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact clauses with no wasted words. It front-loads the core purpose and then adds the return format and downstream handoff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The existence of an output schema reduces the need to explain return values, and the description does note Markdown output. However, for a four-parameter tool with no annotations and 0% schema description coverage, the missing explanation of target_role/target_company and side effects leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It only loosely maps 'candidate's own CV' and 'job' to candidate_cv and job_description, and does not explain target_role or target_company at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names specific operations: re-ranking CV bullets, listing matched/missing keywords, and flagging bullets needing metrics. This clearly distinguishes it from sibling tools like generate_cover_letter or evaluate_job_fit, though it does not explicitly name or contrast those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives workflow guidance by stating the output is Markdown and should be fed to export_to_docx, which implies a downstream step. However, it does not explain when to choose this tool over evaluate_job_fit, generate_cover_letter, or prepare_job_application, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage the applications CSV (job_applications.csv in the output folder).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| notes | No | ||
| action | No | "add", "update" (status/notes) or "list". | list |
| job_id | No | Job ID or URL (used as the key; or use company + role). | |
| portal | No | ||
| salary | No | ||
| status | No | saved, applied, interviewing, offer, rejected, withdrawn. | applied |
| company | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the CSV file location but does not explain mutation behavior, duplicate handling, key requirements, permissions, or what happens to existing rows when adding or updating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It is appropriately concise, though its brevity contributes to the missing operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an eight-parameter tool with no annotations and only partial schema descriptions, the description is too thin. It mentions the CSV file but omits the add/update/list workflow, keying strategy, and side effects, leaving the agent to infer core behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, so the description needed to compensate for undocumented parameters. Instead it adds no meaning for parameters such as role, notes, portal, salary, or company, and does not explain how job_id/company+role are used as keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a general resource (applications CSV at job_applications.csv in the output folder) but uses the vague verb 'manage'. It does not clarify whether this primarily tracks, creates, updates, or lists applications, nor does it distinguish the tool from siblings like prepare_job_application or search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The schema exposes an 'action' parameter with add/update/list modes, but the description does not mention these modes or routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0evaluate_job_fitexport_to_docxgenerate_cover_letterget_job_detailslookup_salary_benchmarkprepare_job_applicationsearch_jobstailor_resumetrack_applicationScored across 9 tools
Most tools have distinct purposes, but prepare_job_application overlaps heavily with get_job_details, evaluate_job_fit, tailor_resume, and generate_cover_letter by bundling them into one workflow shortcut. Agents may be unsure whether to call the composite tool or the granular tools for a given request, though the descriptions make the tradeoff reasonably clear.
All tool names use snake_case and follow a predictable verb_noun or verb_noun_phrase pattern, such as search_jobs, get_job_details, evaluate_job_fit, and generate_cover_letter. export_to_docx is a minor phrasing variation but still fits the consistent imperative naming style.
Nine tools are well-scoped for a job-search and application-preparation server, with each major workflow step represented. The count is neither thin nor sprawling, and the composite tool does not inflate the surface excessively.
The surface covers the core lifecycle: search jobs, inspect details, evaluate fit, tailor resume, generate cover letter, export documents, track applications, and benchmark salary. Minor gaps remain around richer application tracking operations and explicit candidate-profile management, but agents can work around them.
Tailor resumes, score ATS fit, find hiring leads, and send cold outreach, from your agent.
AI job search MCP — fact-checked jobs, application tracker, alerts. ChatGPT, Claude, Cursor.
A job-search companion: tailor your CV to a role, score fit, fix ATS issues. Also via MCP.
Analyze job listings against your resume, track applications, and generate cover letters.
