Greenhouse MCP

update_user

Update a Greenhouse user's name, job title, primary email, offices, or departments. Use the user ID to apply changes; primary email must already be verified.

Instructions

Update a user's name, title, primary email, offices or departments. Write operation.

To find user_id: list_users → match by name or email. To make a new address primary, first add it with add_email_to_user and have it verified.

Input Schema

TableJSON Schema

Name	Required	Description
`user_id`	Yes	Greenhouse user ID
`job_title`	No	New job title
`last_name`	No	New last name
`first_name`	No	New first name
`office_ids`	No	Replace the user's offices — get from list_offices
`primary_email`	No	New primary email — must already be a verified email on the user
`department_ids`	No	Replace the user's departments — get from list_departments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.5.0Oct 5, 2026

addedInput schema / properties / department_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Replace the user's departments — get from list_departments",
+  "title": "Department Ids"
+}

addedInput schema / properties / first_name / description
```
Added value: +"New first name"
```

addedInput schema / properties / job_title

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "New job title",
+  "title": "Job Title"
+}

addedInput schema / properties / last_name / description
```
Added value: +"New last name"
```

addedInput schema / properties / office_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Replace the user's offices — get from list_offices",
+  "title": "Office Ids"
+}

addedInput schema / properties / primary_email

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "New primary email — must already be a verified email on the user",
+  "title": "Primary Email"
+}

addedInput schema / properties / user_id / description
```
Added value: +"Greenhouse user ID"
```

Addedv0.3.4Apr 15, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It does label itself a 'Write operation' and discloses the verified-email prerequisite for primary_email, which is genuine context. However, it says nothing about required permission level (e.g., admin), reversibility of the replace-style office/department updates, or error behavior for a destructive-feeling mutation.

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?

Front-loads the action, affected fields, and write nature in the first sentence, then adds two tightly scoped workflow notes. No filler sentences; every line earns its place.

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?

An output schema exists, so return values need not be explained. For a 7-parameter mutation with no annotations, the definition covers field scope, mutation nature, ID resolution, and the primary-email prerequisite. The main remaining gap is permission/authorization requirements.

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 each parameter, including the replace semantics and that primary_email must be verified. The description adds the list_users lookup path and the add_email_to_user prerequisite, but largely restates what the schema provides, so baseline 3 applies.

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) plus the resource (user) and enumerates the mutable fields (name, title, primary email, offices, departments). This clearly distinguishes it from siblings like update_candidate, update_department, and update_office without needing to open any 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?

Gives actionable prerequisites: route the agent to list_users to resolve user_id, and instructs that a new primary address must first be added via add_email_to_user and verified. It names concrete alternatives/prerequisites, though it stops short of any explicit 'when not to use this' exclusions.

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

Deploy Server