Which integrations are available for this server?

Provides tools for managing job applications in a Notion database, including creating a Job List database, logging applications, and updating application statuses.

How do I use JobPilot MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JobPilot MCP Search for remote React developer jobs and score my 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.

JobPilot MCP

by TheCodeDaniel

Overview Schema Related Servers Score Discussions

TypeScript

Local

JobPilot MCP 🚀

Your AI-Powered Job Hunting Agent — Built for the Notion MCP Challenge 2026

"I built this because I needed it myself. As a developer actively searching for remote work, I was spending hours searching, copy-pasting, writing cover letters, and forgetting to follow up. JobPilot automates the grind so I can focus on what matters — actually getting hired."
— Daniel A., THECODEDANIEL

What is JobPilot?

JobPilot is a custom MCP (Model Context Protocol) server that turns Claude into a full AI job-hunting assistant. You paste your CV once, and Claude can:

Search remote job boards (RemoteOK, We Work Remotely, Himalayas) for relevant roles
Score each job against your CV (0–100 fit score with matched/missing skills)
Generate a tailored cover letter for every job — in your tone
Log every application automatically to a Notion Job Tracker database
Track status changes (Applied → Interview → Offer) directly in Notion
Draft follow-up emails when a company goes quiet
Auto-apply to jobs using browser automation (Playwright)

Everything is human-in-the-loop — Claude proposes, you decide, Notion remembers.

Related MCP server: job-search-mcp

Architecture

You (Claude Desktop)
      │
      ▼
┌─────────────────────┐
│   JobPilot MCP       │  ← This repo
│   (Node.js server)  │
└──────┬──────────────┘
       │
  ┌────┴──────────────────────────┐
  │                               │
  ▼                               ▼
Job Board APIs              Notion API
(RemoteOK, WWR,            (Job Tracker DB
 Himalayas, Jobicy)         read & write)
       │
       ▼
Playwright (Chromium)
(Browser automation for
 auto-apply form filling)

The 9 MCP Tools

Tool	What it does
`setup_notion_db`	One-time setup — creates the Job List DB in Notion with the correct schema
`parse_cv`	Extracts your profile from CV text (plain text only — see Limitations)
`search_jobs`	Searches RemoteOK, WeWorkRemotely, and Himalayas for matching roles
`score_job_fit`	Scores how well you match each job (0–100) with gap analysis
`generate_cover_letter`	Writes a personalised cover letter (professional / enthusiastic / concise)
`generate_follow_up`	Drafts a follow-up email scaled to how long since you applied
`log_to_notion`	Creates a row in your Notion Job Tracker with all details
`update_application_status`	Updates status in Notion (Applied → Interview → Offer)
`auto_apply`	Full pipeline: search → score → cover letter → browser apply → Notion log

Known Limitations & What's Not Fully Implemented

This is important to read before using JobPilot so you know what to expect.

PDF parsing does not work

parse_cv accepts a file_path argument but reads the file as plain UTF-8 text. Binary PDF files will produce garbled output. Pass your CV as plain text using cv_text instead. Copy-paste from your word processor or export as .txt first.

No Anthropic API calls are made

Despite the .env.example including ANTHROPIC_API_KEY, the key is never used. CV parsing, fit scoring, and cover letter generation are all done with local regex and string-matching logic — not the Anthropic API. The ANTHROPIC_API_KEY environment variable is currently a placeholder for a future implementation. You do not need it to run JobPilot.

The `location` filter in `search_jobs` is ignored

The tool accepts a location parameter but does not pass it to any of the job board APIs. All results are unfiltered by location. Treat this as a remote-first search.

WeWorkRemotely only covers 3 categories

Job roles are mapped to one of: design, marketing, or programming. Roles like data scientist, devops engineer, or product manager all fall through to programming, which may return irrelevant listings.

Role matching uses a small keyword expansion map

The RELATED_TAGS map only covers: flutter, mobile, react, ios, android. All other roles rely on exact keyword matching against job titles and tags. If you search for TypeScript developer, only jobs with "typescript" in the title or tags will match — no synonyms are expanded.

Browser automation opens a visible window

auto_apply launches Chromium with headless: false, meaning a real browser window opens on your screen during auto-apply. This is intentional for transparency but may be surprising. Do not close it while a pipeline is running.

LinkedIn field is not extracted from CV

The auto_apply pipeline attempts to fill LinkedIn fields in job application forms, but the CandidateProfile type does not include a linkedin field. The field is always left blank.

Environment variables are not loaded from `.env` when testing directly

The .env file is only read by Claude Desktop (you pass the values in the MCP config). When running or testing the server outside Claude Desktop, you must set the environment variables manually in your shell. See the Testing section below.

Notion Database Schema

You do not need to create this manually. Run the setup_notion_db tool once and it creates everything for you.

The database ("Job List DB") is created with these columns:

