Greenhouse MCP

add_attachment

Attach a resume, cover letter, or file to a Greenhouse candidate by URL or base64 content; target a specific application or the active one.

Instructions

Attach a file (resume, cover letter, etc.) to a candidate. Write operation.

Harvest v3 stores every attachment on an application, so this attaches to application_id if given, otherwise to the candidate's most recently active application (the response's application_id shows which). To get candidate_id: search_candidates_by_name. To choose the application, see get_candidate's applications array, or use add_attachment_to_application.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	Public URL to fetch the file from — provide this OR content, not both
`type`	Yes	Type: 'resume', 'cover_letter', 'take_home_test', 'other', ... ('admin_only' = 'other' with admin-only visibility)
`content`	No	Base64-encoded file content — provide this OR url, not both
`filename`	Yes	File name with extension, e.g. 'resume.pdf'
`visibility`	No	Who can see it: 'public', 'private', or 'admin_only'
`candidate_id`	Yes	Greenhouse candidate ID
`application_id`	No	Application to attach to — omit to use the candidate's most recently active application

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.5.0Oct 5, 2026

addedInput schema / properties / application_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Application to attach to — omit to use the candidate's most recently active application",
+  "title": "Application Id"
+}

addedInput schema / properties / candidate_id / description
```
Added value: +"Greenhouse candidate ID"
```

addedInput schema / properties / content / description

Added value: +"Base64-encoded file content — provide this OR url, not both"

removedInput schema / properties / content_type

Removed value: -{
-  "default": "application/pdf",
-  "title": "Content Type",
-  "type": "string"
-}

addedInput schema / properties / filename / description

Added value: +"File name with extension, e.g. 'resume.pdf'"

addedInput schema / properties / type / description

Added value: +"Type: 'resume', 'cover_letter', 'take_home_test', 'other', ... ('admin_only' = 'other' with admin-only visibility)"

addedInput schema / properties / url / description

Added value: +"Public URL to fetch the file from — provide this OR content, not both"

addedInput schema / properties / visibility

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Who can see it: 'public', 'private', or 'admin_only'",
+  "title": "Visibility"
+}

Addedv0.3.4Apr 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does disclose the non-obvious default: attachments land on application_id if given, otherwise on the candidate's most recently active application, with the response's application_id indicating which. That is genuine behavioral value. It stops short of stating auth/permission requirements, failure modes, or the visibility default, so it isn't fully transparent.

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 the verb and the write-operation warning, and each following sentence carries routing or defaulting information. The hard line breaks make it slightly choppier than necessary, but there is no filler.

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 needn't be re-explained, and the description covers the mutation nature, the application-resolution default, and the sibling alternative. What remains thin is permission/auth context for a write operation with no annotations, but for a simple attach call the essentials are present.

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 all seven parameters are already documented, including the url-vs-content exclusivity, type values, and application_id default. The description largely reiterates the application_id fallback and points at where to find candidate_id rather than adding new syntax or format detail. Baseline 3 is appropriate.

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 and resource ('Attach a file ... to a candidate') and immediately labels it a write operation. It distinguishes itself from the sibling add_attachment_to_application by naming that alternative explicitly, so an agent can pick the right tool 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when/when-not routing: use search_candidates_by_name to obtain candidate_id, and inspect get_candidate's applications array or switch to add_attachment_to_application when you need to pick the application. It also explains the omission case for application_id. Nothing is left to inference.

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

Deploy Server