The CandidRanker MCP server: run hiring from Claude, ChatGPT or any MCP client

What MCP is, in one paragraph

Model Context Protocol is an open standard for giving an AI assistant controlled access to an external system's operations. Instead of pasting resumes into a chat window and hoping, the assistant calls named, permissioned actions against CandidRanker and gets structured results back. MinMaxHR treats it as a first-class interface, not a demo.

The 14 actions

• list_jobs: see the job descriptions available in the workspace.
• upload_job: add a job description.
• upload_resume: add a candidate resume.
• parse_status: check whether ingestion and parsing have completed.
• rank_candidates: run CandidRanker's deterministic ranking for a job.
• get_rankings: read the ranked candidate list with scores.
• explain_ranking: get the per-dimension reasoning behind one candidate's score.
• ranking_report: produce the recruiter-facing ranking report.
• list_candidates: see candidate summaries.
• get_candidate: read one candidate's detailed record.
• set_candidate_decision: shortlist, select, reject, or clear the current decision. A reason is required. There is no pending state.
• set_job_lifecycle: mark a role active or fulfilled.
• get_analytics: read the hiring funnel: decisions per week, time-to-decision, time-to-fill.
• list_tags: read classification tags.

What a recruiter can actually ask

• "Rank the candidates for the Senior Backend Engineer role and show me the top ten with reasons."
• "Why did this candidate score low on tools?"
• "Shortlist these four with the reason 'strong Kubernetes depth, mandatory coverage met'."
• "Which roles have the longest time-to-decision this month?"
• "Produce the ranking report for the Chennai QA role so I can send it to the hiring manager."

Each of those maps onto one or two CandidRanker MCP actions. The value is not novelty. It is that a recruiter already living in an assistant does not have to change surface to run the hiring loop, and the governance travels with them.

Security model

Connection is by OAuth: the user is sent to CandidRanker, logs in, picks one workspace and approves scopes. The issued token is bound to that single workspace and carries only the granted scopes. The tenant is inferred from the token and can never be passed as a parameter, which removes an entire class of cross-tenant mistakes.

Everything the app enforces, MCP enforces: workspace isolation with row-level security underneath, decisions attributable to a named human with a written reason, no auto-rejection, and full audit logging of actions taken through the agent surface.

API keys versus MCP

Both reach the same governed operations. Workspace-scoped API keys over the REST API suit internal tools and system integrations. MCP uses per-workspace OAuth consent and is built for AI assistants. Both are Enterprise capabilities and both inherit the same isolation, logging and security posture.

Where this fits your stack

MCP does not replace your ATS and does not replace CandidRanker's interface. It adds a third door into the same governed system for teams whose work already happens inside an assistant. If your recruiters do not work that way, the REST API or the app itself will serve you better, and MinMaxHR would rather you picked the right door than the newest one.