Skip to main content
Glama
Sign In
Maestro Career Studio

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Score Resume Against Job

score_ats

Generates deterministic hybrid match scores to compare base resumes against job postings, verify edits, and rank candidates with recommendations.

Instructions

Deterministic hybrid match score (no LLM): deterministic lexical layers + anchored pinned-model semantic matching + section-level semantic_fit. Omit target to score ALL base resumes (fast).

target_type "base_resume" (target_id = slug) or "application" (target_id = id).
Same inputs always give the same score; use it to compare bases and to
verify an edit actually moved the number.

Response is {scores, recommendation, countries, next}. `scores` is the raw per-target
list: composite (0-100), per-layer subscores (incl. semantic_fit), gate
warnings, and a per-skill diagnostic table with fix_hints. `recommendation`
is a deterministic ranking of the base-resume rows (order, recommended slug,
margin, close_call, reasons, coverage_warning) — always present, cheap, and
useful during triage even with hints off. Bases set for other countries are
not scored for this job unless `include_other_countries` is true; the
`countries` block ({job_country, fallback, skipped}) names them and is
omitted when a target_id is given. `next` is an optional next-step
hint (null when suppressed or unavailable): in a set with the tailoring tools,
a gap analysis of the recommended base, filled from the saved presets or
walked by hand.

brief=True suits scoring many jobs in a triage/mass-capture loop: it
suppresses ONLY `next` (never `recommendation`) and is checked before any
settings lookup, so a twenty-posting triage loop pays no extra HTTP
round-trip for a hint nobody will read.

Input Schema

NameRequiredDescriptionDefault
briefNo
job_idYes
target_idNo
target_typeNo
include_other_countriesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.9/5.0
Behavior5/5

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

It discloses substantial behavior beyond annotations: deterministic/no-LLM computation, full response shape ({scores, recommendation, countries, next}), what each block contains, and the precise exclusion semantics of the countries block. It also explains brief's side-effect surface (suppresses only next, skips settings lookup).

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?

Purpose and the key decision (target vs all) are front-loaded, but the passage is verbose—e.g., the brief justification about HTTP round-trips and settings lookup is repeated in spirit. It earns most of its length given complexity, but some sentences could be tightened.

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 complex, 5-parameter tool with no output schema and no schema descriptions, the description fully compensates: it explains the return structure block-by-block and conditions each optional behavior. An agent has everything needed to call it and interpret the result.

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?

With 0% schema coverage, the description carries the full burden and does so: target_type's two enum values are mapped to their target_id forms (slug vs id), omitting target scores all bases, include_other_countries gates cross-country scoring, and brief's exact effect is defined. Every parameter gains meaning absent from the bare schema.

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 opening sentence names a specific verb+resource ('Deterministic hybrid match score') and enumerates the layers (lexical, semantic, semantic_fit), clearly distinguishing it from siblings like compare_ats. An agent immediately knows this produces a match score, not a comparison or edit.

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?

It states concrete use cases ('compare bases', 'verify an edit actually moved the number') and the omit-target-all-resumes behavior, plus when to set brief=True for triage loops. The alternative path (score-all vs single target) is spelled out explicitly.

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

Deploy Server

Other Tools