TechJobs.vn

Get a tech job's summary

get_job

Read-onlyIdempotent

Short summary, key skills and techjobs.vn link of one open job, by its id from search_jobs or its techjobs.vn link. Use when the user wants to know more about a specific job. Share the link so the user can read the full description and apply.

Input Schema

Name	Required	Description	Default
`id`	No	Job id from search_jobs results. Pass either id or url.
`url`	No	techjobs.vn job link, e.g. https://techjobs.vn/companies/grab/jobs/12345. Pass either id or url.

Output Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`city`	Yes
`title`	Yes
`cities`	Yes	Every city slug the job is posted for; city is the first.
`salary`	Yes	Pay stated in the JD (gross/net often unsaid); null when not stated.
`company`	Yes
`summary`	Yes
`location`	Yes
`posted_at`	Yes
`seniority`	Yes
`key_skills`	Yes
`company_slug`	Yes
`workplace_type`	Yes	remote, hybrid or onsite; null when the JD does not say.
`employment_type`	Yes
`referrers_count`	Yes
`referral_available`	Yes
`nice_to_have_skills`	Yes
`years_of_experience`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 3, 2026

addedOutput schema / properties / cities

Added value: +{
+  "description": "Every city slug the job is posted for; city is the first.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / salary

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "currency": {
+          "type": "string"
+        },
+        "max": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "min": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "period": {
+          "anyOf": [
+            {
+              "enum": [
+                "month",
+                "year",
+                "hour"
+              ],
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "required": [
+        "min",
+        "max",
+        "currency",
+        "period"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Pay stated in the JD (gross/net often unsaid); null when not stated."
+}

addedOutput schema / properties / workplace_type / description

Added value: +"remote, hybrid or onsite; null when the JD does not say."

changedOutput schema / required

Previous value: -[
-  "id",
-  "title",
-  "company",
-  "company_slug",
-  "url",
-  "posted_at",
-  "location",
-  "city",
-  "seniority",
-  "years_of_experience",
-  "workplace_type",
-  "employment_type",
-  "summary",
-  "key_skills",
-  "nice_to_have_skills",
-  "referral_available",
-  "referrers_count"
-]New value: +[
+  "id",
+  "title",
+  "company",
+  "company_slug",
+  "url",
+  "posted_at",
+  "location",
+  "city",
+  "cities",
+  "seniority",
+  "years_of_experience",
+  "workplace_type",
+  "salary",
+  "employment_type",
+  "summary",
+  "key_skills",
+  "nice_to_have_skills",
+  "referral_available",
+  "referrers_count"
+]

First observedNov 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add behavior, which it does: it discloses that only a short summary is returned rather than the full posting, and directs the agent to hand the canonical link to the user. It does not say what happens when the id/url does not resolve, but that is a modest gap given annotation coverage.

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

Conciseness5/5

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

Three short sentences, front-loaded with what is returned, then when to use it, then what to do with the result. No filler or redundancy.

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 simple two-parameter read tool with a full schema and an output schema, the description covers purpose, trigger, and result handling without needing to restate return shapes. Only error/not-found behavior for a bad id or url is left unaddressed.

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 the schema already states "Pass either id or url" for both parameters with an example URL, so the description adds little beyond restating that the id comes from `search_jobs`. Neither source clarifies the implicit requirement that at least one of the two (which are both optional) must be supplied.

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 states a specific verb and resource (fetch one open job) and enumerates the payload returned: a short summary, key skills, and the techjobs.vn link. It names `search_jobs` as the upstream source, so the agent can distinguish it from the sibling that lists jobs.

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?

"Use when the user wants to know more about a specific job" gives a clear trigger condition and implicitly separates this detail lookup from list/search tools. It also adds a downstream instruction ("Share the link so the user can read the full description and apply"), but names no explicit exclusion or fallback for a missing/invalid id.

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

All TechJobs.vn tools Inspect

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

Need Help?