Skip to main content
Glama

Quick Tailor

quick_tailor
Destructive

Starts a resume tailoring session for a job, using a saved profile to fill gaps automatically instead of one-by-one prompts.

Instructions

Start Quick Tailor over MCP: the fast path that fills gaps from the user's saved quick-tailor profile instead of walking them one by one.

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

Composes create_tailoring_session(enrich=False) with the profile fill
(deterministic; resolve_gaps' honesty-gated save path).

This tool makes NO in-house LLM call: sessions rely on the calling agent's
own model. The saved profile only plans
mechanical, evidence-respecting moves — it does NOT write resume prose.
The returned resolutions_json may already resolve every gap, including
system-planned entries (payload.provenance). Resume text comes from
caller-authored typed edit ops passed to
tailor_session(tailoring_session_id=..., ops=[...]), which skips the backend
LLM pass.

Honesty: the server does not gate caller-authored ops against fabricated
skills, experience, metrics, or dates. An unverified or absent skill can only
enter a skills category (add_skill_item), never as an experience or project
bullet asserting the candidate did the work.

The tailor_session that follows writes the job's ONE application: it
rebuilds the draft and removes its PDF (version history keeps the old
draft).

A session whose resolutions_json contains no planned action beyond
"skip" means the profile was not ALLOWED to add anything to THIS
session — it is not an error; the gaps can then be resolved with
resolve_gaps.

Raises (409, message says which): a failing fatal health gate on the
base blocks session creation; a stale or no-longer-open session blocks
the profile fill. Response is the filled session plus a `next` hint
suggesting tailor_session (profile standing instruction as user_prompt
when the session has no note of its own).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes
base_resumeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations declare destructive/non-idempotent, and the description adds substantial behavior beyond that: re-calling supersedes the open session and makes saved resolutions unreachable, no in-house LLM call is made, the honesty gate on caller-authored ops, the 409 failure conditions (fatal health gate, stale/closed session), and the PDF removal done by the follow-up tailor_session. This is exactly the extra context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The key routing constraint (supersedes the open session) is front-loaded, which is good, but the description sprawls across six dense paragraphs with heavy dash-clause nesting and some restatement (resolve_gaps' save path, then resolve_gaps again at the end). Several sentences could be tightened considerably.

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 multi-step, stateful tool with no output schema, the description covers the mechanical composition, the LLM/honesty boundaries, the failure modes with status codes, and what the response contains (filled session plus a next hint). An agent has what it needs to call and follow up correctly.

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 coverage is 0% for job_id and base_resume, so the description carries the burden. It references 'the same job+base' when describing supersede behavior, implying these identify the job and base resume, but never states their expected format (ID vs. name) or relationship. This is partial compensation for the coverage gap.

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 states that it starts a Quick Tailor session over MCP and fills gaps from the saved profile, and it explicitly distinguishes this fast path from create_tailoring_session (which it composes with enrich=False) and resolve_gaps. The verb is somewhat implicit ('Start... over MCP') but the resource and scope are clear enough to separate it from siblings.

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 gives explicit when-to-use context (fast path instead of walking gaps one by one), names alternatives for adjacent needs (list_tailoring_sessions to see sessions, resolve_gaps for unresolved gaps, tailor_session to write the resume), and states the supersede condition on re-invocation. Nothing about routing is left to inference.

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