Skip to main content
Glama
benmonopoli

Greenhouse MCP

by benmonopoli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

create_or_replace_approval_flow

Create or replace a job approval flow in Greenhouse. Overwrites existing approver groups for the same approval type; new flows stay pending until request_approvals starts them.

Instructions

Create or replace an approval flow for a job. Write operation — overwrites existing.

If the job already has a flow of this approval_type, its approver groups are replaced; otherwise a new flow is created (pending — call request_approvals to start it). To find job_id: list_jobs → match by name. For approver user IDs: list_users → match by name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesGreenhouse job ID
sequentialNoGroups approve one after another (true) or all at once
approval_typeYesFlow type: 'open_job', 'offer_job' or 'offer_candidate'
approver_groupsYesOrdered approver groups: [{approvals_required: N, approvers: [{user_id: N} | {email: '...'}]}]

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.5.0
    • addedInput schema / properties / approval_type / description
      Added value: +"Flow type: 'open_job', 'offer_job' or 'offer_candidate'"
    • addedInput schema / properties / approver_groups / description
      Added value: +"Ordered approver groups: [{approvals_required: N, approvers: [{user_id: N} | {email: '...'}]}]"
    • addedInput schema / properties / job_id / description
      Added value: +"Greenhouse job ID"
    • addedInput schema / properties / sequential
      Added value: +{
+  "default": true,
+  "description": "Groups approve one after another (true) or all at once",
+  "title": "Sequential",
+  "type": "boolean"
+}
  2. Addedv0.3.4

TDQS

A4.5/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 well: it declares the write operation, warns that existing approver groups are overwritten, and discloses the resulting pending state requiring request_approvals. It omits permission/auth requirements and error behavior, which keeps it short of 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the verb, resource, and the critical 'overwrites existing' warning in the first sentence, then layers branch behavior and ID lookups. Every sentence earns its place; nothing is redundant.

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?

An output schema exists so return values need no explanation, and the description covers the mutation semantics, replacement behavior, pending state, and prerequisite lookups. An agent has everything needed to invoke this 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 description coverage is 100%, so the baseline is 3, but the description adds real semantic help the schema lacks: how to obtain job_id (list_jobs → match by name) and approver user IDs (list_users → match by name). It doesn't clarify the nested approver_groups structure beyond the schema, so not a 5.

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+resource with clear semantics: 'Create or replace an approval flow for a job.' It also implicitly distinguishes itself from siblings by noting the flow is created pending and that request_approvals starts it, versus get_approval_flow/list_approvals_for_job which read state.

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?

Explains the two branches (existing flow of this approval_type → groups replaced; otherwise new flow) and routes the agent to request_approvals for activation plus list_jobs/list_users for ID discovery. It does not explicitly say when to prefer this over replace_approver or get_approval_flow, but the context is clear.

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

Deploy Server

Other Tools