Skip to main content
Glama
benmonopoli

Greenhouse MCP

by benmonopoli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

advance_application

Move a candidate forward one stage in their job pipeline. Specify the application ID; omit the target stage to advance to the natural next stage.

Instructions

Move a candidate forward one stage in their job pipeline. Write operation.

Users say "advance Sarah to the next stage" or "move John forward." To get the application_id: search_candidates_by_name → get_candidate → match the application to the job. from_stage_id must be the application's current job_interview_stage_id (Greenhouse rejects stale moves); omit it and it is looked up for you. Omit to_stage_id to advance to the natural next stage. To skip stages, use move_application_same_job. For bulk advancing, use bulk_advance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_stage_idNoTarget stage — from list_job_stages_for_job. Omit for next stage
from_stage_idNoCurrent job_interview_stage_id (from get_application). Omit to look it up automatically
application_idYesGreenhouse application ID

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.5.0
    • addedInput schema / properties / application_id / description
      Added value: +"Greenhouse application ID"
    • addedInput schema / properties / from_stage_id / anyOf
      Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / from_stage_id / default
      Added value: +null
    • addedInput schema / properties / from_stage_id / description
      Added value: +"Current job_interview_stage_id (from get_application). Omit to look it up automatically"
    • removedInput schema / properties / from_stage_id / type
      Removed value: -"integer"
    • addedInput schema / properties / to_stage_id / description
      Added value: +"Target stage — from list_job_stages_for_job. Omit for next stage"
    • changedInput schema / required
      Previous value: -[
-  "application_id",
-  "from_stage_id"
-]New value: +[
+  "application_id"
+]
  2. Addedv0.3.4

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 disclose meaningful behavior: it flags 'Write operation', warns that Greenhouse rejects stale moves unless from_stage_id matches the current job_interview_stage_id, and notes that omitting from_stage_id triggers an automatic lookup. It stops short of covering permission/auth requirements or failure modes beyond the staleness check, so it is strong but not exhaustive.

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 core action in the first sentence, then layers the ID-resolution workflow, parameter constraints, and alternatives. Every sentence earns its place; the quoted user utterances map directly to routing decisions rather than being filler.

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 3-param write tool with no annotations but with an output schema (so return values need no explanation) and full schema coverage, the description supplies the workflow, the key failure constraint, and the sibling alternatives. It omits permission/auth context and non-staleness error behavior, leaving a small but real gap.

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 semantic value beyond the schema: from_stage_id must equal the application's current job_interview_stage_id or the write is rejected, and omitting it is auto-resolved; omitting to_stage_id advances to the natural next stage. That constraint-level detail exceeds what the property descriptions state.

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+scope: 'Move a candidate forward one stage in their job pipeline.' It explicitly names and distinguishes the two nearest siblings, move_application_same_job (skipping stages) and bulk_advance (bulk), so 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?

Provides explicit when-to-use via user utterance examples ('advance Sarah to the next stage'), states the preconditions for the key input (how to obtain application_id via search_candidates_by_name → get_candidate → match to job), and names alternatives with the condition that selects them (skip stages, bulk advancing). Nothing is left 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

Other Tools