job-search-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_sponsorA | Look up whether a company holds a UK Skilled Worker sponsor licence. Returns a confidence grade, because company names collide: a match on a generic word like 'global' or 'minerva' is not evidence. A result of 'none' does NOT mean the employer cannot sponsor; it means they are not listed under that name, and the registered legal entity should be checked instead. |
| screen_postingA | Screen a posting for hard eligibility bars (citizenship, residency, existing security clearance, explicit refusal to sponsor), for seniority the body implies but the title hides, and for salary and stack. Run this before investing effort in an application. |
| search_rolesA | Search live UK job listings via Reed, excluding recruitment agencies and job boards, which cannot sponsor roles they merely advertise. Returns a funnel showing what each filter removed, so a small result set can be explained rather than mistaken for an error. Requires REED_API_KEY. |
| application_historyA | Read the local application ledger. Use it before applying to avoid duplicate submissions to the same employer, and to see what has already been tried. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool addresses a clearly distinct aspect: sponsor verification, posting screening, application history, and job searching. No overlap in purpose and each has a specific trigger condition.
Three tools follow a verb_noun pattern (check_sponsor, screen_posting, search_roles), but application_history deviates as noun_noun. The naming is still descriptive and predictable, with only minor inconsistency.
Four tools is well-scoped for a focused job-search assistant, covering the core workflow without bloat. Each tool contributes a distinct function and none seem redundant.
The surface covers search, screening, sponsor checks, and local history, which addresses the primary workflow. A minor gap is the lack of a tool to update or add to the application ledger, but this may be handled externally.