Greenhouse MCP

add_email_note_to_candidate

Log an email exchange on a candidate's activity feed in Greenhouse. Records to, from, cc, subject, and body without sending.

Instructions

Log an email on a candidate's activity feed. Write operation.

Records an email exchange (to, from, cc, subject, body) as an activity entry. This logs the email — it does not send one. To get candidate_id: search_candidates_by_name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "candidate_id": "<candidate_id>",
      "to": "<to>",
      "from_": "<from_>",
      "subject": "<subject>",
      "body": "<body>"
    },
    "name": "add_email_note_to_candidate"
  }
}

Input Schema

Name	Required	Description	Default
`cc`	No	Cc email addresses
`to`	Yes	Recipient email address
`body`	Yes	Email body content
`from_`	Yes	Sender email address
`subject`	Yes	Email subject line
`visibility`	No	'public' (default), 'private', or 'admin_only'	public
`candidate_id`	Yes	Greenhouse candidate ID

Output 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 / body / description
```
Added value: +"Email body content"
```
addedInput schema / properties / candidate_id / description
```
Added value: +"Greenhouse candidate ID"
```

addedInput schema / properties / cc

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Cc email addresses",
+  "title": "Cc"
+}

addedInput schema / properties / from_ / description
```
Added value: +"Sender email address"
```
addedInput schema / properties / subject / description
```
Added value: +"Email subject line"
```
addedInput schema / properties / to / description
```
Added value: +"Recipient email address"
```

addedInput schema / properties / visibility

Added value: +{
+  "default": "public",
+  "description": "'public' (default), 'private', or 'admin_only'",
+  "title": "Visibility",
+  "type": "string"
+}

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 full burden and does disclose the key traits: it is a 'Write operation' and it records rather than sends an email. It omits permissions/authorization requirements and the side effects of the visibility setting, so it is not fully complete but adds meaningful behavioral context.

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?

Purpose and write-nature are front-loaded in the first line, with supporting detail after. Slight redundancy between 'Log an email,' 'Records an email exchange,' and 'This logs the email,' but every line still carries a distinct point (purpose, fields, disambiguation, prerequisite).

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 no explanation, and the description covers the write semantics, the log-not-send distinction, and candidate_id acquisition. For a mutation tool with zero annotation coverage it is close to complete, lacking only permission/authorization context.

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 baseline is 3, and the description modestly exceeds it by listing the recorded fields (to, from, cc, subject, body) and explaining how to source the required candidate_id. It adds no format or validation detail beyond what the schema already documents.

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 (Log) and resource (an email on a candidate's activity feed) and immediately disambiguates the action with 'This logs the email — it does not send one,' which separates it from a real email-sending operation. An agent can identify the tool's intent 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 Guidelines4/5

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

Gives clear context (log vs. send) and a concrete prerequisite by routing the agent to search_candidates_by_name for the candidate_id. It does not explicitly contrast with the generic sibling add_note_to_candidate, so it stops short of full when-to-use guidance.

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

Deploy Server