Skip to main content
Glama
benmonopoli

Greenhouse MCP

by benmonopoli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_answers

Retrieve demographic survey responses from candidates, including application, question, and answer option IDs, with pagination and date filtering.

Instructions

List all demographic survey responses submitted by candidates. Read-only.

Each answer has application_id, demographic_question_id, demographic_answer_option_id and free_form_text. Resolve labels with list_questions and list_answer_options.

Input Schema

NameRequiredDescriptionDefault
cursorNoPass next_cursor from the previous response to get the next page
paginateNo'single' for one page, 'all' to auto-fetch every pagesingle
per_pageNoResults per page (max 500)
created_afterNoISO 8601 datetime — only answers created after this

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.5.0
    • addedInput schema / properties / created_after
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "ISO 8601 datetime — only answers created after this",
+  "title": "Created After"
+}
    • 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"
+}
    • 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

A3.5/5.0
Behavior3/5

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

With no annotations present, the description carries the full burden. It does disclose that the operation is 'Read-only' and enumerates the shape of each returned answer, which is meaningful behavioral context. It stops short of noting any auth/permission requirements or result-volume considerations for an all-records listing.

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 purpose, then the read-only note, then the field shape and label-resolution tip. Very little waste, though the final sentence could be slightly tighter.

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 needn't be explained, yet the description still helpfully summarizes the answer fields. Read-only status and label-resolution pointers are included. The one gap is the absence of differentiation from the closely named sibling list_answers_for_application.

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%, with cursor, paginate, per_page and created_after each documented in the schema, so the baseline is 3. The description adds no further parameter meaning (e.g., it never mentions date filtering), so it neither compensates nor detracts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List all demographic survey responses submitted by candidates'), which is clear enough to identify the entity being read. It implies an unfiltered listing that contrasts with the sibling list_answers_for_application, but never names that sibling to make the distinction explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only routing guidance is 'Resolve labels with list_questions and list_answer_options,' which is genuinely useful for follow-up lookups. However, there is no when-to-use guidance versus the very similar list_answers_for_application, nor any stated prerequisites, so usage is only implied.

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