Skip to main content
Glama

Edit Tailored Resume

edit_application
Destructive

Apply typed edits on top of an existing application's tailored resume to refine or retry bullets and sections while preserving prior edits and avoiding duplicate applications.

Instructions

INCREMENTAL FIX: apply typed edit ops on top of an existing application's CURRENT tailored resume (customized_json), preserving every prior edit.

Falls back to the base resume only when the application has no customized_json
yet (nothing to preserve). Suited to refining or retrying a tailored resume
after inspecting PDF previews — swap a bullet, tweak wording, fix one thing —
without losing the rest of what's already been tailored and without creating
duplicate applications.
Accepts the FULL op vocabulary documented on edit_base_resume — every
kind. replace_entry changes an entry's dates, title, company, project name
or tech list; add/replace/remove/move_extra_section handle the custom
Publications/Awards/Volunteer sections.

Op field names (these exact keys, no synonyms):
{"kind": "replace_bullet", "section": "experience", "index": 0,
 "bullet_index": 2, "value": "New bullet text"} — `kind` (not op/type),
`index` (not entry_index; 0-based into the FULL array incl. disabled rows),
`value` (not text).
Index is 0-based into the full customized_json array (including enabled:false),
as shown by get_application, not PDF ordinals. Response `applied[].name`
echoes the entry each op touched.
Clears pdf_path/tex_path (the old PDF is stale); render_pdf produces a new one.

Input Schema

NameRequiredDescriptionDefault
opsYesTyped edit ops. Each is an object with a `kind`, one of: replace_summary | toggle_entry | replace_bullet | replace_skills_group | add_skill_item | add_bullet | add_entry | replace_entry | remove_entry | remove_bullet | replace_contact | replace_certifications | add_extra_section | replace_extra_section | remove_extra_section | move_extra_section. To change a field ON an entry — dates, title, company, project name, link, tech — use replace_entry with that entry's index and the full edited entry object; it is scoped to that one entry (a whole-resume replace is the separate update_base_resume tool). See the tool description for each op's shape. add_extra_section/replace_extra_section `value` is {key,title,enabled,type:"entries"|"bullets"} plus EITHER entries:[{heading,subheading?,location?,date?,link?,enabled,bullets:[str]}] OR bullets:[str] — never both; unknown keys are rejected (400, extra="forbid"). Text the ops write is implied first person: a line with I/he/she/they or the owner's name is a 400 naming the lines, and nothing is written.
application_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • changedInput schema / properties / ops / description
      Previous value: -"Typed edit ops. Each is an object with a `kind`, one of: replace_summary | toggle_entry | replace_bullet | replace_skills_group | add_skill_item | add_bullet | add_entry | replace_entry | remove_entry | remove_bullet | replace_contact | replace_certifications | add_extra_section | replace_extra_section | remove_extra_section | move_extra_section. To change a field ON an entry — dates, title, company, project name, link, tech — use replace_entry with that entry's index and the full edited entry object; it is scoped to that one entry (a whole-resume replace is the separate update_base_resume tool). See the tool description for each op's shape. add_extra_section/replace_extra_section `value` is {key,title,enabled,type:\"entries\"|\"bullets\"} plus EITHER entries:[{heading,subheading?,location?,date?,link?,enabled,bullets:[str]}] OR bullets:[str] — never both; unknown keys are rejected (400, extra=\"forbid\")."New value: +"Typed edit ops. Each is an object with a `kind`, one of: replace_summary | toggle_entry | replace_bullet | replace_skills_group | add_skill_item | add_bullet | add_entry | replace_entry | remove_entry | remove_bullet | replace_contact | replace_certifications | add_extra_section | replace_extra_section | remove_extra_section | move_extra_section. To change a field ON an entry — dates, title, company, project name, link, tech — use replace_entry with that entry's index and the full edited entry object; it is scoped to that one entry (a whole-resume replace is the separate update_base_resume tool). See the tool description for each op's shape. add_extra_section/replace_extra_section `value` is {key,title,enabled,type:\"entries\"|\"bullets\"} plus EITHER entries:[{heading,subheading?,location?,date?,link?,enabled,bullets:[str]}] OR bullets:[str] — never both; unknown keys are rejected (400, extra=\"forbid\"). Text the ops write is implied first person: a line with I/he/she/they or the owner's name is a 400 naming the lines, and nothing is written."
  2. First observedv0.11.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructive=true, readOnly=false, and idempotent=false. The description adds valuable behavior beyond that: it preserves prior edits, falls back only when customized_json is absent, clears stale pdf_path/tex_path, and says applied[].name echoes the touched entry.

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

Conciseness5/5

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

Front-loads the key framing with "INCREMENTAL FIX" and proceeds through fallback, usage, op vocabulary, exact field names, indexing, response, and file invalidation. It is dense but every sentence carries useful context for a complex 16-op tool.

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?

Covers the core behavior, fallback, response echo, and stale-file handling well for a destructive complex tool with no output schema. It is not fully self-contained because full op shapes must be read from the sibling edit_base_resume description.

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?

With 50% schema description coverage, the description meaningfully compensates by specifying exact op keys (`kind`, `index`, `value`) and 0-based indexing into the full array including disabled rows, not PDF ordinals. It still delegates full op shapes to edit_base_resume and does not describe application_id, though that parameter is obvious.

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: applying typed edit ops to an existing application's CURRENT tailored resume (customized_json), preserving prior edits. It distinguishes the resource from base-resume editing and from creating duplicate applications.

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?

Explicitly says it is suited to refining or retrying a tailored resume after inspecting PDF previews, and explains the base-resume fallback when no customized_json exists. It references edit_base_resume for the op vocabulary but does not fully state when to use that sibling instead or when not to use this tool.

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