Motivation: Users want to schedule job aggregation via cron, GitHub Actions, etc. Today the MCP server is stdio-only and relies on an MCP client to drive tool calls. For scheduled/headless runs we need a self-contained entrypoint.
Proposal: Add an optional jobsync-mcp run subcommand that:
- Loads the user's model API key from
~/.jobsync/config.json (model.provider + model.apiKey)
- Runs the
scrape_jobs_workflow prompt to completion using an embedded SDK (Anthropic / OpenAI / Gemini)
- Exits with non-zero on failure so cron can alert
Tradeoff: Bundling a model client slightly breaks the 'bring your own model via any MCP client' story. Keep it opt-in — if model.provider isn't configured, the command errors and points users at the MCP-client flow.
Example cron:
0 9,17 * * * jobsync-mcp run >> ~/.jobsync/run.log 2>&1
Scope: Phase 8 / post-publish enhancement. Not blocking core MCP migration.
Motivation: Users want to schedule job aggregation via cron, GitHub Actions, etc. Today the MCP server is stdio-only and relies on an MCP client to drive tool calls. For scheduled/headless runs we need a self-contained entrypoint.
Proposal: Add an optional
jobsync-mcp runsubcommand that:~/.jobsync/config.json(model.provider+model.apiKey)scrape_jobs_workflowprompt to completion using an embedded SDK (Anthropic / OpenAI / Gemini)Tradeoff: Bundling a model client slightly breaks the 'bring your own model via any MCP client' story. Keep it opt-in — if
model.providerisn't configured, the command errors and points users at the MCP-client flow.Example cron:
Scope: Phase 8 / post-publish enhancement. Not blocking core MCP migration.