Summary
Add an MCP tool that deletes job records from Airtable and the local SQLite dedup cache in a single call, so users can prune stale / wrong / closed postings on demand.
Motivation
Today the server only writes jobs (airtable_upsert_job, cache_mark_seen). When a job turns out to be a bad fit, a duplicate that slipped through, or a closed posting that sneaked past verify_job_link, the only way to remove it is manually editing Airtable — and the cache still has the apply link marked seen, so it won't be re-scraped even if it's legitimately re-posted later.
Proposed tool(s)
delete_job
Delete one or more jobs by Airtable record ID or apply link.
Input schema (sketch):
Behavior:
- Resolve any
applyLinks to recordIds via airtable_list_recent_jobs / a direct filterByFormula lookup.
- Batch
DELETE /v0/{baseId}/{tableId}?records[]=... (Airtable cap: 10 per call — handle pagination internally).
- If
alsoClearCache: true, remove matching rows from the SQLite cache so the apply link is eligible to be re-scraped on a future run.
- Return
{ deletedFromAirtable, deletedFromCache, notFound } counts.
delete_job_batch (optional)
Same semantics, accepts up to ~100 identifiers; internally chunks Airtable calls at 10.
Open questions
- Should we require confirmation (e.g. a
confirm: true arg) to avoid accidental mass-deletes from an LLM? Leaning yes, at least for batch.
- Should we add a prompt (
prune_jobs_workflow) that chains verify_job_link_batch against recent Airtable rows and proposes closed postings for deletion?
- Cache-only delete mode for users who want to force a re-scrape without losing the Airtable row?
Files likely touched
mcp-server/src/lib/airtable.ts — add delete helper
mcp-server/src/lib/cache.ts — add delete-by-link helper
mcp-server/src/tools/airtable-tools.ts (or new delete-tools.ts) — tool definition
mcp-server/src/tools/index.ts — register
mcp-server/README.md — tools table
Acceptance criteria
Summary
Add an MCP tool that deletes job records from Airtable and the local SQLite dedup cache in a single call, so users can prune stale / wrong / closed postings on demand.
Motivation
Today the server only writes jobs (
airtable_upsert_job,cache_mark_seen). When a job turns out to be a bad fit, a duplicate that slipped through, or a closed posting that sneaked pastverify_job_link, the only way to remove it is manually editing Airtable — and the cache still has the apply link marked seen, so it won't be re-scraped even if it's legitimately re-posted later.Proposed tool(s)
delete_jobDelete one or more jobs by Airtable record ID or apply link.
Input schema (sketch):
{ "recordIds": ["recXXXX", "recYYYY"], // optional "applyLinks": ["https://..."], // optional "alsoClearCache": true // default true }Behavior:
applyLinkstorecordIdsviaairtable_list_recent_jobs/ a direct filterByFormula lookup.DELETE /v0/{baseId}/{tableId}?records[]=...(Airtable cap: 10 per call — handle pagination internally).alsoClearCache: true, remove matching rows from the SQLite cache so the apply link is eligible to be re-scraped on a future run.{ deletedFromAirtable, deletedFromCache, notFound }counts.delete_job_batch(optional)Same semantics, accepts up to ~100 identifiers; internally chunks Airtable calls at 10.
Open questions
confirm: truearg) to avoid accidental mass-deletes from an LLM? Leaning yes, at least for batch.prune_jobs_workflow) that chainsverify_job_link_batchagainst recent Airtable rows and proposes closed postings for deletion?Files likely touched
mcp-server/src/lib/airtable.ts— add delete helpermcp-server/src/lib/cache.ts— add delete-by-link helpermcp-server/src/tools/airtable-tools.ts(or newdelete-tools.ts) — tool definitionmcp-server/src/tools/index.ts— registermcp-server/README.md— tools tableAcceptance criteria
alsoClearCacheis true