JobMojito

Get interview definition

get_interview_definition

Read-onlyIdempotent

[Interviews] Get the definition/configuration of an interview (position), including its ordered questions array. The questions come back in the same format create_interview_from_questions accepts, so you can read an interview here, change the array, and send it to update_interview. Each question's id identifies it — keep the ids you did not mean to change.

Retrieves the interview definition for a given interview-definition id or position id. Returns the compiled calc_definition_json, the ordered questions array (in the same format job-interview-create-from-array accepts, so it round-trips into job-interview-update) plus basic metadata. Access is subject to the caller's row-level security.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`position_id`	Yes	Identifier of either an interview definition (single-stage) or a position definition (multi-stage). The function resolves whichever matches.

Output Schema

TableJSON Schema

Name	Required	Description
`code`	Yes	Caller-supplied external code/reference.
`name`	Yes	Interview or position name.
`slug`	Yes	URL slug of the public listing, when one was generated.
`tags`	Yes	Free-form tags. Also the coaching-catalogue mapping key: a catalogue directory lists this session when its `tags_interview_set_filter` is a subset of these tags. Null for multi-stage positions.
`type`	Yes	Interview type. Null for multi-stage positions.
`stage`	Yes	Hiring-pipeline stage. Null for multi-stage positions.
`status`	Yes	Lifecycle status of the interview/position.
`questions`	Yes	The interview questions, in the order they are asked, in the same format job-interview-create-from-array accepts — so this array can be edited and sent straight back to job-interview-update, or used to create a copy of this interview. Each `id` is the question's real identifier: send it back unchanged and the question keeps its existing record (and with it its answer rules and any rendered avatar video). The welcome, thank-you and instructional-video steps are NOT included — they are not questions in this format, and job-interview-update leaves them untouched. Null for multi-stage positions, whose questions live on the individual interview stages.
`recording`	Yes	Per-answer recording mode. Null for multi-stage positions.
`coach_plan`	Yes	Coaching-plan stage this session belongs to. Null for multi-stage positions and for sessions outside any plan.
`created_at`	Yes
`updated_at`	Yes
`visibility`	Yes	Who can see and access the interview/position.
`description`	Yes	Short description.
`merchant_id`	Yes	Owning merchant id.
`result_view`	Yes	Result view level. Null for multi-stage positions.
`type_credit`	Yes	Credit bucket the interview draws from. Null for multi-stage positions.
`max_duration`	Yes	Live session limit in seconds. Null for multi-stage positions.
`is_multistage`	Yes	True when the id resolved to a multi-stage position rather than a single interview.
`is_voice_only`	Yes	Convenience flag derived from interview_template_type: true when voice-only (`interactive_elevenlabs`), false when avatar-based, null when the template type could not be resolved.
`max_followups`	Yes	Maximum number of AI follow-up questions; null uses the template default. Null for multi-stage positions.
`result_scoring`	No	Resolved result-scoring config (update field `custom_scoring`; its `max_retries` is the update field `interview_attempts`). Null means the platform defaults apply. Null for multi-stage positions.
`cover_image_url`	Yes	Cover image URL.
`interview_salary`	Yes	Salary range shown for the position.
`interview_location`	Yes	Location (create field `location`).
`creation_parameters`	No	The creation parameters recorded at build time (interview_type, interview_tone, interview_length, additional_context, include_rapport_question, include_closing_prompt, knowledge_base_store_id, seniority_level, hiring_for_company).
`calc_definition_json`	No	The compiled interview definition JSON (structure varies by interview type).
`interview_department`	Yes	Department the position belongs to.
`mojito_language_code`	Yes	Platform (mojito) language code.
`recruiter_profile_id`	Yes	Profile id of the recruiter owning this interview/position.
`speech_language_code`	Yes	Azure speech language code. Null for multi-stage positions.
`speech_language_name`	Yes	Azure speech language display name. Null for multi-stage positions.
`interview_template_id`	Yes	Interview template id. For multi-stage positions this is the first interview step's template.
`candidate_expectations`	Yes	Free-text candidate expectations. Null for multi-stage positions.
`pdf_export_auto_config`	No	Auto-PDF-report options applied when the interview completes; null when auto-export is off. Null for multi-stage positions.
`recording_full_session`	Yes	Full-session recording mode. Null for multi-stage positions.
`required_pronunciation`	Yes	Whether a pronunciation assessment is required. Null for multi-stage positions.
`interview_template_type`	Yes	Type of the linked interview template. `interactive_elevenlabs` is voice-only; the others (`interactive_heygen`, `offline_heygen`, `offline_elai`, `offline_synthesia`) are avatar-based. Null when the template could not be resolved.
`knowledge_base_store_id`	Yes	Linked knowledge base store id. Null for multi-stage positions.
`questions_random_subset`	Yes	Fraction of the questions actually asked (0.01-0.9); null asks all of them. Null for multi-stage positions.
`interview_available_till`	Yes	ISO date/time after which the interview is no longer available to candidates. Null means always available.
`interview_description_long`	Yes	Long description (create/update field `description_long`). Rendered as Markdown on the candidate-facing position page — formatting guide: https://developer.jobmojito.com/cookbooks/format-content-with-markdown
`candidate_expectations_json`	No	Structured candidate expectations JSON — the scoring rubric. Null for multi-stage positions.
`candidate_video_introduction`	Yes	Whether a candidate video introduction is hidden/optional/required. Null for multi-stage positions.
`interview_conversation_speed`	Yes	Conversation pace of the AI avatar (slower/normal/faster). Null keeps the template default. Null for multi-stage positions.
`result_enable_edit_transcript`	Yes	Whether the candidate may edit the transcript on the result view. Null for multi-stage positions.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate this is read-only, idempotent, and non-destructive. The description adds useful context: returns include `calc_definition_json`, metadata, and question ids should be preserved for round-tripping. It also discloses row-level security restrictions, which is valuable beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and workflow, but it has redundant phrasing: both paragraphs repeat the same-format round-trip point using different names. A tighter version would be just as clear with less duplication.

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?

