Skip to main content
Glama
seinun-ai

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Update Application Tracking

update_application
DestructiveIdempotent

Change a job application's tracking fields, including status, applied date, notes, and referral. Only the fields you pass are modified, so untouched details stay intact.

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 omitting an
argument leaves that field untouched. This tool cannot clear a field back to
null/empty (e.g. remove notes or unlink a referral): omitting an arg skips it
entirely rather than sending an explicit null, and clearing a field requires
the web UI.

Allowed statuses: draft, applied, interviewing, offered, accepted, rejected,
withdrawn (anything else is rejected). Setting status to applied,
interviewing, offered or accepted also closes any open proposal on the job,
recorded as a declined "applied manually" consent event.

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 later stage (interviewing/offered/accepted/rejected/
withdrawn) 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNo
statusNo
applied_atNo
referral_idNo
application_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.4/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description goes well beyond them: PATCH omission semantics, inability to null fields, the allowed status whitelist, a real side effect (setting applied/interviewing/offered/accepted closes open proposals and records a declined 'applied manually' consent event), and a 422 failure mode for naive timestamps. This is rich, non-redundant behavioral disclosure.

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?

Long but front-loaded: the purpose and field list come first, then mutation semantics, then side effects, then the applied_at rule. Nearly every sentence carries operational weight (enum, sync rule, 422 condition), with only mild redundancy in the verbose applied_at paragraph.

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?

For a mutation tool with no output schema, it covers arguments, side effects, validation, and error behavior thoroughly. The one omission is what the tool returns after a successful update, which an agent might want since no output schema exists to describe it.

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 0% with no enums declared, so the description carries the full burden and does: it lists valid status values, documents the applied_at auto-sync algorithm and required UTC offset format with an example, and states that notes/referral_id cannot be cleared. Meaning is added for every meaningful argument beyond the bare anyOf string/null schema.

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?

Specific verb+resource: 'Update an application's tracking fields' with the exact field set (status, applied_at, notes, referral_id) enumerated, which effectively separates it from the sibling edit_application. It never names a sibling explicitly, so it stops short of full differentiation.

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?

Gives a clear when-not with a concrete alternative: clearing a field back to null is impossible here and 'requires the web UI', and it explains the omission-vs-null PATCH rule that governs all invocations. No sibling tool is offered as an alternative for related edits, but the operational context is explicit.

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