How this tracker is laid out: field -> column, custom fields, other headers (usable by exact text in add_application's extra and in funnel's by), allowed statuses, which statuses are closed, the follow-up rule, and tools this layout cannot support (unavailable_tools). On the first start the server writes the config itself; then config_generated says where, and what to check.

Browse the job applications in the tracker, one line each: row, company, role, status, submit and follow-up dates. Filter by status, by company or role text, by submit dates, or show open ones only. For every column of one row use get_application. For counts use summary or funnel, and for what is due use followups_due.

Everything recorded for one job application: every column, the notes and the follow-up log. Find it by row, or by company or role text in query. A text that matches several rows returns all of them. Use it before a write to show the user the current values. To browse many rows in brief, use list_applications.

Follow-ups due by today + within_days (overdue included), plus submitted applications that have no follow-up date at all.

Applications still waiting for a reply: a waiting status, silent for days+ days since the last touch (the submit date or the newest dated follow-up log entry, not counting moved or dropped follow-ups), and no follow-up planned for today or later. These are what close_stale closes.

Counts the job applications in the tracker: per status, submitted and not yet, and submissions per month. With since/until, it shows the applications submitted in that period and where they stand now. For reply and interview rates use funnel, and for how fast replies come use reply_times. For what to do next, use followups_due and stale_applications.

Conversion of submitted applications: how many got any reply (a rejection counts), and how many reached each funnel stage (screening, interview, offer, as configured). In total and per group, with rates in percent of submitted.

Find what hand edits leave behind, row by row: dates kept as text or bare numbers (Excel cannot sort or filter them as dates), rows with no status or a status not in the dropdown, follow-ups on a weekend or on closed applications, waiting applications with no follow-up date, the applied column disagreeing with the status, the furthest stage behind the status, replies without a reply date (with the date found in the response text), duplicates. Each issue says whether fix_tracker can fix it.

How long replies take: median and 75th percentile of days from submitting to the first reply, in total and per group, and a silence table: of the applications that had heard nothing for 7, 14, 21, 30, 45, 60 days, how many still got a reply later. Use it to decide when to close silent applications. Needs reply dates (a reply-date column, filled by set_status; check_tracker can fill past ones).

Which application each e-mail is about and what it says: a confirmation, a rejection, an interview invitation or an offer. The company comes from the subject, the sender's name or the sender's own domain (not from applicant-tracking systems such as Ashby, Greenhouse, Lever or Workable). Each message gets the matching rows and the write tool that would record it, with the e-mail's date. Suggestions only: fetch the messages with your mail tool first, and make each change with its write tool after the user's yes.

The audit log of this server's writes to the tracker, newest first. Each entry has the time, the tool, the row, the backup file, and every changed cell with its old and new value. Use it to answer "what did you change?" or to check that a write landed. It also shows what undo_last_write would revert. Edits made by hand in Excel or Sheets are not in it.

Add a new row with the not-applied status. Refuses a duplicate (same company+role or link). For several rows at once use add_applications: one preview and one yes for all of them.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Add several new rows in one write, each with the not-applied status. Each item takes the arguments of add_application. The user sees one preview of every row and answers once. The write is all or nothing: if one item is refused (a duplicate, an unknown column), nothing is written and the error names that item. It makes one backup, so one undo_last_write removes the whole batch.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Record that the user submitted an application that is already a row in the tracker. Add a new one with add_application first. The write sets the applied flag, the submit date, the channel and the applied status, unless the row already has another status. It also sets the first follow-up date by the follow-up rule and adds a line to the follow-up log. An existing follow-up date is kept unless followup_on is given. A row already marked as applied is refused; correct its date with edit_application. The tool warns when the same company got another application within a few weeks. Replies and closing go through set_status.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Change the status of one job application when the company replies or the application ends. It covers a rejection, a screening call, an interview, an offer or a withdrawal. status must be a value from the tracker's status dropdown; describe_tracker lists them and which are closed. The response and the note are appended with a date. The furthest-stage column moves forward, never back. The first reply fills the reply date with on, and a closed status clears a pending follow-up date. For a new submission use mark_applied, and for many silent applications at once use close_stale. To fix another cell, use edit_application. For several rows at once use set_statuses: one preview and one yes for all of them.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Change the status of several applications in one write, for example after a day of replies. Each item takes the arguments of set_status and is applied as set_status applies it. The user sees one preview of every row and answers once. A row may appear only once. The write is all or nothing: if one row is refused, nothing is written and the error names that row. It makes one backup, so one undo_last_write reverts the whole batch.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Record a follow-up that the user actually sent for one job application. The tool appends text to the follow-up log and replaces the contact if one is given. It also sets the next follow-up date: next_on, or the follow-up rule counted from today. final=true clears the date, so there are no more follow-ups while the status stays open. Use reschedule_followup when nothing was sent and only the date moves. Use set_status when the company replied or the application closes. followups_due lists what is due.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Move the next follow-up to another date, or plan none, when nothing was sent: no one to write to yet, waiting for message credits, the company promised an answer by a date. Use log_followup instead when a follow-up was actually sent, and set_status to close an application.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Correct fields of one row by hand: a wrong or missing date, a typo in the company or role, the furthest stage, the link, a custom column. Dates are checked (a submit or reply date cannot be in the future, a reply cannot come before the submit) and written as dates. The status is changed with set_status, a sent follow-up recorded with log_followup, a moved one with reschedule_followup: they keep the related columns in step. The preview shows the old and new value of each cell.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Add a column after the last one, its header styled like its neighbour's, and with field map it in the config so the tools start using it: describe_tracker's unavailable_tools says which columns a tool is missing. Only at the end, so no formula, dropdown or filter of the sheet moves. Undo removes the column and the config line together.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Close stale applications in one write: the no-response status, no follow-up date, a line in the follow-up log. One backup and one undo step for the whole batch.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

Fix the fixable issues check_tracker found, in one write with one backup and one undo step: text dates become real dates, a missing status gets the not-applied (or applied) one, weekend follow-ups move to Monday, closed applications lose a planned follow-up, the furthest stage catches up with the status, missing reply dates are filled from the response text.

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version. A backup is taken first, and undo_last_write reverts the write.

The open follow-ups as all-day calendar events: date (an overdue one on today), title and description. Each description ends with a line "tracker-mcp id: "; search the calendar for it to update an event instead of adding a second one. For the user's own calendar tool (see the sync_calendar prompt); the tracker is not touched.

Write the open follow-ups as an .ics file next to the tracker (overdue ones on today), to import into Calendar, Outlook or Google Calendar; the tracker itself is not touched. If your client has a calendar tool, you can add the events there instead: followups_due has the same data.

Restore the file to its state before this server's last write. Refused if the file has changed since that write (it would lose someone else's edits).

The tool writes only with the user's yes. The client may ask in its own confirmation dialog. Otherwise call with dry_run=true, show the preview to the user, and after they agree in a new message repeat the same call with confirm=. The write is refused if the tracker changed since expected_version.