Skip to main content
Glama
Sign In

TechJobs.vn

by vn.techjobs
OverviewDiscussionsAdmin

Update a tracked application

update_application
DestructiveIdempotent

Requires techjobs.vn sign-in. Edits one entry of the signed-in user's Apply Tracker by its id: status, note and tracker details (source, CV used, salary, work mode, excitement, next step and its due date, outcome reason). Only the fields you pass change. Take the id from list_applications; to add a job or only move its status, track_job is simpler.

Input Schema

NameRequiredDescriptionDefault
noteNoThe user's own note. Replaces the current note; omit to keep it, empty string to clear it.
statusNoMove the entry to this status. Omit to keep the current status.
locationNoJob location. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
work_modeNoonsite, hybrid or remote. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
excitementNoHow much the user wants the job, 1-5. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
salary_maxNoHighest salary offered or expected. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
salary_minNoLowest salary offered or expected. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
next_actionNoThe user's next step, e.g. "Follow up with the recruiter". Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
clear_fieldsNoDetails to remove from the entry, by name, e.g. ["salary_min", "excitement"].
cover_letterNoWhether a cover letter was sent. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
outcome_noteNoFree text about the outcome. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
cv_variant_idNoId of the CV (from list_my_cvs) sent with this application. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
salary_periodNomonth or year. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
application_idYesApply Tracker entry id: the `id` of an entry from list_applications or track_job.
next_action_atNoISO date or datetime the next step is due, e.g. 2026-10-12. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
outcome_reasonNoWhy the process ended (rejected, withdrawn, accepted…). Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
recruiter_nameNoRecruiter or hiring contact. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
source_channelNoWhere the user found or applied to the job. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).
salary_currencyNoCurrency of the salary. Omit to keep the current value; to remove it, name it in clear_fields (text can also be cleared with an empty string).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the write/destructive/idempotent/local profile, and the description adds two pieces of context the annotations cannot: a sign-in requirement and the patch semantics ('Only the fields you pass change'), which substantiates the idempotentHint. It does not say what happens on invalid status transitions or whether edits are recoverable, which would have pushed this higher.

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-loads the auth prerequisite, then the action, then the routing hint — good ordering in three sentences. The parenthetical enumeration of tracker details is long and duplicates the schema's property list, costing some tightness.

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 19-parameter mutation with no output schema, the description covers the essentials: auth, id provenance, partial-update behavior, and the simpler sibling. It leaves out outcome-shaped constraints (e.g. whether status can move anywhere, what a successful update returns) but nothing that would cause a misinvocation.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter already documents its own omit-to-keep and clearing behavior, so the schema carries most of the burden. The description's field enumeration and the 'only fields you pass change' rule restate what the schema already says per-property; it adds no extra syntax or edge-case guidance (e.g. clearing via clear_fields vs empty string).

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 and resource ('Edits one entry of the signed-in user's Apply Tracker by its id') and enumerates the editable field families, so the agent knows exactly what is mutated. It also explicitly separates itself from track_job (add a job / status-only moves) and list_applications (id source).

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 explicit when-to-use routing: take the id from list_applications, and use track_job instead if the goal is adding a job or only changing status. This is a real alternative-plus-condition statement, not just implied context.

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

All TechJobs.vn toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources