Skip to main content
Glama
seinun-ai

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Save Gap Resolutions

resolve_gaps
DestructiveIdempotent

Save gap resolutions for a resume tailoring session: submit actions like add keyword, attach project, skip, or confirm missing evidence. Batch validated as one unit; merge by gap ID.

Instructions

Save gap resolutions on a tailoring session (merge by gap_id, idempotent). The batch is validated as ONE unit — one invalid item saves NOTHING (existing saved resolutions untouched).

`tailoring_session_id` is the id from create_tailoring_session. Each item
is {gap_id, action, payload}. Actions: add_keyword, user_input,
attach_project, skip, enable_entry, port_kb_point, cannot_confirm.
Payload shapes live on the `resolutions` parameter schema.

enable_entry and port_kb_point carry verified evidence and are exempt
from the add_keyword missing-skill rule (unverified additions stay in
skills). Re-sending a gap_id overwrites that gap; other saved resolutions
stay — including system-planned autos (payload.provenance; see
get_tailoring_session). May be called repeatedly; tailor_session consumes
the saved resolutions. Merge-only: omitting a gap_id never removes its saved resolution — resend
that gap_id with action "skip" to retract.

Response is the session plus a `next` hint (null when hints are off or unavailable).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resolutionsYesBatch of {gap_id, action, payload}. Actions: add_keyword | user_input | attach_project | skip | enable_entry | port_kb_point | cannot_confirm. Validated as ONE unit — one invalid item saves NOTHING (existing saved resolutions untouched). Merge-by-gap_id; omit never deletes — resend skip to retract. Payloads: add_keyword needs placement_target {section, index_or_category} (+ optional wording); a MISSING skill may use add_keyword ONLY with section=skills. user_input {text}. attach_project {project_name}. enable_entry {section: experience|projects, index}. port_kb_point {kb_point_id, kb_entity_id, placement_target, wording}. skip/cannot_confirm {} (cannot_confirm also stores a durable user_cannot_confirm KB record; only legal on gaps that ask a question, i.e. where user_input is allowed).
tailoring_session_idYes

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?

Goes well beyond the annotations (destructive=true, idempotent=true). It discloses the all-or-nothing batch validation ('one invalid item saves NOTHING'), the merge-only overwrite rule per gap_id, the exemption of enable_entry/port_kb_point from the add_keyword missing-skill rule, and that system-planned autos are preserved. Notably it reconciles the destructiveHint by clarifying that omission never deletes and retraction requires an explicit skip.

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?

Dense but well-organized, with the atomicity and merging rules front-loaded in the first three sentences before the finer action-level detail. A few clauses (payload provenance, evidence exemption) could be tightened, but nearly every sentence carries operational information the schema lacks.

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 still characterizes the response (session plus a 'next' hint, null when hints are off or unavailable). Given a two-parameter mutation tool with heavy schema detail and annotations present, the description supplies everything an agent needs to call it correctly.

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?

The resolutions parameter is heavily documented inside the schema itself, and the description defers payload shapes there rather than duplicating them. Its added value is real: it explains tailoring_session_id's origin, the cross-item interaction rules, and the evidence exemption that the schema does not state, compensating for the 50% coverage gap.

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 ('Save gap resolutions on a tailoring session') and immediately qualifies it with merge-by-gap_id and idempotent semantics. It is clearly distinct from its sibling tailor_session, which is named as the downstream consumer of what this tool saves.

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 states prerequisites (tailoring_session_id comes from create_tailoring_session), that it may be called repeatedly, that tailor_session consumes the results, and how to retract a resolution (resend the gap_id with action 'skip'). It also names get_tailoring_session as the place to inspect provenance, giving the agent a clear alternative for the read side.

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