Skip to main content
Glama

Set the status

set_status
Destructive

Update one job application’s status when a company replies or the application ends, covering rejection, screening, interview, offer, or withdrawal.

Instructions

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.

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

NameRequiredDescriptionDefault
onNoWhen the reply came (the e-mail's date); default today. Goes into the reply date on the first reply
rowYesSheet row number of the application (see list/get results)
noteNoAppended to the notes column
statusYesA value from the status dropdown
confirmNoToken from the dry run the user approved. Not needed when the client shows the server's confirmation dialog
dry_runNoOnly show what would change, plus the confirm token; write nothing
responseNoWhat the company replied; appended to the response column
expected_versionNo`version` from your last read; the write is refused if the file changed since

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4.6/5.0
Behavior4/5

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

Despite annotations covering safety profile (destructive, non-idempotent), the description adds substantial context: dropdown constraint, describe_tracker reference, date-appending behavior, furthest-stage monotonicity, reply-date and follow-up clearing semantics, plus a full confirm/dry_run/expected_version workflow with backup and undo. This is far beyond what annotations alone convey.

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

Conciseness4/5

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

Purpose and sibling routing are front-loaded, then the confirmation workflow. Dense but every sentence carries operational info; a bit long but well organized.

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?

An output schema exists, so return values need not be explained. For an 8-param mutating tool, the description fully covers when to use, alternatives, behavioral side effects, and the confirmation/versioning protocol an agent needs to call correctly.

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%, baseline 3. The description adds meaningful semantics on top: status must come from the tracker dropdown listed by describe_tracker, `on` feeds the reply date only on first reply, response/note are appended, and the confirm/expected_version flow is explained operationally.

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?

States a specific verb+resource+scope: 'Change the status of one job application'. It is explicitly distinguished from mark_applied, close_stale, and edit_application, so an agent can route to it without opening 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?

Gives clear when-to-use ('when the company replies or the application ends') plus explicit alternatives: mark_applied for new submissions, close_stale for many silent applications, edit_application for other cells.

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