JobMojito

List interviews

list_interviews

Read-onlyIdempotent

[Interviews] List the merchant's interview definitions.

Paginated list of a merchant's interview definitions (the admin-portal interview 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
`type`	No	Product type of interviews to list.	interview
`limit`	No	Maximum number of records to return (1–1000).
`offset`	No	Number of records to skip from the start of the result set.
`status`	No	Filter by lifecycle status. Omit to include all statuses.
`show_demo`	No	Include demo/sample interviews.	false
`filter_text`	No	Case-insensitive search on the interview name.
`merchant_id`	No	Optional merchant to scope to. Admins and sub-merchant operators only; other callers always use their token's merchant.
`show_public`	No	Include interviews shared publicly across merchants (coaching/avatars).	false
`filter_emoji`	No	Filter by the interview emoji marker.
`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.

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	The merchant's interview definitions for this page, newest-updated first.
`pagination`	Yes
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field 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."

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"
+}

First observedJul 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful operational context on top: the 1000-record per-page cap, the merchant-token scoping default, and the admin-only restriction on merchant_id. It stops short of describing what a page contains or how to page through beyond limit/offset.

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?

Two short paragraphs, front-loaded with the resource label, then scope and cap. 'Paginated list' mildly restates the title, but the second sentence carries real information without padding.

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, all ten parameters are documented in-schema, and annotations carry the safety profile. The description supplies the remaining missing pieces an agent needs: scope resolution and the page-size ceiling.

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%, so the schema already documents all ten parameters including enums, defaults, ranges and examples; baseline 3 applies. The description only reinforces scoping (merchant_id override, 1000 cap) and adds no syntax or format detail beyond 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?

States a specific verb and resource ('List the merchant's interview definitions') and clarifies it is the admin-portal interview definition list, which implicitly separates it from list_interview_results. It never explicitly names a sibling, so differentiation is left to the reader's inference between 'definitions' and 'results'.

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?

Gives scoping guidance — the list is bound to the token's merchant unless an admin/sub-merchant operator passes merchant_id — and states the 1000-record page cap. However, it never says when to use this tool instead of get_interview_definition or list_interview_results, and there are no exclusions or prerequisites beyond the scope note.

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.