Skip to main content
Glama
Sign In

JobMojito

by com.jobmojito
OverviewDiscussionsAdmin

Invite candidates to an interview or position

invite_candidates
Destructive

[Interviews] Invite candidates to an interview or position: e-mails each one their invitation.

The same invitation the admin console's Add candidates sends: creates or finds the candidate, uses the company's invitation budget, and queues the invitation e-mail (with the optional recruiter message). Each row comes back with its outcome; only 'Invited' means an e-mail was queued.

With send_email=false NOTHING is e-mailed: each candidate is registered and their personal interview_url comes back; nothing is sent. The result's email_sent says which happened. send_email=false sends nothing now or later: no invitation, no reminders, no SMS or WhatsApp, and it does not use the invitation budget.

A draft interview is not refused, but candidates can use their links only once it is active; activating it is a separate step (set_interview_state). is_test=true (with send_email=false) gives test links that also work on a draft, for trying the interview yourself; they are not for candidates, whose results would be marked as tests.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "interview_id": "<interview_id>",
      "candidates": "<candidates>"
    },
    "name": "invite_candidates"
  }
}

Input Schema

NameRequiredDescriptionDefault
is_testNoOnly with send_email=false: test links for trying the interview yourself; they also work on a draft. Not for real candidates: their results are marked as tests.
languageNoLanguage code for new candidates (e.g. 'en', 'sk'); defaults to English.
llm_modelNoYour model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
candidatesYesThe people to invite.
send_emailNotrue (default): e-mail each candidate their invitation. false: send NOTHING; register them and return each one's personal interview_url, shared outside this tool.
merchant_idNoOnly for an account acting for a sub-merchant; omit for your own company.
interview_idYesThe interview or position: its `id` from list_interviews, or the interview_def_set_id create_interview returned.
conversation_idNoThe conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.
message_from_recruiterNoOptional personal note shown above the invitation in the e-mail.

Output Schema

NameRequiredDescriptionDefault
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / is_test / description
      Previous value: -"Only with send_email=false: test links for trying the interview yourself; they also work on a draft. Never for real candidates, whose results would be marked as tests."New value: +"Only with send_email=false: test links for trying the interview yourself; they also work on a draft. Not for real candidates: their results are marked as tests."
    • changedInput schema / properties / send_email / description
      Previous value: -"true (default): e-mail each candidate their invitation. false: send NOTHING; register them and return each one's personal interview_url to share yourself."New value: +"true (default): e-mail each candidate their invitation. false: send NOTHING; register them and return each one's personal interview_url, shared outside this tool."
  2. Changed2 schema fields changed
    • changedInput schema / properties / interview_id / description
      Previous value: -"The interview (interview_def_set) or position (position_def_set) id, from list_interviews."New value: +"The interview or position: its `id` from list_interviews, or the interview_def_set_id create_interview returned."
    • changedInput schema / properties / is_test / description
      Previous value: -"Only with send_email=false: test links that may take a draft interview; results are marked as tests."New value: +"Only with send_email=false: test links for trying the interview yourself; they also work on a draft. Never for real candidates, whose results would be marked as tests."
  3. Changed1 schema field changed
    • addedInput schema / properties / llm_model
      Added value: +{
+  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
+  "type": "string"
+}
  4. Changed2 schema fields changed
    • addedInput schema / properties / is_test
      Added value: +{
+  "default": false,
+  "description": "Only with send_email=false: test links that may take a draft interview; results are marked as tests.",
+  "type": "boolean"
+}
    • addedInput schema / properties / send_email
      Added value: +{
+  "default": true,
+  "description": "true (default): e-mail each candidate their invitation. false: send NOTHING; register them and return each one's personal interview_url to share yourself.",
+  "type": "boolean"
+}
  5. Changed1 schema field changed
    • changedInput schema / properties / conversation_id / description
      Previous 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."New value: +"The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics."
  6. Added

TDQS

A4.6/5.0
Behavior5/5

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

Given annotations already flag destructiveHint=true and openWorldHint=true, the description still adds substantial behavior: it consumes the company's invitation budget, creates-or-finds the candidate, queues e-mail plus optional recruiter note, and returns a per-row outcome where only 'Invited' means queued. The send_email=false paragraph is unusually explicit about side effects (nothing now or later, no reminders, no SMS/WhatsApp, no budget use), which is exactly the disclosure a destructive, non-idempotent write tool needs.

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?

The critical constraint (nothing is sent when send_email=false) is stated early and the structure follows a sensible what/flag/draft/test progression. It is slightly repetitive, restating the no-send behavior across two paragraphs ('NOTHING is e-mailed ... nothing is sent' then 'sends nothing now or later'), which costs a little density but reinforces the most consequential flag.

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?

For a 9-parameter, non-idempotent, budget-consuming write tool with an output schema, the description covers invocation conditions, failure-adjacent edge cases (draft interviews), and result interpretation. Return values need not be described because an output schema exists, and nothing an agent needs before calling is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 would apply, but the description genuinely extends semantics: it explains the interaction between send_email=false and is_test (test links work on a draft using the same flag), states that a personal interview_url is returned instead of sending, and clarifies what the returned outcome values mean. Only merchant_id and llm_model/conversation_id are left entirely to the schema.

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 opening line gives a specific verb and resource ('Invite candidates to an interview or position: e-mails each one their invitation') and immediately anchors it to a known equivalent action (the admin console's Add candidates). An agent can tell exactly what the call does and what it produces (an e-mail queued per candidate) without opening the 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?

The description clearly delineates the two operational modes (send_email=true vs. false) and the narrow condition for is_test=true, and it warns that a draft interview is not refused and must be activated separately via set_interview_state. What it lacks is any explicit routing to an alternative invite mechanism in the sibling list; the guidance is contextual rather than comparative.

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

All JobMojito toolsInspect
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.

Resources