Greenhouse MCP

create_tag

Create a new candidate tag for Greenhouse ATS to organize applicants; then apply it to candidates with add_tag_to_candidate.

Instructions

Create a new candidate tag. Write operation.

After creating, use add_tag_to_candidate to apply it. Note: bulk_tag creates tags on-the-fly, so pre-creation isn't needed for bulk ops.

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": {
      "name": "<name>"
    },
    "name": "create_tag"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Tag name — must be unique across the organization

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.0Oct 5, 2026
- addedInput schema / properties / name / description
```
Added value: +"Tag name — must be unique across the organization"
```
Addedv0.3.4Apr 15, 2026

TDQS

A4.2/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 burden. It does declare 'Write operation', which is the key safety signal, and notes the two-step create-then-apply workflow. However it says nothing about permission requirements, what happens on a duplicate name, or idempotency — relevant gaps for a mutation with zero annotation coverage (return format is covered by the output schema, so that omission is acceptable).

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?

Three short sentences, front-loaded with the operation and its write nature, then the follow-up action, then the alternative. Every sentence earns its place and none is redundant with structured fields.

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?

For a one-parameter mutation with an output schema and a well-described parameter, the description is largely complete: it establishes the write nature and routes to the correct follow-up and sibling tools. It falls short only on operational behavior (permissions, duplicate-name handling) that an agent might need under failure conditions.

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?

There is a single parameter and schema description coverage is 100% — the schema already documents both the name field and the organization-wide uniqueness constraint. The description adds no syntax, format, or constraint detail beyond that, 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 and resource ('Create a new candidate tag') and immediately differentiates from the two most confusable siblings: add_tag_to_candidate (applies an existing tag) and bulk_tag (creates tags implicitly). An agent can route correctly without opening any 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 explicit workflow ordering ('After creating, use add_tag_to_candidate to apply it') and an explicit exclusion ('bulk_tag creates tags on-the-fly, so pre-creation isn't needed for bulk ops'). This is exactly when-to-use / when-not-to-use with named alternatives.

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

Deploy Server