Greenhouse MCP

submit_application

Apply to a job through the public Greenhouse board as an external candidate by sending applicant details, resume, and cover letter to the posting.

Instructions

Submit an application through the public job board. Write operation.

For internal application creation (as a recruiter/admin), use create_application instead. This endpoint mirrors what external candidates do when they apply through the public board.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	Applicant's email address
`phone`	No	Applicant's phone number
`job_id`	Yes	Board job ID — from list_board_jobs
`resume`	No	Resume content or URL
`last_name`	Yes	Applicant's last name
`first_name`	Yes	Applicant's first name
`cover_letter`	No	Cover letter text
`mapped_url_token`	No	Tracking link token for source attribution

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 / cover_letter / description
```
Added value: +"Cover letter text"
```
- addedInput schema / properties / email / description
```
Added value: +"Applicant's email address"
```
- addedInput schema / properties / first_name / description
```
Added value: +"Applicant's first name"
```
- addedInput schema / properties / job_id / description
```
Added value: +"Board job ID — from list_board_jobs"
```
- addedInput schema / properties / last_name / description
```
Added value: +"Applicant's last name"
```
- addedInput schema / properties / mapped_url_token / description
```
Added value: +"Tracking link token for source attribution"
```
- addedInput schema / properties / phone / description
```
Added value: +"Applicant's phone number"
```
- addedInput schema / properties / resume / description
```
Added value: +"Resume content or URL"
```
Addedv0.3.4Apr 15, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose that this is a write operation and frames the semantics as an external-candidate submission, which is useful. However, it says nothing about side effects, duplicate-application handling, notification triggers, or auth requirements expected of a public endpoint.

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?

Three short sentences, front-loaded with the core action and write nature before the routing advice. The closing sentence partly restates the 'public job board' framing of sentence one, a minor redundancy but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 all 8 parameters are documented in the schema. What remains missing is behavioral context for a write tool with zero annotations: side effects, whether it creates a candidate record, and duplicate handling are all unstated.

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% and each field (email, phone, job_id, resume, cover_letter, mapped_url_token) is documented in the schema, including that job_id comes from list_board_jobs. The description adds no parameter-level detail, so the 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 (submit) and resource (application) plus the channel (public job board), and explicitly contrasts itself with the sibling create_application. An agent can distinguish it from the internal-creation tool 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?

Names the alternative tool and the condition that selects it: internal recruiter/admin creation goes to create_application, while this mirrors the external candidate path. The when-not is implied by that same contrast, leaving little 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