Skip to main content
Glama

Tailor Resume Session

tailor_session
Destructive

Run the tailoring pipeline for a saved session: apply resolutions or caller-supplied edit ops to produce one tailored application and auto-score it.

Instructions

Run the tailor pipeline for a session: resolutions -> edit ops -> tailored application, auto-scored.

`tailoring_session_id` is the id returned by create_tailoring_session.
Two ways to produce the edit ops:
- Default (ops omitted): the backend builds the tailor prompt from the saved
  resolutions and calls the LLM to generate the ops.
- Caller-supplied (ops given): the caller has already produced the typed edit
  ops (same op shapes as tailor_application/edit_application). The backend
  skips its own LLM pass and applies them directly — the caller's judgment
  IS the tailor. `ops` carry only the changed fields (the base is in
  get_base_resume).

Caller-supplied ops are applied as authored: the server validates structure
only, so nothing gates fabricated skills, experience, metrics, or dates
(keyword-survival checks run only on the backend-LLM path). A skill the
candidate cannot evidence goes only in the skills list (add_skill_item), not
in a bullet; the compare view audits any edit beyond the saved resolutions.

Resume text must be implied first person: no I/he/she/they or the owner's name; a hit returns 400 naming the lines.

Optional user_prompt adds free-form tailoring guidance. Writes the job's ONE
application from the base plus the ops: it rebuilds the draft and removes its
PDF (version history keeps the old draft), scores it, and returns
{session, compare, compare_error, next}. compare (before/after match score
deltas) may be null with compare_error set: the tailor still succeeded, so do
not retry. `kb_writeback_skips` derives from each user_input
resolution's STORED placement_target from resolve_gaps, not from the ops, so
ops that disagree with the stored target produce a spurious wrong_section
skip. `next` is a next-step hint naming render_pdf for that application
(null when suppressed or unavailable).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opsNo
user_promptNo
tailoring_session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.5/5.0
Behavior5/5

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

Far beyond the annotations (which only say destructive/not-read-only/not-idempotent), it discloses that it rebuilds the draft and removes its PDF (version history retained), that caller-supplied ops are applied as authored with structure-only validation and no gating of fabricated content, the implied-first-person rule with a 400 naming offending lines, and the kb_writeback_skips/stored-placement_target caveat.

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?

It is long but front-loaded, opening with the pipeline before flowing into input modes, constraints, and return shape. Nearly every sentence adds operational value; a few (e.g. the repeated op-shape cross-references) could be tightened, keeping it just short of maximal efficiency.

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 fully specifies the return payload {session, compare, compare_error, next}, explains when compare is null and that a compare_error is not a failure, and clarifies that next is a render_pdf hint (null when suppressed). Mutation effects and the first-person validation constraint are also covered, leaving nothing essential unstated.

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?

Schema description coverage is 0%, so the description carries the full burden and does: tailoring_session_id is the id from create_tailoring_session, ops has two modes with shapes tied to tailor_application/edit_application and carries only changed fields (base is in get_base_resume), and user_prompt is free-form tailoring guidance. All three parameters are meaningfully documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource and states the full pipeline: 'Run the tailor pipeline for a session: resolutions -> edit ops -> tailored application, auto-scored.' It distinguishes itself from create_tailoring_session, resolve_gaps, and render_pdf, but never contrasts itself with the most confusable siblings (tailor_application, quick_tailor), so the agent must infer when this session-based path beats the direct one.

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?

It gives clear context for the two invocation modes: default (ops omitted) uses the backend LLM, caller-supplied ops skip the LLM pass. It also supplies operational guidance like 'the tailor still succeeded, so do not retry' on compare_error. What's missing is any statement of when to choose this tool over tailor_application or quick_tailor.

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