Column Name	Type	Notes
Job Title	Title	Primary column
Company	Text
Job URL	URL	Used for duplicate detection in auto_apply
Status	Text	Applied, Pending, Interview, Rejected, or Offer
Date Applied	Date
Salary	Text	If available
Fit Score	Number	AI-generated 0–100
Cover Letter Snippet	Text	First 300 chars of letter
Last Updated	Date	Updated on status changes
Notes	Text	Any extra context

Setup Guide

Prerequisites

You need the following installed before starting:

Tool	Version	Download
Node.js	18 or higher	https://nodejs.org (choose LTS)
Git	Any recent version	https://git-scm.com
Claude Desktop	Latest	https://claude.ai/download
A Notion account	—	https://notion.so

To confirm Node.js and Git are installed, open a terminal and run:

node --version   # should print v18.x.x or higher
git --version    # should print git version x.x.x

If either command says "command not found", install the tool from the links above before continuing.

Step 1 — Clone, install & build

Open a terminal and run:

git clone https://github.com/YOUR_USERNAME/jobpilot-mcp.git
cd jobpilot-mcp
npm install
npm run build

After npm run build you should see a dist/ folder created. If you get TypeScript errors, make sure Node.js 18+ is installed.

To get the full path to this folder (you will need it in Step 3):

# macOS / Linux
pwd

# Windows (PowerShell)
Get-Location

Step 2 — Set up Notion

Go to notion.so/my-integrations
Click New Integration → name it JobPilot
Set capabilities: Read content, Update content, Insert content
Click Submit and copy the Internal Integration Token (starts with secret_...)
In Notion, create a blank page — this is where the database will live
Open that page → click Share → Invite → search for JobPilot → click Invite
Copy the Page ID from the page URL. It is the 32-character string in the URL:
```
https://notion.so/yourworkspace/My-Page-<PAGE_ID_HERE>?v=...
```
The Page ID is everything after the last - and before ?. It looks like: a1b2c3d4e5f6...

You will use the integration token and page ID in the next step.

Step 3 — Configure Claude Desktop

Locate (or create) the Claude Desktop config file:

Operating System	Config file path
macOS	`~/Library/Application Support/Claude/claude_desktop_config.json`
Windows	`%APPDATA%\Claude\claude_desktop_config.json`
Linux	`~/.config/Claude/claude_desktop_config.json`

Open or create the file:

# macOS
open -a TextEdit ~/Library/Application\ Support/Claude/claude_desktop_config.json
# If that fails (file doesn't exist yet):
mkdir -p ~/Library/Application\ Support/Claude && touch ~/Library/Application\ Support/Claude/claude_desktop_config.json && open -a TextEdit ~/Library/Application\ Support/Claude/claude_desktop_config.json

# Linux
mkdir -p ~/.config/Claude
nano ~/.config/Claude/claude_desktop_config.json

# Windows (PowerShell)
New-Item -ItemType Directory -Force -Path "$env:APPDATA\Claude" | Out-Null
notepad "$env:APPDATA\Claude\claude_desktop_config.json"

Paste the following into the file, replacing all placeholder values:

{
  "mcpServers": {
    "jobpilot": {
      "command": "node",
      "args": ["/FULL/PATH/TO/jobpilot-mcp/dist/index.js"],
      "env": {
        "NOTION_API_KEY": "secret_...",
        "NOTION_DATABASE_ID": ""
      }
    }
  }
}

Replace /FULL/PATH/TO/jobpilot-mcp with the output of pwd from Step 1.

Already have other MCP servers? Add the "jobpilot": { ... } block inside your existing "mcpServers" object — don't replace the whole file.

Note: NOTION_DATABASE_ID can be left blank for now. You will fill it in after Step 4.

Step 4 — Restart Claude Desktop & create the Notion database

Fully quit Claude Desktop (not just close the window — use Quit from the menu)
Reopen Claude Desktop
Select the Chat tab and look for the tools icon in the chat input bar — click it to confirm all 9 JobPilot tools are listed

Then ask Claude to set up your Notion database:

Run setup_notion_db with parent_page_id YOUR_PAGE_ID_HERE

The tool will return a database_id. Copy it, then go back to your Claude Desktop config file, paste it as NOTION_DATABASE_ID, and restart Claude Desktop once more.

If NOTION_DATABASE_ID is already set and the database exists, the tool will skip creation safely — so it is safe to run multiple times.

How to Test JobPilot (Without Claude Desktop)

This section is for developers who want to test tools directly without going through Claude Desktop.

Option 1: MCP Inspector (Recommended)

The MCP Inspector is an official browser-based tool for interactively testing any MCP server. It lets you call any tool, pass custom inputs, and see the raw JSON response — no Claude needed.

Install and run:

# From inside the jobpilot-mcp directory
npm run build
npx @modelcontextprotocol/inspector node dist/index.js

This starts a local web server and opens http://localhost:5173 in your browser (or prints the URL if it doesn't open automatically).

Pass your environment variables if you want Notion tools to work:

# macOS / Linux
NOTION_API_KEY=secret_... NOTION_DATABASE_ID=your_db_id npx @modelcontextprotocol/inspector node dist/index.js

