Greenhouse MCP

update_job

Modify a Greenhouse job's name, department, offices, notes, or custom fields, changing only the fields you provide.

Instructions

Update a job's name, department, offices, notes, or custom fields. Write operation.

To find job_id: list_jobs → match by name. Only updates fields you provide. For department_id: list_departments. For office_ids: list_offices. To modify the public listing, use update_job_post instead. A job's open/closed status can't be set directly in Harvest v3: close its openings with update_job_opening(status='closed') (list_job_openings to find them).

Input Schema

Name	Required	Description
`name`	No	New internal job name
`notes`	No	Internal notes about the job (HTML supported)
`job_id`	Yes	Greenhouse job ID
`status`	No	Not settable in Harvest v3 — a job's status follows its openings. Use update_job_opening to close or reopen openings instead.
`office_ids`	No	Replaces all office associations — get IDs from list_offices
`custom_fields`	No	Array of {id, value} — replaces the job's custom field values
`department_id`	No	New department ID — get from list_departments
`requisition_id`	No	External requisition/req ID
`how_to_sell_this_job`	No	Internal selling points recruiters use for the role
`team_and_responsibilities`	No	Internal description of the team and responsibilities

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.5.0Oct 5, 2026

addedInput schema / properties / custom_fields

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Array of {id, value} — replaces the job's custom field values",
+  "title": "Custom Fields"
+}

addedInput schema / properties / department_id / description

Added value: +"New department ID — get from list_departments"

addedInput schema / properties / how_to_sell_this_job

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Internal selling points recruiters use for the role",
+  "title": "How To Sell This Job"
+}

addedInput schema / properties / job_id / description
```
Added value: +"Greenhouse job ID"
```
addedInput schema / properties / name / description
```
Added value: +"New internal job name"
```

addedInput schema / properties / notes / description

Added value: +"Internal notes about the job (HTML supported)"

addedInput schema / properties / office_ids / description

Added value: +"Replaces all office associations — get IDs from list_offices"

addedInput schema / properties / requisition_id / description
```
Added value: +"External requisition/req ID"
```

addedInput schema / properties / status / description

Added value: +"Not settable in Harvest v3 — a job's status follows its openings. Use update_job_opening to close or reopen openings instead."

addedInput schema / properties / team_and_responsibilities

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Internal description of the team and responsibilities",
+  "title": "Team And Responsibilities"
+}

Addedv0.3.4Apr 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it flags 'Write operation', discloses partial-update semantics ('Only updates fields you provide'), and surfaces a non-obvious guardrail (status not directly settable in Harvest v3). It stops short of mentioning auth/permission requirements or the irreversibility of replacements, which the schema hints at but the prose does not reinforce.

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 purpose and write semantics, then structured guidance. Most sentences earn their place, though enumerating the updatable fields overlaps with what the schema already lists for a 10-parameter tool.

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

Completeness5/5

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

For a 10-parameter mutation with no annotations and an existing output schema, the description fills the meaningful gaps: write semantics, partial-update behavior, ID sourcing, sibling routing, and a status constraint. Nothing an agent needs to invoke it correctly appears missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning by naming the lookup tool for each ID parameter and calling out the status caveat. This goes beyond restating the schema by connecting parameters to their source tools.

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 (update) and resource (job), enumerates the mutable fields, and explicitly distinguishes itself from siblings update_job_post (public listing) and update_job_opening (status via openings). An agent can tell what this does and what it does not do without opening the schema.

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?

Provides explicit lookup chains (list_jobs → match by name for job_id; list_departments for department_id; list_offices for office_ids), names an alternative for the public listing (update_job_post), and explains the status workaround (update_job_opening(status='closed')). When-to-use, when-not-to-use, and alternatives are all covered.

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

Deploy Server