Greenhouse MCP

update_office

Update an existing office's name, location, parent office, or primary contact. Use list_offices to get the office ID; admin-only write operation.

Instructions

Update an office's name, location, parent or contact. Write operation — admin only.

To find office_id: list_offices → match by name. Greenhouse requires the name on every update, so the current name is kept when name is omitted.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New office name
`location`	No	New location string
`office_id`	Yes	Office ID to update
`parent_id`	No	New parent office ID — get from list_offices
`primary_contact_user_id`	No	User ID of the new primary in-house contact

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.5.0Oct 5, 2026

addedInput schema / properties / location / description
```
Added value: +"New location string"
```
addedInput schema / properties / name / description
```
Added value: +"New office name"
```
addedInput schema / properties / office_id / description
```
Added value: +"Office ID to update"
```

addedInput schema / properties / parent_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "New parent office ID — get from list_offices",
+  "title": "Parent Id"
+}

addedInput schema / properties / primary_contact_user_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "User ID of the new primary in-house contact",
+  "title": "Primary Contact User Id"
+}

Addedv0.3.4Apr 15, 2026

TDQS

A4.1/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 disclose meaningful traits: it is a write operation, requires admin rights, and explains the non-obvious name-retention behavior ('current name is kept when name is omitted'). It does not address reversibility or what happens to unspecified fields, but it adds substantial context beyond structured data.

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?

Two sentences, front-loaded with the operation and constraints, followed by the practical lookup and name-retention notes. No wasted text; every sentence 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 an unannotated mutation tool, the description covers purpose, permissions, parameter sourcing, and a behavioral quirk; only minor gaps (reversibility, handling of omitted fields) remain.

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 coverage is 100%, so the schema already documents all five parameters (baseline 3). The description adds real value beyond the schema: how to source office_id and the name-required workaround, both of which affect how parameters must be supplied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource plus the updatable fields ('Update an office's name, location, parent or contact'). An agent can identify the operation immediately, though it does not explicitly differentiate itself from siblings like create_office or update_department.

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?

Provides concrete routing guidance for the required parameter ('To find office_id: list_offices → match by name') and states the prerequisite ('admin only'). No explicit when-not guidance or comparison to alternative tools, but the context needed to invoke it is clear.

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

Deploy Server