Skip to main content
Glama
Sign In

TechJobs.vn

by vn.techjobs
OverviewDiscussionsAdmin

Track a job in my Apply Tracker

track_job
DestructiveIdempotent

Requires techjobs.vn sign-in. Adds a techjobs.vn job to the signed-in user's Apply Tracker or moves it to another status (e.g. applied, interviewing), optionally with a note and tracker details (source, salary, next step, outcome reason). Calling it again with the same arguments changes nothing. The change shows on techjobs.vn right away. To edit an entry by id (including jobs added by hand), use update_application.

Input Schema

NameRequiredDescriptionDefault
noteNoThe user's own note. Replaces the current note; omit to keep it, empty string to clear it.
job_idYesJob id from search_jobs, get_job, list_applications or suggest_jobs_for_me.
statusYesApply Tracker status: wishlist (saved), clicked (opened the apply link), applied, screening, interviewing, offer, rejected, withdrawn, accepted (took the offer).
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).
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.1/5.0
Behavior4/5

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

Beyond the annotations it adds two real pieces of context: a sign-in requirement and immediate propagation ('the change shows on techjobs.vn right away'). The idempotency sentence just restates idempotentHint=true, and it never explains the destructiveHint=true flag (e.g. that adding an entry creates persistent tracker state), so the safety profile is not fully illuminated.

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 purpose, then persistence behavior, then the sibling alternative — a sensible order. One sentence ('Calling it again with the same arguments changes nothing') merely echoes idempotentHint and could be cut without losing information.

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 upsert with no output schema, the description covers auth, create-vs-status-change, idempotency, immediate effect, and the correct alternative tool. It is only slightly short on explaining the destructive flag and whether partial updates merge into an existing entry versus creating one.

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%, so the schema already documents every one of the 19 parameters, including the omit-to-keep and clear_fields conventions. The description only loosely groups the optional fields ('a note and tracker details (source, salary, next step, outcome reason)'), adding little beyond the schema baseline.

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 names a specific verb and resource ('Adds a techjobs.vn job to the signed-in user's Apply Tracker or moves it to another status') and immediately contrasts with the sibling update_application for id-based edits. An agent can distinguish it from update_application and list_applications without opening a schema.

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?

It gives a concrete routing rule: use this tool to add a job or change status, and use update_application to edit an entry by id (including hand-added jobs). That is clear context plus one explicit alternative, though it does not spell out the inverse condition (when this tool is the wrong choice for an already-tracked application).

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