autoapply-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTOAPPLY_DB | No | SQLite database | $HOME/data/autoapply.sqlite |
| AUTOAPPLY_HOME | No | Root for config, database and artifacts | ~/.autoapply |
| AUTOAPPLY_PROFILE | No | Candidate profile | $HOME/profile.json |
| AUTOAPPLY_CAMPAIGN | No | Campaign policy | $HOME/campaign.json |
| AUTOAPPLY_ARTIFACTS | No | Screenshots and submission evidence | $HOME/artifacts |
| AUTOAPPLY_COMPANIES | No | Company board list | $HOME/companies.json |
| AUTOAPPLY_LOG_LEVEL | No | Log level: debug, info, warn, error | info |
| AUTOAPPLY_MAX_RESPONSE_MB | No | Response size ceiling | 64 |
| AUTOAPPLY_MIN_INTERVAL_MS | No | Minimum delay between requests to one host | 700 |
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
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| discover_jobsA | Fetches every configured ATS board, normalizes the postings, applies the campaign's hard gates, scores what survives, and stores the results. Read-only against employers: no application is created or sent. |
| resolve_company_boardA | Probes Greenhouse, Lever and Ashby for a company's public board slug. Board tokens are not published centrally, so guesses must be verified before being added to companies.json. Workday is not probed: its tenant, datacenter and site slug cannot be guessed, so find that URL on the employer's careers page and record it with add_company_board. |
| add_company_boardA | Checks that a candidate board actually serves postings, then saves it to companies.json. Nothing is saved unless postings were seen, because a wrong slug often answers 200 with a generic page rather than an error. Use this to record boards found elsewhere — a careers-page URL or a web search — including Workday, which cannot be probed by guessing. |
| scan_hiring_threadA | Scans a monthly Hacker News 'Ask HN: Who is hiring?' thread for links to employers' own ATS boards, verifies each one actually serves postings, and optionally saves the new ones to companies.json. This is a lead source, not a job source: the thread's prose cannot be gated on reliably, so only the board slug is taken and discover_jobs then ingests every role at that company with full structured pay and location. Free to call — it uses the public Hacker News API and no third-party scraping credits. |
| list_queueA | Returns gated-in jobs ordered by score. Roles already applied to are excluded by fingerprint, so the same posting on a second board is not surfaced twice. |
| explain_jobA | Returns the full gate result, score breakdown with quoted evidence, and the posting text wrapped as untrusted data. |
| campaign_statusA | Summarizes progress toward the application target, pipeline health, tier distribution and the most common rejection reasons. |
| prepare_applicationA | Builds the match report, loads the employer's application questions, drafts only the answers that verified profile data supports, and selects the resume variant for the matched track. Creates a local draft; nothing is sent. |
| set_application_contentA | Records a cover letter and answers to questions the policy engine would not fill on its own. Changing content invalidates any prior approval, because approval is bound to the packet hash. |
| preview_applicationA | Renders the full submission packet - every field, its value and where the value came from - plus the packet hash to approve. |
| prepare_batchA | Selects queued jobs matching a filter and prepares an application packet for each, using the same drafting and validation as the single-job path. Creates local drafts and a batch manifest; nothing is sent. Applications whose questions still need a human decision are marked needs_human and excluded from batch approval. The campaign's submission.maxBatchSize is a hard ceiling, so a larger limit is silently reduced to it. |
| preview_batchA | Lists every application in a batch with its company, role, resume variant and readiness, plus the grouped questions blocking the rest. Returns the manifest hash required to approve. |
| approve_batchA | Records a human approval for each ready application in the batch. Requires the current manifest hash and the exact count being approved, so approval cannot silently cover more applications than were reviewed. |
| submit_batchA | Submits every approved application in the batch, re-running all per-application guards for each one and honouring the daily limit and pacing delay. Stops cleanly when the daily limit is reached so the rest can continue on the next run. The campaign's submission.maxBatchSize also caps how many are submitted per run. |
| list_batchesB | Recent batches with their status and per-state counts. |
| approve_applicationA | Records the human decision that authorizes submission. The supplied packetHash must match the current content exactly; any later edit invalidates the approval. |
| submit_applicationA | Runs every submission guard, then acts according to mode. 'manual' returns the packet for a person to submit. 'assisted' fills the hosted form in a visible browser and leaves it for a person to submit. 'auto' fills and clicks submit, and is only available when the campaign and company allowlists permit it. |
| record_submissionA | Marks an application as submitted after a person sent it, so counts, pacing and duplicate checks stay accurate. |
| record_outcomeA | Appends an outcome to an application's history so conversion rates can be measured per track, tier and company. |
| list_applicationsC | Lists applications with their status, target role and outcome history. |
| audit_logA | Returns recent recorded events: discovery runs, approvals, submissions and blocked attempts. Values are redacted. |
| reload_configA | Re-reads profile.json, campaign.json and companies.json so edits take effect without restarting the server. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/niragmehta/autoapply-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server