# Windows (PowerShell)
$env:NOTION_API_KEY="secret_..."; $env:NOTION_DATABASE_ID="your_db_id"; npx @modelcontextprotocol/inspector node dist/index.js

Using the Inspector UI:

Click Connect — the server status should turn green
Click Tools in the left sidebar — all 9 JobPilot tools appear
Click any tool (e.g. search_jobs) to expand it
Fill in the input fields and click Run Tool
The JSON response appears on the right

Example inputs to try:

search_jobs:

{
  "role": "Flutter Developer",
  "max_results": 5
}

parse_cv:

{
  "cv_text": "John Smith\njohn@example.com\n+1 555 000 1234\n\nSkills\nFlutter, Dart, Firebase, REST APIs\n\nExperience\nSenior Flutter Developer at Acme Corp\n2021 – Present\n\nFlutter Developer at Startup Inc\n2019 – 2021\n\nEducation\nBSc Computer Science, University of Lagos"
}

score_job_fit:

{
  "candidate_profile": {
    "name": "John Smith",
    "email": "john@example.com",
    "phone": "+1 555 000 1234",
    "location": "Lagos, Nigeria",
    "summary": "Mobile developer with 5 years Flutter experience",
    "skills": ["Flutter", "Dart", "Firebase", "REST APIs"],
    "experience": [
      { "title": "Senior Flutter Developer", "company": "Acme Corp", "start": "2021", "end": "present" },
      { "title": "Flutter Developer", "company": "Startup Inc", "start": "2019", "end": "2021" }
    ],
    "years_experience": 5,
    "education": [
      { "degree": "BSc Computer Science", "institution": "University of Lagos" }
    ]
  },
  "job": {
    "id": "test-001",
    "title": "Senior Flutter Engineer",
    "company": "Remote First Inc",
    "url": "https://example.com/jobs/flutter",
    "description": "We need a Flutter expert with 3+ years experience. Must know Dart, Firebase, and REST APIs. Remote position.",
    "tags": ["flutter", "dart", "remote"],
    "date_posted": "2026-03-22",
    "source": "test"
  }
}

Option 2: Smoke-test the MCP protocol directly

Send a raw MCP message via stdin to verify the server starts and responds correctly:

npm run build

# macOS / Linux
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | node dist/index.js

# Windows (PowerShell)
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | node dist/index.js

You should see a JSON response listing all 9 tools. If the server crashes or prints nothing, check your Node.js version with node --version.

How to Use JobPilot (in Claude Desktop)

Full Workflow

Paste this into Claude Desktop:

Here is my CV:

[paste your full CV as plain text — not PDF]

Please:
1. Parse my CV to extract my profile
2. Search for remote Flutter Developer jobs
3. Score the top 5 results against my profile
4. For any job with a fit score above 65, generate a professional cover letter
5. Log each application to my Notion Job Tracker

Claude will run the full pipeline automatically, logging everything to Notion as it goes.

Individual Commands

Parse your CV:

Parse my CV and extract my profile.
[paste CV text]

Search for jobs:

Search for remote Flutter developer jobs. Show me the top 10.

Score a specific job:

Score how well my profile matches the Senior Flutter Engineer role at Acme Corp.
[paste job description]

Generate a cover letter:

Write an enthusiastic cover letter for the Flutter Engineer role at Stripe.

Log to Notion manually:

Log this application to Notion:
- Job: Senior Flutter Developer
- Company: Shopify
- URL: https://shopify.com/careers/123
- Salary: $120,000/yr
- Status: Applied
- Fit Score: 82

Update an application status:

Update my Shopify application status to "Interview". Add a note: "Interview scheduled for March 25 at 2pm."

Generate a follow-up email:

Generate a follow-up email for my Flutter Engineer application at Stripe. It's been 9 days since I applied.

Auto-Apply Workflow

The most powerful feature of JobPilot. Run the full job application pipeline with a single command.

What it does:

Searches for remote jobs matching your role across multiple job boards
Scores each job against your CV (only applies to jobs scoring >= min_fit_score)
Generates a tailored cover letter for each qualifying job
Fills and submits application forms automatically using a Chromium browser window
Logs every application to your Notion tracker with status, score, and cover letter

Example usage in Claude:

Parse my CV, then auto-apply to 10 Flutter Developer jobs today

Supported application methods:

Easy Apply / Quick Apply buttons
Greenhouse ATS forms
Lever ATS forms
Workable ATS forms
BambooHR ATS forms
Generic form fill (best-effort)

When it skips a job:

CAPTCHA detected
Login/account creation required
Already applied (duplicate detected in Notion)
Form too complex (more than 3 steps)

Skipped jobs are logged to Notion as "Pending" for manual follow-up.

Dry run mode: Set dry_run: true to run the full pipeline (search → score → cover letter → log) without actually submitting any forms. Useful for previewing what would be applied to.

Safety:

Never enters financial information
Never creates accounts or passwords
Never applies to the same job twice
Takes a screenshot after each submission as proof (saved to screenshots/)

Example Notion Output

After running the full pipeline, your Notion Job Tracker will look like this:

