Skip to main content
Glama
Sign In
Maestro Career Studio

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Update Application Tracking

update_application
DestructiveIdempotent

Update an application's tracking fields—status, applied_at, notes, or referral_id—without altering untouched fields. Clear notes or unlink a referral when needed.

Instructions

Update an application's tracking fields (status, applied_at, notes, referral_id).

Only the arguments passed are sent to the backend — the PATCH endpoint is
driven by which fields were actually set on the request, so an argument left
out leaves that field untouched. `clear` empties notes or unlinks the
referral (an explicit null on the request).

Allowed statuses: draft, applied, interviewing, offered, accepted, rejected,
withdrawn, skipped (anything else is rejected). `skipped` is the user's own
"not applying to this one". Setting status to applied, interviewing, offered
or accepted also closes any open proposal on the job, recorded as a declined
"applied manually" consent event; skipped closes it as a plain skip.

applied_at sync rule: if you change `status` without also passing `applied_at`,
the backend keeps applied_at in sync automatically — entering "applied" stamps
it with the current time (only if not already set), moving back to "draft"
clears it, and every other status (interviewing/offered/accepted/rejected/
withdrawn/skipped) preserves whatever applied_at already holds. An explicit
`applied_at` overrides that sync and must carry a UTC offset
(e.g. `2026-08-18T14:32:11+00:00`) — a naive value is a 422.

Every status change is logged with its date and who made it (this client's
name). Pass `from_email=True` when you read the change in the user's job
email (the mail-status automation): the log then says it came from mail.

Input Schema

NameRequiredDescriptionDefault
clearNoFields to empty: "notes" removes the notes, "referral_id" unlinks the referral contact (the referral itself is kept). A field given a value in the same call is refused, and nothing is written.
notesNo
statusNo
applied_atNo
from_emailNo
referral_idNo
application_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.0
    • addedInput schema / properties / clear
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "enum": [
+          "notes",
+          "referral_id"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Fields to empty: \"notes\" removes the notes, \"referral_id\" unlinks the referral contact (the referral itself is kept). A field given a value in the same call is refused, and nothing is written.",
+  "title": "Clear"
+}
    • addedInput schema / properties / from_email
      Added value: +{
+  "default": false,
+  "title": "From Email",
+  "type": "boolean"
+}
  2. First observedv0.11.1

TDQS

A4.4/5.0
Behavior5/5

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

Far beyond what the annotations declare: it discloses the PATCH contract, the side effect that certain statuses close an open proposal with a declined 'applied manually' consent event, the applied_at sync rules per status transition, the 422 on naive datetimes, and that every change is logged with date and actor. For a destructive, non-read-only mutation this is exactly the context an agent needs before calling.

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?

Front-loaded with the purpose, then paragraph-per-topic (PATCH semantics, statuses, applied_at sync, logging) with no filler sentences. It is on the long side for seven parameters, but each block maps to a distinct behavior an agent would otherwise get wrong.

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

Completeness4/5

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

Covers the write semantics, side effects, validation errors and logging for a seven-parameter mutation with no output schema. What is missing is the shape of the response (the updated row vs. a bare acknowledgement) and any differentiation from `edit_application`.

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

Parameters5/5

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

Schema coverage is only 14% and `status` has no enum in the schema, so the description carries the load: it enumerates the eight allowed statuses, defines `skipped` in the user's terms, specifies UTC-offset formatting for `applied_at`, and explains that `clear` empties notes or unlinks the referral. That compensates for nearly every undocumented parameter.

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

Purpose4/5

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

The first sentence gives a specific verb and resource plus the exact set of tracking fields it touches (status, applied_at, notes, referral_id). It is clearly a partial PATCH-style update rather than a creation or read. The one gap is that the sibling `edit_application` is never mentioned, so an agent cannot tell from this text why it should pick this tool over that one.

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

Usage Guidelines4/5

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

Explicit when-semantics are given for the trickiest cases: only supplied arguments are sent, `clear` is the way to null a field, and `from_email=True` applies when the change was read in the user's job email. There is no exclusion or alternative-tool routing, and the overlap with `edit_application` goes unaddressed.

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

Deploy Server

Other Tools