With a full schema covering the only parameter, rich annotations, and an output schema, the description still adds all necessary behavioral context: resolved ID types, returned fields, workflow usage, and row-level security. An agent has enough information to call and use this tool correctly.

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%, and the schema already explains that `position_id` can be an interview or a position definition id. The description reinforces the round-trip purpose but does not add further parameter details, so the baseline of 3 is appropriate.

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?

The description clearly states that the tool retrieves the full definition/configuration of an interview, including its ordered `questions` array. It also distinguishes the read operation from create/update sibling tools by explicitly tying the output into a round-trip workflow.

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?

It gives specific usage context: read the definition, modify the questions array, and send it to update_interview. It also clarifies that `position_id` can be either an interview-definition id or a position id. However, it does not explicitly state when to use list_interviews or another sibling for lighter-weight reads.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation4/5

Most tools target distinct resources and actions, with clear category prefixes like [Interviews], [Results], and [Admin]. A few pairs could be confused—create_interview vs. create_interview_from_questions and update_interview vs. set_interview_state—but the descriptions do enough to separate them.

Naming Consistency4/5

The overwhelming majority follow a consistent verb_noun pattern: create_*, get_*, list_*, update_*, generate_*. The main deviation is jobmojito_configuration, which is a noun phrase rather than an action verb, and a few longer names like request_another_interview_attempt break the clean pattern slightly.

Tool Count2/5

With 29 tools, this server is above the 25+ threshold and places a significant navigation burden on an agent. The tools are organized into coherent domains, but several admin/merchant and results tools could likely be consolidated.

Completeness3/5

The core interview lifecycle is well covered: create, read, update, list, state changes, result retrieval, and report generation. However, there are notable gaps such as no delete operations for interviews or catalogue directories, no candidate management beyond listing/registration, and no explicit result-decision tool.

Get interview definition

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources