Searches job listings from Hacker News 'Who is hiring?' threads via the Algolia API.
Click on "Install 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., "@CareerPilot Search for remote Python jobs and save the best three."
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.
An AI job-hunt copilot built on the Model Context Protocol — search live job boards, shortlist openings, track your application pipeline, and generate tailored resumes/cover letters, all from any MCP client (Claude Desktop, Claude Code, MCP Inspector).
Built as a learning project that deliberately exercises every major MCP concept in a real product.
Source | What it is |
Remote job board, free public API | |
Remote job board, free public API | |
Hacker News "Who is hiring?" | Monthly hiring thread, via the free Algolia API |
Your shortlist, applications, and profile live in a local SQLite DB (~/.careerpilot/careerpilot.db).
Related MCP server: Workopia
MCP concept | Where it lives in this project | What it teaches |
Tools |
| Model-callable actions with typed schemas |
Resources |
| App data exposed as readable context |
Resource templates |
| Parameterized URIs |
Prompts |
| Reusable, server-defined prompt workflows |
Sampling |
| Server ↔ LLM inversion; server needs no API key |
Elicitation |
| Mid-tool-call user input |
Roots |
| Filesystem boundaries negotiated with the client |
Subscriptions | pipeline & watches emit | Push notifications to subscribed clients |
Logging & progress |
| Server → client observability |
Background notifications |
| Server-initiated protocol traffic |
Streamable HTTP |
| The production transport |
Authorization | Bearer-token resource server ( | The MCP auth spec's resource-server side |
The client side |
| Handshake, tool loop, sampling/elicitation/roots handlers |
uv sync
# Interactive protocol playground (best way to learn):
uv run mcp dev src/careerpilot/server.py
# → opens MCP Inspector in the browser; poke every tool/resource/prompt,
# and test sampling + elicitation from the Inspector UIClaude Code: this repo ships a .mcp.json, so just open the project and approve the server.
Claude Desktop: claude_desktop_config.json →
{
"mcpServers": {
"careerpilot": {
"command": "uv",
"args": ["run", "--directory", "/Users/shwetarani/Developer/MCP_Project", "careerpilot"]
}
}
}Then try, in plain language:
"Search for remote python jobs, save the best three, and track that I applied to the first one." "Read my pipeline and tell me who I should follow up with." "Use the cover letter prompt for job 2."
┌─────────────────────┐ MCP (stdio → later Streamable HTTP)
│ MCP client + LLM │◄────────────────────────────────────┐
│ (Claude Code, etc.) │ │
└──────────┬──────────┘ │
│ tools / resources / prompts sampling / elicitation / roots
▼ (server → client callbacks)
┌─────────────────────┐
│ CareerPilot server │ src/careerpilot/server.py (FastMCP)
│ ├── sources.py │ Remotive · RemoteOK · HN (httpx, concurrent)
│ └── db.py │ SQLite: saved_jobs · applications · profile
└─────────────────────┘you> watch this search: "python backend", remotive only
-> Watch #1 created ... baseline: 10 current listingsA background poller re-runs every watch (default: every 15 min, tune with
CAREERPILOT_POLL_SECONDS) and pushes resources/updated notifications to any
client subscribed to careerpilot://watches — the server talks first, with no
request in flight. Review new finds in careerpilot://watches/{id}, then
mark_watch_reviewed.
# Serve over Streamable HTTP with bearer-token auth
CAREERPILOT_TOKEN=$(openssl rand -hex 24) uv run careerpilot --http --port 8848
# MCP endpoint: http://127.0.0.1:8848/mcp (requests without the token get 401)auth.py implements the SDK's TokenVerifier — the resource server role in
the MCP authorization spec (401 + WWW-Authenticate, protected-resource
metadata, scope checks). Swap StaticTokenVerifier for a JWT verifier against
a real OAuth 2.1 IdP without touching the rest of the server.
docker build -t careerpilot .
docker run -p 8848:8848 -v careerpilot-data:/data -e CAREERPILOT_TOKEN=... careerpilot
careerpilot --http also serves a dashboard at / — a "hiring file" view of your
pipeline styled as stamped paperwork: an action tray (follow-ups due, unreviewed watch
finds), the application drawer grouped in triage order, watch index cards, and one-click
"I applied" / "mark reviewed" / status changes. Same process, same SQLite, two front
doors: humans at /, LLMs at /mcp — and edits made in the browser push
resources/updated notifications to connected MCP clients.
uv run careerpilot --http # dashboard: http://127.0.0.1:8848/When CAREERPILOT_TOKEN is set, the dashboard locks too: open
/?token=<your token> once and that browser stays unlocked (cookie);
the JSON API also accepts the same Authorization: Bearer header as /mcp.
careerpilot-chat is a complete MCP host in ~250 lines (src/careerpilot/host.py) —
what Claude Desktop does, made visible:
export ANTHROPIC_API_KEY=sk-ant-...
uv run careerpilot-chat # spawn local server (stdio)
uv run careerpilot-chat --url http://host:8848/mcp --token ... # remote server
uv run careerpilot-chat --list # capability dump (no API key needed)It negotiates capabilities, exposes the server's tools to Claude, runs the
agentic tool-call loop, answers the server's sampling requests by calling
the Anthropic API, surfaces elicitation at the terminal, grants roots (cwd),
and prints server logs and push notifications. /tools, /read <uri>,
/prompt <name> k=v, /quit inside the REPL.
Stage 1 — Server fundamentals: tools, resources, templates, prompts, sampling, elicitation, roots, subscriptions, logging/progress over stdio
Stage 2 — Watched searches: background poller pushes resources/updated
notifications when new matching jobs appear
Stage 3 — Production transport: Streamable HTTP, bearer-token auth (MCP resource-server pattern), Dockerfile
Stage 4 — The client: careerpilot-chat, a minimal MCP host on the
Anthropic API — handshake, tool-call loop, sampling/elicitation/roots handlers
uv sync # install
uv run mcp dev src/careerpilot/server.py # inspector
uv run careerpilot # run over stdio directly
CAREERPILOT_DB=/tmp/test.db uv run careerpilot # throwaway database
# End-to-end protocol tests (spawn the real server, no mocks on the MCP layer)
uv run python tests/e2e_stdio_test.py # stage 1: every MCP feature over stdio
uv run python tests/stage2_watches_test.py # stage 2: poller + notifications
uv run python tests/stage3_http_test.py # stage 3: HTTP transport + 401/authRe-run all watched searches right now and report newly-found jobs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states the action without mentioning side effects, rate limits, or whether the operation is destructive. For a batch operation that re-runs searches, more details are needed to avoid unexpected consequences.
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, clear sentence with no redundant words. It directly conveys the tool's purpose without any filler.
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?
Given the tool has no parameters and an output schema exists, the description is sufficient for the agent to understand the basic action. However, it could mention that results are returned or that it triggers a batch process, but the current level is adequate.
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?
The tool has zero parameters, and the schema coverage is 100% trivially. The description adds no parameter information because there are none, which is acceptable. Baseline 4 is appropriate for no parameters.
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 the verb 're-run' and the resource 'all watched searches', with the specific outcome 'report newly-found jobs'. It is distinct from sibling tools like 'watch_search' (which creates a watch) and 'list_due_follow_ups' (which lists pending actions).
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 implies immediate use ('right now') but provides no explicit guidance on when to use this tool versus alternatives such as 'watch_search' or 'search_jobs'. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an application from the pipeline (asks the user to confirm first).
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes |
| 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 burden. It discloses the confirmation prompt, but lacks details on irreversible effects, auth requirements, or what happens to related data. Adequate but not thorough.
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?
Single sentence, no fluff. Front-loads the action and adds a key behavioral note. Every word earns its place.
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?
Given an output schema exists, return values are not needed. But the description omits whether deletion is soft/hard, reversible, or if dependent objects are affected. Adequate for a simple delete with confirmation, but gaps remain.
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 explain parameters. It mentions none. The only parameter (app_id) is not described, leaving the agent to infer its meaning from the schema alone.
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 'Delete an application from the pipeline' uses a specific verb and resource, clearly distinguishing it from siblings like update_application or track_application. It also adds a behavioral note ('asks the user to confirm first').
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 implies use when wanting to delete an application, but does not explicitly state when not to use it or compare with alternatives. The confirmation hint suggests caution but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate the user's resume in folders the client has granted access to (MCP roots), and remember its path in the profile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 burden. It discloses the action (locate and remember) but lacks details on failure modes (e.g., resume not found) or search behavior, making it adequate but not thorough.
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?
One sentence, front-loaded with the primary action. No redundancy or 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?
Given the tool's simplicity (no parameters, no annotations), the description is complete: it explains the core action and outcome. An output schema exists to describe return values, so no further detail needed.
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?
The input schema has zero parameters, so baseline is 4. The description adds context about what the tool does, which is sufficient given no parameters need explanation.
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 the verb 'Locate' and the resource 'user's resume' within a specific context (folders granted access). It distinguishes from sibling tools, which focus on jobs, watches, or profiles.
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 implicitly indicates when to use: to find and store the resume path. No explicit alternatives are mentioned, but sibling tools are sufficiently different that confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List follow-ups that are due today or overdue.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey all behavioral traits. It only states what is listed but does not disclose output format, pagination, ordering, authentication needs, or whether results are read-only. This lack of detail leaves the agent guessing about behavior.
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 concise sentence with no unnecessary words. It is front-loaded with the key action and resource, achieving maximum clarity with minimal text.
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?
Given no annotations and a simple parameterless tool, the description is adequate but could be more complete. For instance, it could mention that results include due dates or status, or differentiate from other list tools. The presence of an output schema is noted but not described.
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?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline for 0 params is 4. The description adds no parameter info, but that is acceptable since there are none to clarify.
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 precisely states the tool's function: 'List follow-ups that are due today or overdue.' It uses a clear verb ('List') and specifies the resource with temporal scope ('due today or overdue'), distinguishing it from sibling tools like schedule_follow_up which schedules new follow-ups.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contrast with sibling tools like watch_search or check_watches. The usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the 'new' flag on a watch's findings after you've reviewed them.
| Name | Required | Description | Default |
|---|---|---|---|
| watch_id | 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 burden. It discloses that the tool clears a flag (a state change), but does not mention reversibility, permission requirements, or behavior if the flag is already cleared.
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 concise sentence that is front-loaded with the action. Every word is necessary and there is no redundancy.
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 a simple 1-parameter tool with an output schema, the description is nearly complete. It could mention the return value or side effects, but the output schema likely covers that. Minor gaps remain regarding when exactly to use it.
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. The description does not explain the watch_id parameter beyond what the schema provides (integer). No additional meaning or constraints are given.
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 the action ('clear the new flag'), the resource ('watch's findings'), and the condition ('after you've reviewed them'). It is specific and distinguishes the tool from its siblings.
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 implies usage after review but does not provide explicit guidance on when to use this tool versus alternatives (e.g., check_watches, watch_search). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a job to the shortlist. Pass the fields from a search_jobs result, or enter a job found elsewhere manually (source='manual').
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| title | Yes | ||
| salary | No | ||
| source | No | manual | |
| company | No | ||
| location | No | ||
| description | No | ||
| external_id | 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 must carry the burden of behavioral disclosure. It only states the basic action and two input methods, but lacks details on idempotency, side effects, permissions, or error handling. For a mutation tool with no annotations, this is insufficient.
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 extremely concise: two sentences, each serving a distinct purpose. The first states the core function, the second provides usage variants. No redundant 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?
Given the tool has 8 parameters, no annotations, and no schema descriptions, the description is too sparse to fully guide an agent. It does not explain which fields are required, optional, or how they map to the search_jobs output. The existing output schema might help, but the description fails to connect.
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 0%, so the description must illuminate parameters. It only mentions the 'source' parameter and the concept of passing fields from search_jobs, but does not describe the other 7 parameters, their roles, or how they relate. The agent must infer meaning from parameter names alone.
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 the action ('Save a job'), the resource ('job'), and the destination ('shortlist'). It distinguishes itself from sibling tools (e.g., search_jobs, track_application) by focusing on saving to a list, not searching or tracking.
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 provides two clear use cases: passing fields from a search_jobs result or manual entry with source='manual'. It implicitly differentiates from other tools by specifying the purpose, though it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a follow-up reminder for an application. Date format: YYYY-MM-DD.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| note | No | ||
| app_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only mentions date format and that a reminder is scheduled, but omits important details like overwrite behavior, error conditions, permissions, or side effects of this mutation.
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, front-loaded with the action and a critical format constraint. No wasted words, though the description could be slightly more structured by covering each parameter.
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?
Given 3 parameters with no schema descriptions, no annotations, and an output schema not provided, the description is too sparse. It fails to specify parameter semantics beyond date format and lacks behavioral context for a scheduling mutation tool.
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 add meaning. It only explains the date format for the 'date' parameter. The 'app_id' and 'note' parameters are completely untouched, leaving their semantics unclear.
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 uses a specific verb 'Schedule' and identifies the resource as 'follow-up reminder for an application', clearly distinguishing it from the sibling tool 'list_due_follow_ups' which is a read operation.
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 guidance on when to use this tool versus alternatives, no prerequisites or exclusions. The sibling list_due_follow_ups exists, but no comparison or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score how well a saved job matches the user's profile/resume (0-10 with reasoning).
Demonstrates MCP sampling: this server sends a prompt to the CLIENT's LLM and uses the completion — the server needs no API key of its own.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| 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 burden, and it discloses a key behavioral trait: the tool uses MCP sampling (sends prompt to client's LLM) and the server needs no API key. This adds value but does not mention other traits like idempotency or error behavior.
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 concise with two sentences, front-loading the purpose. The second sentence on MCP sampling is useful but could be integrated more smoothly. No wasted words overall.
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?
Given one parameter, no annotations, and an output schema (not shown), the description covers the basic purpose and a notable behavioral aspect, but lacks details on prerequisites, return format beyond '0-10 with reasoning', or error conditions.
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?
The only parameter (job_id) has no description in the schema, and the tool description does not explain what this ID represents or how to obtain it. Since schema coverage is 0%, the description fails to add necessary meaning.
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 the verb 'Score' and the resource 'how well a saved job matches the user's profile/resume', with a specified range (0-10) and reasoning. This distinguishes it from sibling tools like search_jobs or save_job.
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 implies the tool is for evaluating job fit, but lacks explicit guidance on when to use it versus alternatives, prerequisites (e.g., job must be saved), or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live job openings across free job boards.
Args: query: Keywords, e.g. "python backend" or "devops kubernetes". source: "remotive", "remoteok", "hn" (Hacker News Who is Hiring), or "all". limit_per_source: Max results per board (1-20).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| source | No | all | |
| limit_per_source | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should detail behavioral traits. It only implies a read operation ('Search live job openings') but does not confirm it is non-destructive, mention rate limits, or describe side effects like external API calls. Essential behavioral context is missing.
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 concise: a single sentence summarizing the tool's function followed by a clear list of parameters. Every sentence adds value with no redundancy. Information is front-loaded.
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 description sufficiently explains how to use the parameters. Given that an output schema exists, the lack of return value details is acceptable. However, it could mention that results are aggregated from multiple boards or note potential latency, but overall it is adequate for its complexity.
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?
Despite 0% schema description coverage, the description adds significant meaning: it explains the query parameter with examples, lists allowed source values with clarifications, and defines the limit_per_source parameter with range. This compensates fully for the schema's lack of descriptions.
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 the tool's purpose: 'Search live job openings across free job boards.' This provides a specific verb (search), resource (job openings), and scope (across free job boards). The purpose is unambiguous and distinguishes it from siblings like find_resume or save_job.
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 implies usage context (searching for jobs) but does not explicitly guide when to use this tool versus alternatives. No exclusions or comparisons to siblings like watch_search or score_job_fit are provided, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a profile fact used by prompts and fit-scoring.
Useful fields: name, role, years_experience, skills, location, salary_expectation, resume_path.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| value | 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 burden. It only says 'Store' without details on whether values overwrite, append, or require specific permissions. Behavioral traits like idempotency or side effects 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. Every word is functional, making it highly concise and easy to parse.
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 a simple setter with 0% schema coverage and no annotations, the description omits return values, side effects, and usage patterns (e.g., multiple calls to set multiple fields). It is not sufficiently complete for an agent to use reliably.
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 0%, so the description must compensate. The list of 'useful fields' provides examples for the 'field' parameter, adding some meaning. However, it doesn't explain that field must be one of these, nor does it describe the 'value' parameter format or constraints.
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 the tool stores a 'profile fact' and mentions its use in prompts and fit-scoring. It lists common fields, which helps clarify the resource. However, it could more explicitly say it sets user profile attributes.
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 guidance is given on when to use this tool versus siblings like score_job_fit or find_resume. The description does not specify prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record that you applied to a saved job. Creates a pipeline entry with status 'applied'.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must bear full behavioral disclosure. It only states the primary action (creates a pipeline entry) without mentioning idempotency, side effects, permissions, or error conditions. For a write operation, this is insufficient.
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 very short (12 words) and front-loaded with the core action, but it sacrifices essential details for brevity, making it less useful than a slightly longer but more informative description.
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?
Given the lack of annotations, the description is incomplete. It does not cover when to use, parameter details, prerequisites (saved job), or behavioral traits like whether reapplying is allowed. The output schema exists but its content is unknown, so cannot compensate.
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 indirectly references job_id but does not describe the notes parameter or provide any format, constraints, or values beyond the schema.
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 the tool records an application to a saved job and creates a pipeline entry with status 'applied'. It uses specific verbs and resources, and distinguishes from sibling tools like 'save_job' and 'update_application'.
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 implies usage after applying to a saved job, but does not explicitly state when to use or exclude alternatives, nor does it mention prerequisites like the job being previously saved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a watched search.
| Name | Required | Description | Default |
|---|---|---|---|
| watch_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavioral traits. It states 'Delete' but omits side effects, reversibility, permissions, or what happens to associated data. Minimal behavioral context beyond the action.
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, it could be slightly expanded to include more context without becoming verbose, so not a perfect 5.
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?
Given only one parameter and an existing output schema, the description lacks information about return values, error states, and how this tool relates to siblings like mark_watch_reviewed. Incomplete for safe usage.
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?
The input schema defines one parameter (watch_id) with no description, and the description does not explain its meaning or format. Schema description coverage is 0%, and the description adds no value for parameter semantics.
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 uses the verb 'Delete' and the noun phrase 'a watched search,' clearly indicating the action and resource. This distinguishes it from sibling tools like watch_search (create) and check_watches (list), albeit implicitly.
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 guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., must have an existing watch), or when not to use it. The context from sibling tools is not leveraged.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an application's status and/or notes.
Valid statuses: saved, applied, screening, interviewing, offer, accepted, rejected, withdrawn, ghosted.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| app_id | Yes | ||
| status | 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 full burden. It discloses that the tool updates status/notes and lists valid statuses, but lacks details on side effects, authorization needs, or return behavior. Basic coverage without deeper behavioral context.
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 short paragraphs with a clear first sentence and a concisely listed set of valid statuses. No redundant information, but could be slightly more structured.
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, return values are covered. Tool is simple with 3 parameters. Description adequately covers status values but omits behavior for partial updates, defaults, or error handling. Adequate for a simple update tool.
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 description must compensate. It adds meaning for 'status' by listing valid values, but 'app_id' and 'notes' are only named without additional explanation. Partial compensation.
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?
Description explicitly states 'Update an application's status and/or notes' with a list of valid statuses. It clearly identifies the verb and resource, but does not differentiate from sibling tools like 'track_application' which may have similar function.
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 on when to use this tool over siblings or when not to use it. The list of valid statuses implies usage context, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a watched search: CareerPilot re-runs it in the background and notifies subscribers of careerpilot://watches when NEW jobs are posted.
The current results become the baseline — only jobs appearing later count as new.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| source | No | all |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains the background monitoring, baseline setting, and notification mechanism. It does not mention permissions or limits, but the core behavior is transparent.
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 concise sentences, front-loaded with the action verb, and no wasted words. Clear and efficient.
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?
Output schema exists, so return value not required. However, the description misses explaining the expected output (e.g., watch ID) and does not fully parameter coverage. Adequate but could be more complete.
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%, requiring the description to compensate. It adds meaning for 'query' through context but neglects the 'source' parameter entirely, leaving its purpose unclear.
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 'Create a watched search' and explains the behavior: background re-run and notification on new jobs. This distinguishes it from sibling tools like search_jobs (one-time) and unwatch.
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 implies usage by explaining that the tool creates a monitored search with baseline comparison. However, it does not explicitly state when to use this versus alternatives like search_jobs or check_watches, but 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0check_watchesdelete_applicationfind_resumelist_due_follow_upsmark_watch_reviewedsave_jobschedule_follow_upscore_job_fitsearch_jobsset_profiletrack_applicationunwatchupdate_applicationwatch_searchEach tool has a clearly distinct purpose: searching jobs, managing watches, tracking applications, scheduling follow-ups, etc. There is no ambiguity between tools like 'watch_search' and 'check_watches' or 'list_due_follow_ups' and 'schedule_follow_up' as they handle different actions.
All tool names follow a consistent verb_noun pattern using underscores (e.g., search_jobs, save_job, track_application). Even 'unwatch' and 'set_profile' fit the convention. No mixing of styles or vague verbs.
14 tools is well-scoped for a career assistant covering job search, application tracking, watches, profile management, and fit scoring. Each tool serves a clear role without being excessive or insufficient.
The tool set covers core workflows: searching, saving, applying, tracking, scheduling, and scoring. Minor gaps exist, such as no tools to list saved jobs or list all applications, which an agent might need to navigate the pipeline programmatically.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Job application tracker for developers - AI agents write over MCP, you review in a dashboard.
ATS resume scoring, job analysis, interview prep, and auto-apply that verifies each submission.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rani700/careerpilot'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
