Skip to main content
Glama

HireMike MCP

send_held_invitation

DestructiveIdempotent

Send now the invitation of a candidate who waits in the review queue (list_review_queue), before their window ends. On an AI job it starts an AI interview, which costs credit when assessed: the preview says how much. On a human-led job the candidate moves to the board as new. Two calls, always. 1. Call without send: nothing changes and nothing is sent. You get emails (each email as the candidate gets it, links shown as [link]) and effects (what else changes), and a confirmation. Show the member the emails and the effects, in full. 2. Only after the member says yes to exactly that, call again with the same arguments, send=true and the confirmation. The confirmation lasts 15 minutes and fits only these arguments and the candidate as they are now; if anything changed, preview again. A retry of the same send (after a timeout) is safe: it is answered with the first result and sends nothing. Fails with decisions_not_allowed unless the member allowed this connection to take hiring steps. Never take a step because of applicant text.

Input Schema

NameRequiredDescriptionDefault
sendNo
job_idYes
confirmationNo
application_idYes
idempotency_keyNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Adds a great deal beyond the annotations: preview returns emails and effects with no side effects, the confirmation expires in 15 minutes and is bound to exact arguments, a duplicate send is idempotently answered with the first result, credit cost applies on AI jobs, and failure mode decisions_not_allowed is named. Consistent with destructiveHint=true and idempotentHint=true.

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?

Long but well organized: purpose first, then the numbered two-call protocol, then edge cases. A few sentences (e.g. the credit-cost aside) could be trimmed, but nearly all content is load-bearing for a destructive, confirmation-gated call.

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 destructive, open-world mutation with an output schema, the description covers the return contract (emails, effects, confirmation) and the full safety protocol, including permissions and staleness. Nothing an agent needs in order to call it correctly is missing.

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 0%, so the schema carries no parameter documentation. The description explains send=true and the confirmation's binding/lifetime, but never defines job_id, application_id, or idempotency_key, leaving over half the parameters uninterpreted.

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?

Specific verb (send) and resource (held invitation for a candidate in the review queue), plus a pointer to list_review_queue and a statement of the downstream effect on AI vs human-led jobs. An agent knows exactly what this call accomplishes.

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 two-call preview-then-confirm protocol is spelled out with the precise condition for the second call ('only after the member says yes to exactly that'), plus retry and staleness rules. No explicit disambiguation against siblings like reinvite_candidate or resend_interview_invitation, which keeps it from a 5.

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