JobHound
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jobhound_scanA | Fetch jobs from all configured sources, score them, and queue high-scoring ones. Jobs above score threshold are saved with status 'queued'. Returns a summary + list of queued job IDs ready for tailoring. Next step: call jobhound_list('queued') then jobhound_get_for_tailoring(id). |
| jobhound_listA | List jobs by status with their database IDs. Args: status: one of new, queued, applied, failed, interviewing, rejected |
| jobhound_get_for_tailoringA | Get everything needed to write a tailored application for a job. Returns the job description and the full resume. After reading this, generate a tailored CV and cover letter, then call jobhound_apply_tailored(job_id, tailored_cv, cover_letter). Args: job_id: integer ID from jobhound_list('queued') |
| jobhound_apply_tailoredA | Submit an application using the tailored CV and cover letter. Tries: LinkedIn MCP → direct POST (Ashby/Lever) → Blackreach fallback. Records the outcome in the database. Args: job_id: integer ID of the job tailored_cv: the tailored CV text (markdown) cover_letter: the cover letter text |
| jobhound_statusB | Summary of JobHound activity: job counts by status. |
| jobhound_getC | Get full details for a job including cover letter if applied. Args: job_id: integer ID |
| jobhound_updateA | Manually update a job's status. Use this when you get an interview invite or rejection. Args: job_id: integer ID status: interviewing, rejected, applied, failed, queued |
| jobhound_pauseA | Pause the JobHound daemon (scan loop stops applying). |
| jobhound_resumeB | Resume the JobHound daemon. |
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 9 tools
Each tool serves a distinct function: scanning, listing, retrieving, updating, applying, and daemon control. The only potential confusion is between `jobhound_get` and `jobhound_get_for_tailoring`, but their descriptions clarify the different outputs.
All tools use the `jobhound_` prefix with snake_case verbs like `get`, `list`, `scan`, `update`, `apply_tailored`. Minor deviations are `jobhound_status` (a noun rather than a verb) and `jobhound_get_for_tailoring` (a longer phrase), but the pattern is consistent enough to predict tool purpose.
9 tools is well-scoped for a job application automation server. Each tool covers a necessary step in the workflow: scanning, queuing, tailoring, applying, tracking, and daemon lifecycle.
The core workflow is fully covered: scan → list → get_for_tailoring → apply_tailored, plus status updates and daemon control. Minor gaps include no tool for manually adding or deleting jobs, but these are not essential for the automated pipeline.