Skip to main content
Glama

Send a reference check

send_reference_check
Destructive

Sends a reference check for one candidate. HiveRef emails the candidate a secure link to add their referees, then contacts the referees; the check counts towards the organisation's plan. Sending emails a real person and can't be undone from here. The questions come from custom_questions (up to 40) or a question_template_id; with neither, HiveRef's general template is used. Custom questions go through HiveRef's compliance check, which can reject a question and give the reason. A repeat call for the same candidate and role within 24 hours sends nothing unless send_again is true, so a retry does not email the candidate twice.

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": {
      "candidate_first_name": "<candidate_first_name>",
      "candidate_last_name": "<candidate_last_name>",
      "candidate_email": "<candidate_email>",
      "role_title": "<role_title>",
      "user_confirmed": "<user_confirmed>"
    },
    "name": "send_reference_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
role_titleYesThe role the candidate is being hired for.
send_againNoTrue sends a second check to a candidate who was already sent one for this role in the last 24 hours. Default false.
user_confirmedYesMust be true. Records that the user reviewed the candidate, email, role, referee count and questions and asked for this check to be sent.
candidate_emailYesThe candidate's email address.
job_descriptionNoThe job description, if the user gave one. Helps the compliance check judge custom questions.
target_refereesNoHow many referees the candidate is asked for, 1 to 6. Default 2.
custom_questionsNoThe questions to ask referees. Leave out to use a template.
candidate_last_nameYesThe candidate's last name.
candidate_first_nameYesThe candidate's first name.
question_template_idNoThe id of a HiveRef question template. Leave out when sending custom_questions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With annotations already flagging destructive/openWorld/non-idempotent, the description goes further by disclosing the external side effect (HiveRef emails the candidate and then the referees), the billing impact, the compliance check that can reject a custom question and return a reason, and the fact that a retry silently sends nothing rather than duplicating the email. These are exactly the failure modes an agent needs before calling.

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?

Five dense sentences, front-loaded with the core action and the irreversibility warning before the question-resolution details. Slight redundancy in the opening restatement of the title, and the phrasing 'Sending emails a real person' is awkward, but almost every sentence carries decision-relevant information.

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 10-parameter mutation with no output schema and 100% schema coverage, the description closes the remaining gaps: external effects, quota cost, idempotency window, and the compliance-rejection path that an agent may need to report back. Nothing needed to call it correctly or explain the outcome appears 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?

Annotations declare destructive and non-idempotent, so the description earns credit for adding what the annotations cannot: real emails go to a person, the action is irreversible from here, the check consumes plan quota, the 24h dedupe behaviour, and the question-source precedence (custom_questions up to 40, else question_template_id, else general template). That precedence logic is genuinely relational and not derivable from the individual parameter descriptions.

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 first sentence names a specific verb and resource (sends a reference check) scoped to 'one candidate', which separates it cleanly from the read-oriented siblings (get_check, list_recent_checks, list_completed_checks). An agent can tell this is the initiating write action 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 establishes context well: use it to start a check for a candidate, and it explains the 24-hour repeat-call condition with the send_again escape hatch. It does not explicitly name alternatives such as suggest_reference_questions or list_question_templates for obtaining questions, so routing is implied rather than spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources