Skip to main content
Glama

Resume-to-Job Description Fit Score

score_resume_against_jd
Read-onlyIdempotent

Accepts one resume and one Job Description (no index required) and returns an overall match score, dimension scores, skill gap list, and natural-language explanation. Bias-controlled and audit-ready.

Input Schema

NameRequiredDescriptionDefault
index_keyNoSame as userkey — the RChilli API user key. Leave blank; the authenticated session userkey is injected automatically.
jd_contentNoComplete plain-text content of the job description. Do NOT base64-encode it; the server encodes it. Required.
match_typeNoDirection of the match — 'Resume to JD' (default) or 'JD to Resume'.Resume to JD
jd_file_nameNoOptional JD file name; always sent with a .txt extension because the content is plain text (default 'inline_jd.txt').
resume_contentNoComplete plain-text content of the resume/CV. Do NOT base64-encode it; the server encodes it. Required.
resume_file_nameNoOptional resume file name; always sent with a .txt extension because the content is plain text (default 'inline_resume.txt').

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / jd_content / description
      Previous value: -"Plain-text content of the job description. Converted to base64 internally."New value: +"Complete plain-text content of the job description. Do NOT base64-encode it; the server encodes it. Required."
    • changedInput schema / properties / jd_file_name / description
      Previous value: -"File name of the JD with extension (e.g. 'jd.docx')."New value: +"Optional JD file name; always sent with a .txt extension because the content is plain text (default 'inline_jd.txt')."
    • changedInput schema / properties / match_type / default
      Previous value: -""New value: +"Resume to JD"
    • changedInput schema / properties / match_type / description
      Previous value: -"Direction of the match — 'Resume to JD' or 'JD to Resume'."New value: +"Direction of the match — 'Resume to JD' (default) or 'JD to Resume'."
    • changedInput schema / properties / resume_content / description
      Previous value: -"Plain-text content of the resume/CV. Converted to base64 internally."New value: +"Complete plain-text content of the resume/CV. Do NOT base64-encode it; the server encodes it. Required."
    • changedInput schema / properties / resume_file_name / description
      Previous value: -"File name of the resume/CV with extension (e.g. 'resume.docx')."New value: +"Optional resume file name; always sent with a .txt extension because the content is plain text (default 'inline_resume.txt')."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile needs no restating; the description instead contributes the output contract and the 'bias-controlled and audit-ready' posture. Those qualifiers are useful but vague—no detail on how bias control is applied or what 'audit-ready' entails.

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?

A single front-loaded sentence with zero waste on process description. The trailing 'Bias-controlled and audit-ready' is mildly promotional rather than operational, which keeps it off a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly enumerates the return values an agent needs to decide to call it. It leaves open which dimensions are scored and how gaps are represented, a minor gap for a read-only scoring tool with fully documented parameters.

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 description coverage is 100%, so every parameter is already documented, and the baseline is 3. The description only reinforces the cardinality (one resume, one JD) and adds nothing about match_type direction or the filename parameters.

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?

States a specific verb and resource (scores one resume against one JD) plus the exact return payload (overall score, dimension scores, skill gaps, explanation). The phrase 'no index required' differentiates it from indexed siblings like find_matches_in_index and match_end_to_end.

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?

'Accepts one resume and one Job Description (no index required)' implicitly routes the agent away from index-based matching tools, and the return shape signals it is the single-pair scoring path. It does not explicitly name an alternative or state when not to use it, so it falls short of 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