Skip to main content
Glama
Ashishkosana

jobs-mcp

by Ashishkosana
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

jobs-mcp

An MCP server that gives any LLM live access to US software-engineering job openings.

Point Claude (or any Model Context Protocol client) at this server and it can search current postings — pulled live from company ATS boards (Greenhouse / Lever / Ashby) and a community new-grad feed — right inside your conversation. US-only, security-clearance / citizenship-required roles filtered out, newest first. No API keys: every source is a public endpoint.

Claude  ──calls──▶  jobs-mcp
                     • search_jobs(query, location, limit)
                     • list_sources()
                       └─▶ Greenhouse · Lever · Ashby · SimplifyJobs feed
                       └─▶ US-only · clearance/citizenship roles excluded · deduped

Tools

Tool

What it does

search_jobs(query, location, limit)

Live search; query words must all appear in the title (e.g. "backend engineer", "new grad software engineer"), location is "us" or a city/state substring. Returns {company, title, location, url, posted, source}.

list_sources()

The ATS boards + community feed this server pulls from.

Related MCP server: trackly-cli

Install & connect to Claude Code

git clone https://github.com/Ashishkosana/jobs-mcp && cd jobs-mcp
python3 -m venv .venv && .venv/bin/pip install -e .

# register it (stdio transport):
claude mcp add jobs -- "$(pwd)/.venv/bin/python" -m jobs_mcp

Then just ask Claude things like "find me fresh backend software engineer roles in New York" — it calls search_jobs and answers from live data.

Works with any MCP client (Claude Desktop, etc.) — point it at python -m jobs_mcp over stdio.

How it works

An MCP server exposes tools a client can discover and call. Here each tool is a plain Python function decorated with @server.tool(); its type hints become the input schema the model sees. On a call, the server fetches every source concurrently (a dead board is skipped, not fatal), applies the US + clearance filters, dedupes, and returns structured rows. See src/jobs_mcp/server.py.

Scope / honesty

  • Sources are a curated company list + one community feed, not "every job on the internet" — LinkedIn/Indeed block scraping, so this uses public ATS APIs instead.

  • The clearance filter is lexical (keywords + known defense employers); it catches the common cases, not every phrasing.

License

MIT

Available Tools

2 tools
list_sourcesA

List the job sources this server pulls from (ATS boards + community feed).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

The description only says 'List', which implies a read-only operation, but with no annotations, it provides no explicit safety guarantees or output details. It doesn't mention whether the response includes full details or just names, nor any rate limits or auth. For a simple list, this is adequate but lacks added behavioral transparency.

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

Conciseness5/5

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

The entire description is one sentence, 12 words, front-loaded with the verb and resource. It contains no filler and every word adds value.

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

Completeness4/5

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

Given the tool's simplicity (no parameters, no output schema, no annotations), the description sufficiently explains what it lists and the categories. It doesn't overpromise or leave major gaps. A slightly more detailed note about the return structure could push it higher, but for a listing tool, this is adequate.

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

Parameters4/5

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

The input schema has zero parameters, so the description doesn't need to explain parameters. The baseline for 0 params is 4, and the description adds context about source categories, which is helpful.

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 identifies the action ('List') and the specific resource ('job sources'), with an added parenthetical defining what those sources include ('ATS boards + community feed'). This distinguishes it from the sibling tool 'search_jobs', which searches jobs rather than listing sources.

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 the use case: when an agent needs to know the server's configured job sources. It doesn't explicitly name the sibling alternative, but the purpose itself differentiates it from 'search_jobs'. Because there are no exclusions or prerequisites, it falls at 'clear context, no exclusions'.

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

search_jobsA

Search live US software-engineering job openings.

Pulls current postings from company ATS boards (Greenhouse/Lever/Ashby) and a community new-grad feed, filters to US roles, excludes security-clearance / US-citizenship-required postings, de-duplicates, and returns newest first.

Args: query: words that must all appear in the job title, e.g. "backend engineer", "new grad software engineer". Default "software engineer". location: "us" for anywhere in the US, or a city/state substring like "New York" or "remote". limit: max results (1-100).

Returns a list of {company, title, location, url, posted, source}.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNosoftware engineer
locationNous

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses behavior: pulls from specific ATS boards, filters to US roles, excludes security-clearance/US-citizenship-required postings, de-duplicates, and returns newest first. This is detailed behavioral transparency.

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

Conciseness5/5

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

The description is structured with a summary line, behavioral details, and an Args section. Every sentence adds value, and the arg descriptions are clear and brief. No waste.

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

Completeness5/5

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

Given 3 optional params and an output schema, the description covers return structure ('list of {company, title, location, url, posted, source}'), parameter semantics, and behavioral filters/ordering. It leaves little ambiguity for a search tool.

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

Parameters5/5

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

Schema coverage is 0%, but the description's Args section extensively explains each parameter: query semantics ('words that must all appear'), location format ('us' or substring), limit range (1-100), including examples. This fully compensates for the schema gap.

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

Purpose5/5

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

The description opens with a specific verb+resource: 'Search live US software-engineering job openings.' It further specifies data sources (Greenhouse/Lever/Ashby, community feed) and exclusions, clearly distinguishing it from the sibling tool list_sources.

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 for when to use the tool: to find current US software-engineering jobs matching query/location. It does not explicitly mention alternatives or when-not-to-use, but the context is enough for a search tool.

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

Tool Schema Changelog

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

  1. 2 tool updatesv0.1.0
    • First observedlist_sources
    • First observedsearch_jobs
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools serve clearly distinct purposes: one lists data sources and the other searches for jobs. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow the same verb_noun snake_case pattern: list_sources and search_jobs. This is perfectly consistent and predictable.

Tool Count3/5

With only two tools, the server feels minimal, but the scope is very narrow—job searching and source listing. This is borderline, as the rule suggests 1-2 tools feels thin, yet each tool serves a necessary role.

Completeness5/5

The server fully covers its stated purpose: list the job sources and search live US software-engineering job openings. There are no obvious missing operations for this narrow domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • job-search-mcp

    VincenzoImp
    A
    license
    Not graded
    quality
    A
    maintenance
    MCP server that exposes job search data from multiple boards, enabling clients to query and manage job listings via natural language.
    7
    MIT
  • trackly-cli by trackly-app

    trackly-cliofficial

    trackly-app
    A
    license
    Not graded
    quality
    A
    maintenance
    MCP server for job search and application tracking, enabling AI agents to search jobs, get details, manage applications, and find contacts across 128K+ jobs and 1,900+ companies.
    638 npm
    3
    MIT

  • RecruitData

    ssaikrishna862
    A
    license
    Not graded
    quality
    D
    maintenance
    Unified job search MCP server that aggregates live listings from multiple job boards with deduplication, enabling AI agents to find and filter jobs by keyword and location.
    MIT

  • job-search

    VikramKavuri
    A
    license
    Not graded
    quality
    B
    maintenance
    A job-search MCP server that ranks roles, drafts cover letters, and rehearses Q&A answers using a candidate profile, with live listings from five public sources.
    45 npm
    MIT