Job Title	Company	Status	Fit Score	Salary	Date Applied
Senior Flutter Engineer	Shopify	Applied	88	$120k/yr	2026-03-19
Mobile Developer	Buffer	Applied	74	Not listed	2026-03-19
Flutter Dev (Remote)	Remote First Inc	Pending	61	$80–100k	2026-03-19

Each row links back to the full cover letter snippet and notes.

Project Structure

jobpilot-mcp/
├── src/
│   ├── index.ts                        # MCP server + tool registry
│   └── tools/
│       ├── parseCV.ts                  # CV parsing (plain text only)
│       ├── searchJobs.ts               # RemoteOK + WeWorkRemotely + Himalayas APIs
│       ├── scoreJobFit.ts              # Fit scoring (0–100, keyword-based)
│       ├── generateCoverLetter.ts      # Cover letter generation (template-based)
│       ├── generateFollowUp.ts         # Follow-up email drafting
│       ├── logToNotion.ts              # Create row in Notion DB
│       ├── updateApplicationStatus.ts  # Update existing Notion row
│       ├── setupNotionDB.ts            # Create the Notion database schema
│       └── autoApply.ts               # Full auto-apply pipeline with Playwright
├── dist/                               # Compiled output (after npm run build)
├── .env.example                        # Environment variable template
├── package.json
├── tsconfig.json
└── README.md

Tech Stack

Runtime: Node.js 18+ with TypeScript
MCP SDK: @modelcontextprotocol/sdk (official Anthropic SDK)
Job scoring & cover letters: Local string-matching logic (no external AI API required)
Job data: RemoteOK API + WeWorkRemotely RSS + Himalayas API (all free, no auth required)
Browser automation: Playwright (Chromium) for auto-apply form filling
Storage: Notion REST API v1 (2022-06-28)
Host: Claude Desktop

Roadmap / Future Ideas

Auto-apply with browser automation via Playwright (Easy Apply, ATS forms, generic forms)
Real AI-powered CV parsing using the Anthropic API (replace regex parser)
Real AI-generated cover letters via Anthropic API (replace template engine)
Actual PDF parsing support (e.g. using pdf-parse or similar)
LinkedIn field extraction from CVs
Expand RELATED_TAGS to cover more tech domains (DevOps, data, product, design)
WeWorkRemotely category mapping for more job types
location filter actually applied to job board API queries
Daily digest: "You have 3 applications with no response after 14 days"
Salary negotiation email generator
Interview prep notes auto-added to Notion page
Slack/Email notification when a Notion status changes

License

MIT — free to use, fork, and build on.

Author

Built by Daniel A. — THECODEDANIEL.

This tool was built for the Notion MCP Challenge 2026 — and also because I genuinely needed it. Job hunting is brutal. Let AI do the boring parts.

Available Tools

11 tools

auto_applyA

Automatically search, score, generate cover letters, and apply to N remote jobs matching the candidate profile. Uses browser automation (Playwright) to fill and submit application forms. Logs all applications to Notion.

ParametersJSON Schema

Name	Required	Description
`role`	Yes	Job role to search and apply for, e.g. "Flutter Developer"
`tone`	No	Tone for generated cover letters (default: professional)
`dry_run`	No	If true, runs the full pipeline (search, score, cover letter, log) but skips actual form submission
`min_fit_score`	No	Minimum fit score to apply (default 65, 0-100)
`max_applications`	No	Maximum number of jobs to apply to (default 5, max 20)
`candidate_profile`	Yes	Structured candidate profile from parse_cv

TDQS

A3.8/5.0

Behavior3/5

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

The description discloses use of browser automation (Playwright) and logging to Notion, and mentions the dry_run parameter skips submission. However, it lacks disclosure of potential side effects like state changes from applications, time consumption, rate limits, or authorization needs. With no annotations, the description carries the full burden but is only partly transparent.

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 two sentences that front-load purpose and key behaviors. It is concise without being terse, though it could be more structured (e.g., listing steps). Every sentence adds value.

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

Completeness3/5

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

The description does not explain what the tool returns (no output schema), nor does it specify the job source (assumes remote jobs from some search). For a complex tool with 6 parameters, this is a notable gap. It partially compensates by mentioning Notion logging.

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%, but the description adds valuable context beyond schema: it explains that candidate_profile should come from parse_cv, dry_run skips submission, and min_fit_score/max_applications govern behavior. This enhances parameter understanding.

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 uses specific verbs ('Automatically search, score, generate cover letters, and apply') and a clear resource ('N remote jobs matching the candidate profile'). It clearly distinguishes itself from sibling tools like search_jobs, score_job_fit, and generate_cover_letter by being a composite end-to-end pipeline.

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?

While the description implies this tool is for full automation, it does not explicitly state when to use it versus using the individual sibling tools (e.g., search_jobs, score_job_fit, indeed_apply). No when-not or alternative guidance is provided.

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

generate_cover_letterB

Generate a tailored, professional cover letter for a specific job based on the candidate profile.

ParametersJSON Schema

