Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@resume-scorer-mcp Score my resume against the rubric"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that scores a structured resume against a deterministic 4-category engineering rubric. Numeric score, evidence per category, bonus points, deductions, concrete improvement areas — all without an LLM call.
Four categories tuned for modern engineering profiles:
Category | Max |
Open Source contributions | 35 |
Self Projects | 30 |
Production Experience | 25 |
Technical Skills | 10 |
Bonus (portfolio, LinkedIn, etc.) | +20 |
Deductions (missing links, tutorial projects) | up to −15 |
Total | 100 (+20 bonus) |
Related MCP server: decroche-mcp
Candidates — self-check before applying. Iterate until score crosses your target.
Recruiters — bulk-screen JSON Resumes without sending content to a paid LLM.
AI agents — a deterministic scoring primitive for agent workflows.
Privacy — no resume content leaves your machine.
npm install -g resume-scorer-mcpOr run directly via npx:
npx resume-scorer-mcpAdd to claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"resume-scorer": {
"command": "npx",
"args": ["-y", "resume-scorer-mcp"]
}
}
}Restart Claude Desktop. Ask:
"Score this resume against the rubric" + paste a JSON Resume
score_resumeScore a structured resume in JSON Resume format.
{
"resume_json": {
"basics": {
"name": "Your Name",
"url": "https://yoursite.dev",
"profiles": [
{ "network": "GitHub", "url": "https://github.com/you" },
{ "network": "LinkedIn", "url": "https://linkedin.com/in/you" }
]
},
"work": [
{ "name": "Company", "startDate": "2025-03", "endDate": "2026-04",
"highlights": ["Built X with Y …"] }
],
"projects": [
{ "name": "Project", "url": "https://project.dev",
"description": "Real-time LLM thing using OpenAI/Claude…",
"technologies": ["Next.js", "Firebase", "OpenAI"] }
],
"skills": [{ "name": "Languages", "keywords": ["Python", "TypeScript", "React"] }]
}
}Also accepts resume_json_path (absolute path) instead of inline data.
score_resume_from_freeformBest-effort scoring of plain text. Less accurate. Use score_resume when possible.
{
"scores": {
"open_source": { "score": 6, "max": 35, "evidence": "GitHub URL present but no external contributions detected …" },
"self_projects": { "score": 22, "max": 30, "evidence": "Per-project breakdown: Project: 3 complexity signals, link present -> 8/10 …" },
"production": { "score": 19, "max": 25, "evidence": "~3.1 years total production tenure across 3 role(s) (LLM production weighting +2)." },
"technical_skills":{ "score": 9, "max": 10, "evidence": "18 distinct technologies/keywords detected." }
},
"bonus_points": { "total": 3, "breakdown": "+2 portfolio URL - +1 LinkedIn profile" },
"deductions": { "total": 2, "reasons": "-2 for 1 project(s) without links: …" },
"key_strengths": [
"Solid production tenure with multi-year track record.",
"Personal projects show technical depth and shipped artefacts.",
"Broad polyglot stack signal."
],
"areas_for_improvement": [
"Land 2-3 merged pull requests to popular open-source repos to break out of the <=10 self-only cap.",
"Add live demo or repo URL to every project to remove missing-link deductions."
],
"total": 59,
"max_total": 100
}git clone https://github.com/KhushalB25/resume-scorer-mcp.git
cd resume-scorer-mcp
npm install
npm run build
npm startTest with @modelcontextprotocol/inspector:
npx @modelcontextprotocol/inspector node dist/index.jsThe scoring rubric is the author's own design. Bands are tuned for early-career to mid-career software engineers. Categories and weightings can be customised by forking src/index.ts — pure functions, no external scoring service.
MIT
Score a structured resume (JSON Resume format) against the HackerRank hiring-agent rubric. Returns category scores (open_source 0-35, self_projects 0-30, production 0-25, technical_skills 0-10), bonus points, deductions, strengths, and improvement areas.
| Name | Required | Description | Default |
|---|---|---|---|
| resume_json | No | Structured resume in JSON Resume format. Required keys: basics, work, projects, skills. See https://jsonresume.org/schema/ | |
| resume_json_path | No | Alternative to resume_json. Absolute path to a .json file on disk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It accurately describes the tool as returning scores and analysis, implying read-only behavior. It does not mention any side effects or prerequisites, but the nature is evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences contain all essential information: purpose, input format, and return values. No redundant or missing content. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool nature, the description is complete. It details input requirements, scoring categories, and output components. No output schema exists, but the description sufficiently covers what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by specifying required keys (basics, work, projects, skills) and providing the JSON Resume schema URL, clarifying the input format beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scores a structured resume in JSON Resume format against a specific rubric. It lists the exact categories returned, distinguishing it from the sibling tool for freeform resumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for structured JSON resumes, and the sibling name suggests an alternative for freeform. However, it does not explicitly state when to use this tool versus the sibling or provide when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a resume passed as free-form text. The server makes best-effort regex extraction of email, GitHub, project names, and tech keywords. Less accurate than score_resume with structured input.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Full resume text (plain text, no formatting). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool uses 'best-effort regex extraction' and acknowledges lower accuracy. However, it does not mention potential failure modes, output format, or what happens when extraction fails, which would improve transparency. Still, the stated limitations are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place: the first states the core purpose, the second adds a critical limitation and comparison. It is front-loaded and concise with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, no annotations), the description covers purpose, usage guidelines, and behavioral transparency adequately. However, it omits details about the output (e.g., score range or format), which would enhance completeness. Still, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with a description). The tool description does not add meaning beyond the schema's parameter description; it merely restates 'Full resume text (plain text, no formatting.)' as present in the schema. Thus, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Score a resume' and specifies the resource as 'free-form text'. It distinguishes from the sibling tool by noting it is less accurate and for free-form input versus structured input, satisfying the requirement for specific verb and resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises that this tool is less accurate than score_resume, which implies it should be used when only free-form text is available, and the sibling is preferred for structured input. This provides clear when-to-use and when-not-to-use guidance with an alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0score_resumescore_resume_from_freeformScored across 2 tools
Both tools have clearly distinct purposes: one expects structured JSON Resume input, the other accepts free-form text. Descriptions explicitly state the difference and accuracy trade-off, leaving no ambiguity.
Both tools follow the same `score_resume` prefix, with the second having a descriptive suffix `_from_freeform`. The pattern is consistent and predictable.
Two tools is minimal but appropriate for this narrow domain—scoring resumes in two input formats. Could potentially add a third for batch processing, but current count is reasonable.
The set covers the two likely input types (structured and freeform). No obvious gaps like scoring from a file path or returning additional output formats, but the core functionality is complete.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Pay-per-call AI evaluation MCP server. Score LLM outputs against benchmark rubrics via Workers AI.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
