Skip to main content
Glama

Start Tailoring Session

create_tailoring_session
Destructive

Starts a resume tailoring workflow for a job and base resume. Scores the base resume, then returns prioritized gaps to resolve for tailoring.

Instructions

Start the gap-analysis tailoring workflow for a job + base resume.

Calling again for the same job+base SUPERSEDES the open session (saved
resolutions become unreachable); list_tailoring_sessions shows existing
sessions.

Scores the base (deterministic ATS engine, persisted as the 'before' score) and
returns a session whose gaps_json.categories list every gap in fix-cost order:
missing skills, wording mismatches, placement upgrades, stale evidence, adjacent
skills, title/structure. The intended flow is: gather the user's answer for each
gap, save them with resolve_gaps, then tailor_session. Each gap carries its
allowed actions. A missing skill MAY use add_keyword ONLY to add the keyword to
a skills category (placement_target.section="skills"): that inserts an
unverified skills-list item, never a fabricated bullet. The evidence-backed
alternatives are a user_input resolution (the user's answer to
enrichment.elicitation_question), attach_project, or skip.

enrich=False (default) skips the backend's fast-model enrichment pass — no
in-house LLM call — so gaps carry only their deterministic fields (no
enrichment.elicitation_question / suggested_wording / suggested_placement).
KB coverage detection does NOT depend on it: the deterministic self-nomination
and evidence-verification pass that used to sit downstream of the LLM call now
runs unconditionally, so KB autos still get stamped with enrich=False, and
even during a provider outage. enrich=True pays for one fast-model call
adding those display-only explanations and elicitation questions per gap —
it never changes scores or which gaps exist.

Response is the session plus a `next` next-step hint (null when hints are off
or unavailable). `base_anchors` are the base's emphasis hints (countries,
role, company, focus), not evidence; the anchor company is the resume's own
target, not necessarily this job's employer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
enrichNo
job_idYes
base_resumeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations flag destructive/non-idempotent, but the description explains WHY: re-calling makes saved resolutions unreachable. It further discloses that the base score is deterministic and persisted as the 'before' score, and precisely what enrich does and does not change (no score/gap-set change, no LLM call by default, KB autos stamped even during an outage).

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?

Front-loads purpose and the destructive supersede warning before the enrich detail. Sentences are dense and mostly earn their place, though the enrich/KB paragraph is verbose enough to risk burying the operational essentials.

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?

With no output schema, the description nonetheless describes the response shape (the session, gaps_json.categories ordering, the `next` hint, base_anchors) and the constraint that gap actions are limited (add_keyword only into a skills category, else user_input/attach_project/skip). Complete enough for an agent to invoke and interpret results.

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

Parameters4/5

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

Schema coverage is 0%, so the description must carry the burden. It fully explains the non-obvious `enrich` parameter (default, cost, effect on enrichment fields only), but job_id and base_resume are never described beyond their self-evident identifier roles. Strong compensation for the covered parameter, partial gap on the other two.

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+resource: 'Start the gap-analysis tailoring workflow for a job + base resume.' This clearly distinguishes it from read-only siblings like list_tailoring_sessions, get_tailoring_session, and close_tailoring_session, and from the downstream tailor_session.

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?

Explicitly warns that calling again for the same job+base SUPERSEDES the open session, and names list_tailoring_sessions as the way to inspect existing sessions. It also lays out the intended downstream flow (gather answers, resolve_gaps, then tailor_session), so the agent knows where this sits in the sequence.

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