tracker-mcp

Overview Schema Source Related Servers Discussions Admin

Log a follow-up

log_followup

Destructive

Log a follow-up you actually sent for a job application, append it to the follow-up history, update the contact, and set or clear the next follow-up date.

Instructions

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.

Input Schema

Name	Required	Description
`row`	Yes	Sheet row number of the application (see list/get results)
`text`	Yes	What was sent and to whom; appended to the follow-up log
`final`	No	No more follow-ups: clears the follow-up date
`confirm`	No	Token from the dry run the user approved. Not needed when the client shows the server's confirmation dialog
`contact`	No	Replace the follow-up contact / channel
`dry_run`	No	Only show what would change, plus the confirm token; write nothing
`next_on`	No	Next follow-up date; default from the follow-up rule
`expected_version`	No	`version` from your last read; the write is refused if the file changed since

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Oct 25, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by explaining the consent requirement, the dry_run/confirm-token flow, the expected_version conflict check, and the backup/undo behavior. These details are important for a destructive, non-idempotent write tool and are not contradicted by the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well structured and front-loaded: it states the core action first, then alternatives, then the write-safety workflow. Given the tool's complexity and confirmation requirements, every sentence carries useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists, the description provides the behavioral context an agent needs: when to use it, what it mutates, how confirmation works, conflict handling, and rollback. It is complete for a complex write tool with eight parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds useful semantics beyond the schema: final=true clears the date and prevents further follow-ups, next_on defaults from the follow-up rule, and confirm is tied to the dry-run flow. It does not individually explain every parameter, but it substantially enriches the important interactions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: recording a follow-up the user actually sent for one job application. It also distinguishes the tool from reschedule_followup, set_status, and followups_due, so an agent can select it without opening sibling schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use this tool versus alternatives: use reschedule_followup when nothing was sent, set_status when the company replied or the application closes, and followups_due to list what is due. The confirmation workflow for writes is also clearly described.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.