Skip to main content
Glama
jnot807

recruitee-mcp

by jnot807

rt_create_candidate

Create a candidate and assign them to a role with a two-step preview-then-confirm process that checks for duplicates before saving.

Instructions

Create a candidate in Recruitee/Tellent AND place them on a role, in one call. Works entirely from what you are told here — nothing has to exist anywhere else first.

WHAT YOU NEED. Required: the role (its title is enough, e.g. "VP of Customer Success") and the person's full name. Strongly recommended, because a record without them is close to useless to a recruiter: email, and either a LinkedIn URL or a CV file. Optional: phone, tags, a coverLetter block for their background and why they are worth a look, and where they came from. If the user has not given you the recommended fields, ASK for them before creating — the preview call lists exactly what is missing.

TWO-CALL GATE, ALWAYS. The first call (confirm omitted or false) returns what would be created, what is missing, and any existing candidates with the same name — and writes nothing. Show that to the user. Only call again with confirm true once they have approved THIS person for THIS role. One person per confirmation.

THIS CREATES A REAL RECORD FOR A REAL PERSON, visible to the whole hiring team and counted in reporting. The preview always runs a duplicate check; if it finds a match, resolve that with the user rather than creating a second record that splits their history.

DO NOT INVENT DETAILS. An empty field beats a guessed one.

STAGE. Defaults to "Sourced", which is right for anyone we went looking for. Pass stage: "Applied" only for someone who genuinely applied. Recruitee's create endpoint has no stage parameter, so this moves them immediately after creation and tells you if that did not take.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asCvNoTreat the attached file as their CV rather than a plain attachment. Default true when attachFile is a CV.
nameYesFull name.
tagsNo
emailNoStrongly recommended — without it nobody can contact them from the ATS.
linksNoProfile URLs, e.g. their LinkedIn.
offerYesRole title or offer id, e.g. "VP of Customer Success" or 2683651.
phoneNo
stageNoStage name. Default "Sourced".
confirmNoFalse/absent = preview only.
sourcesNoWhere they came from, e.g. ["LinkedIn"].
attachFileNoAbsolute path to a local file to attach — a CV, or a summary document.
coverLetterNoFree text: their background, and why they are worth looking at.
Behavior5/5

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

With no annotations, the description carries full burden and does so effectively. It discloses that this creates a real, visible record affecting reporting, always runs a duplicate check in preview, moves the stage immediately after creation, and reports if that stage change fails. It also warns against inventing details, providing a clear safety profile for a mutation tool.

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

Conciseness5/5

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

The description is long but exceptionally well structured with clear headings (WHAT YOU NEED, TWO-CALL GATE, etc.) and front-loaded purpose. Every sentence provides actionable information—no filler or repetition. The length is justified by the tool's complexity and the absence of annotations or output schema.

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?

Given the 12 parameters, no annotations, and no output schema, the description covers all critical operational context: prerequisites, recommended fields, the preview/confirm workflow, duplicate handling, stage behavior, and fallback when the stage move fails. An agent has everything needed to invoke the tool correctly and avoid common pitfalls.

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

Parameters5/5

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

Schema coverage is high (83%), but the description adds substantial meaning beyond it: 'offer' can be title or ID, 'confirm' false/absent means preview only, 'stage' defaults to 'Sourced' with rationale, and it explains the interplay between attachFile/asCv and the recommended fields. This helps the agent map user intent to parameters accurately.

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 opens with a specific and complete statement: 'Create a candidate in Recruitee/Tellent AND place them on a role, in one call.' This clearly names the resource (candidate), the action (create + place on role), and the composite nature that distinguishes it from single-action siblings like rt_set_stage or rt_attach_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use and how-to-use guidance: required vs. recommended fields, asking for missing info before creating, the two-call gate (preview then confirm), when to pass stage 'Applied' vs. default 'Sourced', and handling duplicate candidates. It also explains the composite action's benefit over separate calls, though it doesn't name sibling tools directly.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jnot807/recruitee-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server