Name	Required	Description
`job`	Yes	Job listing object
`tone`	No	Tone of the cover letter (default: professional)
`candidate_profile`	Yes	Structured candidate profile from parse_cv

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It states the tool generates a letter but does not mention whether it saves data, modifies anything, or requires specific permissions. The output format is not described, leaving uncertainty about the tool's behavior beyond generation.

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 concise sentence with no unnecessary wording. It is front-loaded with the key action. However, it is very brief and could include more detail without losing conciseness.

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

Completeness2/5

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

The tool has nested objects and no output schema. The description does not explain what the return value is (e.g., a string of the cover letter) or any constraints on the input objects. For a moderately complex tool, this is insufficient to fully guide an agent.

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 coverage is 100%, so the input schema already documents all parameters. The description adds no extra meaning beyond the schema's descriptions of 'candidate_profile', 'job', and 'tone'. The baseline of 3 is appropriate since the schema carries the semantic load.

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

Purpose4/5

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

The description clearly identifies the tool's function: generating a cover letter for a specific job based on a candidate profile. The verb 'generate' and resource 'cover letter' are specific. However, it does not differentiate from sibling tools like 'generate_follow_up' or 'auto_apply', which have distinct purposes.

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?

The description implies usage when a cover letter is needed, but it lacks explicit context on when to use this tool versus alternatives. No exclusions or alternatives are mentioned, making the guidance adequate but minimal.

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

generate_follow_upB

Generate a professional follow-up email for an application that has not received a response.

ParametersJSON Schema

Name	Required	Description
`job_title`	Yes
`company_name`	Yes
`application_id`	No	Notion page ID of the application (for reference)
`candidate_name`	Yes
`days_since_applied`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the tool generates an email, but fails to mention whether it sends it, the output format, or any side effects. This leaves significant ambiguity for the agent.

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, front-loaded sentence with no wasted words. However, it lacks structure (e.g., separating purpose from behavior). It is concise but minimally adequate.

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

Completeness2/5

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

Given the tool has 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the tool returns (e.g., email text, draft), nor does it clarify parameter details beyond the schema. The agent would need to infer or experiment.

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

Parameters2/5

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

With only 20% schema coverage (only application_id has a description), the description does not add meaning to parameters like days_since_applied or candidate_name. It does not compensate for the low schema coverage, leaving parameter semantics unclear.

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 generates a follow-up email for an application without a response. It uses a specific verb ('generate') and resource ('follow-up email'), and distinguishes from sibling tools like auto_apply or generate_cover_letter, which have different purposes.

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?

The description implies usage for applications lacking a response, but provides no explicit guidance on when to use versus alternatives, nor any 'when not to use' or prerequisite conditions. This is minimal guidance.

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

indeed_applyA

Search Indeed for jobs and auto-apply using Indeed's native 'Easily Apply' flow. Uses a persistent browser session — on first run the user logs in manually; all subsequent runs reuse the saved session. Each application result includes a 'confirmed' flag, confidence level, confirmation message, and a screenshot path so you can verify every submission.

ParametersJSON Schema

Name	Required	Description
`role`	Yes	Job role to search for, e.g. "Flutter Developer"
`tone`	No	Cover letter tone (default: professional)
`remote`	No	Filter for remote jobs only (default: true)
`dry_run`	No	Open forms but do not submit — for previewing the pipeline
`job_type`	No	Job type filter (default: full_time)
`location`	No	Search location (default: "Remote")
`salary_min`	No	Minimum annual salary filter (optional)
`min_fit_score`	No	Minimum fit score to apply (default: 60, range 0-100)
`date_posted_days`	No	Only show jobs posted within this many days (default: 7)
`max_applications`	No	Maximum number of jobs to apply to (default: 10, max 20)
`candidate_profile`	Yes	Structured candidate profile from parse_cv
`indeed_apply_only`	No	Only show jobs with Indeed's native apply flow (default: true)

TDQS

A4/5.0

