Skip to main content
Glama
benmonopoli

Greenhouse MCP

by benmonopoli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_job_posts

Retrieve all public job posts across jobs, including application questions and locations. Filter by live or internal status and paginate results.

Instructions

List all job posts (public listings) across all jobs. Read-only.

A job post is the public-facing listing for a job. Each post includes its application form questions and a locations array (a post can have several locations in v3). For posts on a specific job, use list_job_posts_for_job (job_id from list_jobs → match by name).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
liveNoFilter: true for published posts only, false for unpublished only, omit for all
cursorNoPass next_cursor from the previous response to get the next page
internalNotrue for internal (employee) board posts, false for external only
paginateNo'single' for one page, 'all' to auto-fetch every pagesingle
per_pageNoResults per page (max 500)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.5.0
    • addedInput schema / properties / cursor
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Pass next_cursor from the previous response to get the next page",
+  "title": "Cursor"
+}
    • addedInput schema / properties / internal
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "true for internal (employee) board posts, false for external only",
+  "title": "Internal"
+}
    • addedInput schema / properties / live / description
      Added value: +"Filter: true for published posts only, false for unpublished only, omit for all"
    • removedInput schema / properties / page
      Removed value: -{
-  "default": 1,
-  "title": "Page",
-  "type": "integer"
-}
    • addedInput schema / properties / paginate / description
      Added value: +"'single' for one page, 'all' to auto-fetch every page"
    • addedInput schema / properties / per_page / description
      Added value: +"Results per page (max 500)"
  2. Addedv0.3.4

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden and does state "Read-only," which is the key safety signal. It further reveals response structure (application form questions, locations array, multi-location in v3), adding real context, though pagination behavior is left to the schema.

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-loaded with the core action and the read-only flag, then supporting definition and routing note. The three sentences all earn their place, though the multi-line formatting is slightly loose for the content volume.

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?

An output schema exists, so return values need not be re-explained, and the description covers scope, the entity definition, and the sibling routing. It is complete enough for correct invocation; only explicit filter-usage guidance is missing.

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 coverage is 100%, so every parameter (live, cursor, internal, paginate, per_page) is already documented in the schema. The description adds nothing about parameter semantics, 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+resource ("List all job posts") and explicitly scopes it to "across all jobs." It also defines what a job post is ("the public-facing listing for a job") and names the sibling it is not, so an agent can distinguish it from list_job_posts_for_job without opening a schema.

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?

Names the alternative (list_job_posts_for_job) and the condition that selects it ("posts on a specific job"), including the practical note on obtaining job_id via list_jobs and matching by name. It does not, however, give guidance on when to use the live/internal filters.

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