JobMojito

List interview results

list_interview_results

Read-onlyIdempotent

[Results] List the merchant's interview results. Rows carry the candidate's scores and recruiter risk flags, so this returns 20 at a time; page with offset while pagination.has_more is true, or narrow with tab/interview_id/filter_text.

Paginated list of a merchant's interview results (the admin-portal results list), scoped to your token's merchant (or a merchant_id override). Capped at 1000 records per page.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tab`	No	Filter by decision/completion state. Omit (or empty) to include all.
`step`	No	Filter by pipeline step type (pre-screening, interview or meeting). Omit for all.
`type`	No	Product type of results to list.	interview
`limit`	No	Maximum number of records to return (1–1000).
`risks`	No	Comma-separated list of recruiter-risk keys to filter by (matches any).
`offset`	No	Number of records to skip from the start of the result set.
`order_by`	No	Sort order of the result set.	created_at_newest
`filter_text`	No	Case-insensitive search on candidate name or email.
`merchant_id`	No	Optional merchant to scope to. Admins and sub-merchant operators only; other callers always use their token's merchant.
`filter_emoji`	No	Filter by the candidate emoji marker.
`interview_id`	No	Filter to a single interview definition id.
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.
`profile_interview_id`	No	Filter to a single candidate (profile_interview) id.

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	The merchant's interview results for this page.
`pagination`	Yes
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 27, 2026

changedInput schema / properties / conversation_id / description

Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."

changedInput schema / properties / step / description

Previous value: -"Filter by pipeline step (pre-screening vs interview). Omit for both."New value: +"Filter by pipeline step type (pre-screening, interview or meeting). Omit for all."

changedInput schema / properties / step / enum

Previous value: -[
-  "pre-screening",
-  "interview"
-]New value: +[
+  "pre-screening",
+  "interview",
+  "meeting"
+]

addedOutput schema / properties / data / items / properties / position_def_step_id

Added value: +{
+  "description": "Position step definition id the row belongs to (null for single-stage interviews).",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / data / items / properties / position_step_count

Added value: +{
+  "description": "Number of steps in the position process.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / data / items / properties / position_step_index

Added value: +{
+  "description": "1-based position of the step in the position process.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / data / items / properties / position_step_name

Added value: +{
+  "description": "Custom name of the position step, null when the step uses its default label.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed2 schema fields changedSep 23, 2026

addedInput schema / properties / conversation_id

Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}

addedOutput schema / properties / _mcp_instructions

Added value: +{
+  "description": "Server-issued metadata for this conversation.",
+  "properties": {
+    "conversation_id": {
+      "description": "The server-issued conversation identifier.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 16, 2026
- changedInput schema / properties / limit / default
```
Previous value: -50New value: +20
```
First observedJul 30, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for adding non-obvious behavior: default 20 rows per call, a 1000-record per-page cap, and that results are scoped to the token's merchant unless merchant_id is overridden. It also notes rows carry candidate scores and recruiter risk flags, which helps an agent anticipate payload shape.

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?

Roughly 85 words is well-sized for a 13-parameter paginated tool, and the paging instruction is front-loaded immediately after the purpose. There is mild redundancy between the opening 'List the merchant's interview results' and the second paragraph's 'Paginated list of a merchant's interview results', but no 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?

An output schema exists, so return values need no explanation, and the description covers the things structured fields can't: the paging loop, the per-page cap, and merchant scoping. What's left unstated is minor (e.g. it doesn't flag that `conversation_id` must be echoed back), and that detail is already carried in the schema.

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 the schema already documents all 13 parameters (including enums, defaults, and the merchant_id admin restriction), setting the baseline at 3. The description adds only light semantic value by tying paging params together via `offset`/`has_more` and restating the 20-default/1000-cap behavior already present in the schema.

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?

The description states a specific verb and resource ('List the merchant's interview results', 'Paginated list of a merchant's interview results') and identifies it as the admin-portal results list, which distinguishes it somewhat from list_interviews/get_interview_result_details. It never names the detail-fetching sibling as the alternative, so the differentiation is implied rather than explicit.

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?

Gives concrete operational guidance: page with `offset` while `pagination.has_more` is true, or narrow with `tab`/`interview_id`/`filter_text`. That tells an agent how and when to drive the tool, but no exclusions or named alternatives (e.g. get_interview_result_details for a single record) are provided.

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

All JobMojito tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.