Greenhouse MCP

reject_application

Reject a candidate from a specific Greenhouse job application by providing the application ID and a required rejection reason ID. Optionally send a rejection email and internal notes.

Instructions

Reject a candidate from a job. Write operation.

Users say "reject Sarah from the Backend role." To get the application_id: search_candidates_by_name → get_candidate → match the application to the job. A rejection_reason_id is required: list_rejection_reasons → match by name. For email templates: list_email_templates; the email is sent from email_from_user_id, defaulting to the configured Greenhouse user. Can be reversed with unreject_application. For bulk rejections, use bulk_reject.

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": {
      "application_id": "<application_id>",
      "rejection_reason_id": "<rejection_reason_id>"
    },
    "name": "reject_application"
  }
}

Input Schema

Name	Required	Description
`notes`	No	Internal rejection notes (not sent to candidate)
`application_id`	Yes	Greenhouse application ID
`rejection_email`	No	Optional email to candidate: {email_template_id, send_email_at (ISO 8601), email_from_user_id}
`rejection_reason_id`	Yes	Reason ID (required) — get from list_rejection_reasons

Output 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 / description
```
Added value: +"Greenhouse application ID"
```

addedInput schema / properties / notes / description

Added value: +"Internal rejection notes (not sent to candidate)"

addedInput schema / properties / rejection_email / description

Added value: +"Optional email to candidate: {email_template_id, send_email_at (ISO 8601), email_from_user_id}"

removedInput schema / properties / rejection_reason_id / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / rejection_reason_id / default
```
Removed value: -null
```

addedInput schema / properties / rejection_reason_id / description

Added value: +"Reason ID (required) — get from list_rejection_reasons"

addedInput schema / properties / rejection_reason_id / type
```
Added value: +"integer"
```

changedInput schema / required

Previous value: -[
-  "application_id"
-]New value: +[
+  "application_id",
+  "rejection_reason_id"
+]

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 substantial work: it declares the operation is a write, discloses reversibility via unreject_application, and explains that an email is sent from email_from_user_id defaulting to the configured Greenhouse user. Permission requirements and side effects on application state aren't fully detailed, keeping it below a 5.

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-loads the verb, resource, and operation type, then layers the ID-resolution guidance. Dense but every sentence earns its place; the workflow arrows make it scannable rather than verbose.

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?

Given an output schema exists, return values need not be explained. For a mutation tool with no annotations, the description still covers purpose, prerequisites, side effects, defaults, and alternatives, so an agent has everything needed to call it correctly.

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, but the description adds real value: it tells the agent how to obtain application_id and rejection_reason_id (via search_candidates_by_name/get_candidate and list_rejection_reasons) and documents the default behavior of email_from_user_id, which the schema does not.

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 ('Reject a candidate from a job') and immediately flags the operation class with 'Write operation.' An agent can distinguish it from siblings like bulk_reject and unreject_application without opening either 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?

Explicitly maps the natural-language request to the required workflow (search_candidates_by_name → get_candidate → match application), names the alternative for bulk cases ('use bulk_reject'), and points to unreject_application for reversal. When/when-not 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