Behavior3/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 the persistent browser session and login requirement, and describes the output fields. However, it omits potential behavioral issues like rate limits, risk of detection, or that it only works for 'Easily Apply' jobs. This is adequate but not comprehensive.

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 sentences, front-loaded with the core function, then behavioral detail, then output description. No wasted words; every sentence adds value. It is concise yet informative.

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 complexity (12 parameters, no output schema), the description covers the main workflow and output. It explains the browser session lifecycle and what results include. However, it could be more complete by explaining how dry_run affects other parameters or error handling. It is mostly complete but has minor gaps.

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 all 12 parameters have descriptions in the schema. The description does not add significant new meaning beyond the schema. It hints that candidate_profile comes from parse_cv, which adds context, but overall the parameters are sufficiently documented in the schema. Baseline score of 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 searches Indeed and auto-applies using Indeed's native 'Easily Apply' flow. The verb 'search' and 'auto-apply' combined with specific resource 'Indeed' makes the purpose explicit. It distinguishes itself from siblings like 'linkedin_apply' (different platform) and 'auto_apply' (general vs platform-specific).

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 provides clear context: it's for Indeed's 'Easily Apply' flow, mentions the persistent browser session and first-time manual login. However, it does not explicitly state when NOT to use this tool (e.g., if the job doesn't have Easily Apply) or mention alternatives like 'search_jobs' for broader searching. The usage is implied but lacks explicit exclusions.

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

linkedin_applyA

Search LinkedIn for jobs and auto-apply using Easy Apply. Uses a persistent browser session — on first run the user logs in manually; all subsequent runs reuse the saved session. Each application result includes a 'confirmed' flag, confidence level, confirmation message, and a screenshot path so you can verify every submission.

ParametersJSON Schema

Name	Required	Description
`role`	Yes	Job role to search for, e.g. "Flutter Developer"
`tone`	No	Cover letter tone (default: professional)
`remote`	No	Filter for remote jobs only (default: true)
`dry_run`	No	Open forms but do not submit — for previewing the pipeline
`location`	No	Search location (default: "Worldwide")
`job_types`	No	Job types to filter by (default: [full_time])
`date_posted`	No	How recently the job was posted (default: week)
`min_fit_score`	No	Minimum fit score to apply (default: 60, range 0-100)
`easy_apply_only`	No	Only apply to Easy Apply jobs (default: true)
`max_applications`	No	Maximum number of jobs to apply to (default: 10, max 20)
`candidate_profile`	Yes	Structured candidate profile from parse_cv
`experience_levels`	No	Experience levels to filter by (default: [entry, associate, mid_senior])

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 persistent browser session, manual login first time, and returns confirmed flag, confidence, message, and screenshot path. It does not mention potential failure modes or rate limits, but covers key behavioral aspects.

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 sentences, well-structured, and front-loaded with the main action. Every sentence adds value: purpose, session behavior, and return details. No wordiness.

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?

The description explains the return value (confirmed flag, confidence, message, screenshot path) despite no output schema. Parameters are well-documented in schema. It could mention what happens if no jobs are found or fallback behavior, but overall it is sufficiently complete.

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 coverage is 100%, so the baseline is 3. The tool description adds no extra parameter information beyond what is already in the input schema. It mentions filters like 'remote' and 'dry_run' but does not provide additional semantic detail.

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 searches LinkedIn jobs and auto-applies using Easy Apply. It distinguishes itself from siblings like 'search_jobs' (search only) and 'indeed_apply' (different platform). The verb 'auto-apply' and resource 'LinkedIn jobs with Easy Apply' are specific.

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 the first-run login process and reuse of the browser session, providing context on when to use. However, it does not explicitly state when not to use this tool versus alternatives like 'auto_apply' or 'search_jobs'. Still, the usage scenario is clear enough.

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

log_to_notionC

Log a job application to the Notion Job Tracker database with full details.

ParametersJSON Schema

Name	Required	Description
`notes`	No	Any extra notes
`salary`	No	Salary/rate if available
`status`	Yes	Current application status
`job_url`	Yes
`fit_score`	No	AI fit score 0-100
`job_title`	Yes
`company_name`	Yes
`cover_letter_snippet`	No	First 300 chars of the generated cover letter

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It does not disclose behavioral traits such as that it is a write operation, requires authentication, or how it handles duplicates. 'Full details' is vague.

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 sentence, which is concise. For a tool with 8 parameters, it could be slightly longer but is not overly verbose.

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

Completeness2/5

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

Given the tool has 8 parameters, 4 required, no output schema, and no annotations, the description is insufficient. It does not explain return values, error handling, or the need for prior setup (sibling 'setup_notion_db' hints at this).

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

Parameters2/5

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

With 63% schema description coverage, the description adds no meaning beyond the schema. It does not explain how parameters map to the Notion database fields or that it inserts a new row. The phrase 'full details' does not compensate.

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

Purpose4/5

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

The description 'Log a job application to the Notion Job Tracker database with full details' clearly specifies the verb (log) and the resource (job application to Notion database). It is distinct from sibling 'update_application_status' which implies modifying existing records, though it could explicitly state that it creates a new entry.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'update_application_status'. The description lacks any context about prerequisites or scenarios for use.

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

parse_cvA

Parse a CV/resume (PDF path or raw text) and extract a structured candidate profile: name, skills, years of experience, job titles, education, and a short bio summary.

ParametersJSON Schema

Name	Required	Description	Default
`cv_text`	No	Raw text content of the CV/resume
`file_path`	No	Absolute path to a PDF CV/resume file

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral burden. It mentions handling PDF path or raw text and extracting fields, but does not disclose error behavior (e.g., invalid file path), performance characteristics, rate limits, or whether the operation is read-only. Essential behavioral details are missing.

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 a single, front-loaded sentence that efficiently conveys the tool's function and output. Every word adds value, with no redundancy or unnecessary information.

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 (2 parameters, no output schema, no annotations), the description provides enough context for basic usage. It explains inputs and outputs. However, it could be more complete by specifying that exactly one of the two parameters is required and by mentioning error handling.

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 baseline is 3. The description adds context ('PDF path or raw text') but does not significantly enhance parameter understanding beyond the schema's descriptions. Both parameters are already well-documented in the schema.

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: 'Parse a CV/resume (PDF path or raw text) and extract a structured candidate profile.' It specifies the verb (Parse), resource (CV/resume), and output fields (name, skills, etc.). Additionally, it distinguishes itself from sibling tools, none of which parse CVs.

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?

The description implies usage: use this tool to extract structured data from a CV. However, it does not explicitly state when not to use it, nor does it mention alternative tools (e.g., score_job_fit might also process CVs). The guidance is adequate but lacks exclusion criteria.

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

score_job_fitA

Score how well a candidate profile matches a job listing (0–100). Returns a fit score, matched skills, missing skills, and a recommendation.

ParametersJSON Schema

Name	Required	Description	Default
`job`	Yes	Job listing object with title, description, company, salary
`candidate_profile`	Yes	Structured candidate profile from parse_cv

TDQS

A4.2/5.0

Behavior4/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 that the tool returns a numeric score, matched/missing skills, and a recommendation. This is sufficient for a read-only scoring tool, though it doesn't explicitly state that no mutations occur.

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, no redundant information. The first sentence states the core purpose and output range; the second lists return fields. Every word earns its place.

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?

With no output schema, the description adequately covers what is returned. For a simple scoring tool, it provides sufficient context about inputs (parsed CV, job object) and outputs. Minor gap: no explanation of how to interpret the recommendation.

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 clear descriptions. The description adds value by noting that candidate_profile comes from parse_cv, providing cross-tool context. This goes beyond what the schema alone offers.

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 uses a specific verb ('Score'), identifies the resource ('candidate profile matches a job listing'), specifies the output range (0–100), and lists return items. This clearly distinguishes it from sibling tools like auto_apply or generate_cover_letter.

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?

The description implies use after parse_cv and before applying, but it does not explicitly state when to use it over alternatives or provide a when-not scenario. Sibling tools are listed but not contrasted.

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

search_jobsA

Search for open job listings on RemoteOK, We Work Remotely, and Himalayas based on a role keyword and optional filters.

ParametersJSON Schema

Name	Required	Description
`role`	Yes	Job role to search for, e.g. "Flutter Developer"
`location`	No	Location filter, e.g. "Remote" or "Nigeria"
`max_results`	No	Maximum number of jobs to return (default 10)

TDQS

A4/5.0

Behavior3/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 that the tool searches multiple platforms and uses a role keyword with optional filters. However, it does not mention behavioral details such as data freshness, rate limits, or what happens if no results are found.

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 a single, well-structured sentence that conveys all essential information without any extraneous words. It is front-loaded with the main action and specifies the platforms and filters.

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 (3 parameters, 100% schema coverage, no output schema, no nested objects), the description is complete enough. It explains what the tool does and on which platforms. However, it could briefly mention the return format or that results are blended from multiple boards.

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 has 100% coverage for all three parameters, so the baseline is 3. The description adds minimal value beyond the schema, merely stating that the tool uses a role keyword and optional filters. It does not elaborate on parameter constraints or formatting.

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 searches for open job listings on three specific platforms (RemoteOK, We Work Remotely, Himalayas) using a role keyword and optional filters. The verb 'search' and resource 'open job listings' are explicit, and the tool is well-distinguished from sibling tools that focus on applying or generating letters.

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 implies usage for finding jobs based on keywords and filters. While it does not explicitly state when not to use or mention alternatives, the sibling tools are clearly different in purpose (e.g., auto_apply, generate_cover_letter), so the context is clear.

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

setup_notion_dbA

One-time setup: creates the Job List DB in Notion with the correct schema. If NOTION_DATABASE_ID is already set and valid, it skips creation. Run this before using log_to_notion.

ParametersJSON Schema

Name	Required	Description	Default
`parent_page_id`	Yes	The Notion page ID where the database will be created. Copy it from the page URL.

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 carries full burden. It discloses idempotency (skips if already set) and that it creates the DB with correct schema. It does not cover potential errors or side effects, but the key behaviors are 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?

Two sentences, no wasted words. The important action and prerequisite are front-loaded. Very concise and clear.

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 or output schema, the description covers the essential purpose, behavior, and usage. It lacks details on error handling or the exact schema, but these are minor gaps.

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 covers the parameter with 100% coverage. The description adds value by advising to 'Copy it from the page URL', which goes beyond the schema's description.

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 creates the Job List DB in Notion with the correct schema, and it is a one-time setup. It distinguishes from sibling tools like auto_apply, log_to_notion, etc., which have different purposes.

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 says 'Run this before using log_to_notion' and mentions it skips if already set, providing clear guidance on when to use. However, it lacks explicit instructions on when not to use or alternatives.

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

update_application_statusB

Update the status of an existing job application in Notion (e.g. from Applied → Interview).

ParametersJSON Schema

Name	Required	Description
`notes`	No
`new_status`	Yes
`notion_page_id`	Yes	The Notion page ID of the application row

TDQS

B3.1/5.0

Behavior2/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 only states 'Update the status' without disclosing any behavioral traits such as validation, side effects, or required permissions. The lack of detail is insufficient for a mutation 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 a single sentence that concisely states the action and resource with an example. No extraneous words or redundancy.

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

Completeness2/5

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

Given the tool has 3 parameters, no output schema, and no annotations, the description is too brief. It does not address return values, error conditions, or what happens on a successful update. More context is needed for a write operation.

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

Parameters2/5

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

Schema description coverage is only 33% (only notion_page_id has a description). The description adds no parameter-level detail beyond the schema's enum for new_status and does not explain the optional notes parameter. It fails to compensate for the low schema coverage.

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 updates the status of an existing job application in Notion, with an explicit example transition. It is distinct from sibling tools which cover applying, logging, parsing, etc.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or compare with siblings like log_to_notion which might also affect Notion records.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation4/5

Tools have distinct purposes overall, but auto_apply, indeed_apply, and linkedin_apply have overlapping functionality. Descriptions help differentiate, but an agent might still be confused about which apply tool to use.

Naming Consistency4/5

Tool names follow a mostly consistent snake_case pattern with imperative verbs. Minor deviations like 'indeed_apply' vs 'auto_apply' exist, but overall pattern is readable and predictable.

Tool Count5/5

11 tools is well-scoped for a job application automation server. Each tool serves a necessary function without unnecessary redundancy.

Completeness4/5

The tool set covers the main job application workflow, but missing a tool to list or retrieve existing applications from Notion. This is a minor gap that agents could work around.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

FoundRole — AI Job Search & Application Tracker MCP for Claude & ChatGPT A
io.github.foundrole
AI job search MCP — fact-checked jobs, application tracker, alerts. ChatGPT, Claude, Cursor.
Search
2
keywordise A
com.keywordise
Auto-apply to jobs: matches your CV, tailors a fresh CV per posting, and applies for you.
App Automation Autonomous Agents
491
Smart Match
io.github.pkhaninejad
Analyze job listings against your resume, track applications, and generate cover letters.
RAG Systems Search AI & Machine Learning
2
gemsift-mcp
io.github.erashev-fedor
AI resume triage for recruiters. Query your candidate pool from Claude or ChatGPT.
Search CRM AI & Machine Learning
2

Related MCP Servers

Job Search MCP Server
Search
prabhakar1234pr
F
license
Not graded
quality
D
maintenance
Enables Claude to search AI/ML jobs across Greenhouse, Lever, and Adzuna, with resume tailoring and referral outreach assistance.
Updated 6 months ago (2026-03-04 03:52 UTC)
5
job-search-mcp
Search
Servation
A
license
A
quality
B
maintenance
A personal job-search assistant for Claude Desktop that searches real job boards, scores each job 0–100 for fit, and displays a ranked board for fast triage.
Updated 14 days ago (2026-08-21 01:40 UTC)
10
314
2
MIT
cv-job-assistant
Search Web Scraping File Systems
JahidRayhan
F
license
Not graded
quality
C
maintenance
Enables Claude to parse CVs, search job boards (Remotive, Arbeitnow, Adzuna, Greenhouse/Lever), tailor resumes and cover letters, and prepare application packages with direct apply links—without ever auto-submitting. It runs 100% locally and free, storing jobs and applications as JSON files.
Updated 23 days ago (2026-08-12 13:38 UTC)
jobfinder
Search Web Scraping
MajidAli2006
A
license
Not graded
quality
C
maintenance
Enables AI-powered job searching across multiple platforms using natural language or CV uploads, ranking results by shortlisting likelihood and generating detailed spreadsheets. Integrates with Claude to perform full job searches, preview query interpretation, and manage platform configurations.
Updated 4 days ago (2026-08-30 22:29 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheCodeDaniel/jobpilot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

JobPilot MCP 🚀

Your AI-Powered Job Hunting Agent — Built for the Notion MCP Challenge 2026

What is JobPilot?

Architecture

The 9 MCP Tools

Known Limitations & What's Not Fully Implemented

PDF parsing does not work

No Anthropic API calls are made

The location filter in search_jobs is ignored

WeWorkRemotely only covers 3 categories

Role matching uses a small keyword expansion map

Browser automation opens a visible window

LinkedIn field is not extracted from CV

Environment variables are not loaded from .env when testing directly

Notion Database Schema

Setup Guide

Prerequisites

Step 1 — Clone, install & build

Step 2 — Set up Notion

Step 3 — Configure Claude Desktop

Step 4 — Restart Claude Desktop & create the Notion database

How to Test JobPilot (Without Claude Desktop)

Option 1: MCP Inspector (Recommended)

Option 2: Smoke-test the MCP protocol directly

How to Use JobPilot (in Claude Desktop)

Full Workflow

Individual Commands

Auto-Apply Workflow

Example Notion Output

Project Structure

Tech Stack

Roadmap / Future Ideas

License

Author

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

The `location` filter in `search_jobs` is ignored

Environment variables are not loaded from `.env` when testing directly