Skip to main content
Glama
niragmehta
by niragmehta

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
AUTOAPPLY_DBNoSQLite database$HOME/data/autoapply.sqlite
AUTOAPPLY_HOMENoRoot for config, database and artifacts~/.autoapply
AUTOAPPLY_PROFILENoCandidate profile$HOME/profile.json
AUTOAPPLY_CAMPAIGNNoCampaign policy$HOME/campaign.json
AUTOAPPLY_ARTIFACTSNoScreenshots and submission evidence$HOME/artifacts
AUTOAPPLY_COMPANIESNoCompany board list$HOME/companies.json
AUTOAPPLY_LOG_LEVELNoLog level: debug, info, warn, errorinfo
AUTOAPPLY_MAX_RESPONSE_MBNoResponse size ceiling64
AUTOAPPLY_MIN_INTERVAL_MSNoMinimum delay between requests to one host700

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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

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