Skip to main content
Glama
seinun-ai

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Import Parsed Resume

kb_ingest_resume
Idempotent

Persist a parsed resume into your Career KB as draft points, keeping them hidden until you approve them.

Instructions

Persist one caller-parsed resume into the Career KB. No in-house LLM.

Points land as DRAFTS and appear on no resume until approved with
kb_approve_points (or at /career), which records the user's approval.

HONESTY: `data` is stored as the user's own resume content, so a faithful
transcription is expected. The server does not detect embellishment,
rewording or invented metrics (same trust model as caller-authored tailor
ops); approved points become part of the career record.

ENTITY NAMES: matching is two-pass. Exact identity-key first (experience:
company+role+start_date; projects: name; education: institution+degree;
certs: the string), then a near-identity pass for experience/projects/certs
(token-subset; projects allow ≤2 extra tokens). Education and extra are
identity-key-only. Different spellings can merge on the second pass;
names outside its coverage still fork.

Re-running the same resume_key is a merge: no duplicate entities; a bullet
already on the entity (even retired) is not re-created. resume_key must
match ^[a-z0-9][a-z0-9_]*$.

`data` is ResumeData (only contact.name and contact.email required).
Sections: contact, summary, skills[{category, items}], experience, projects,
education, certifications[str], extra_sections. Experience:
{company, role, location?, start_date?, end_date?, bullets[str]}.
extra_sections are NOT stored in the KB (report warns); they can be added to
a base resume after it exists. skills/contact/summary go to the KB profile
(no draft state). Profile seeding is first-write-wins, so the first resume
ingested determines the profile.

Response {report, next}. report: created/matched entity ids, DRAFT point
ids, counts, warnings. next is a hint (null when suppressed/unavailable); brief=True
(multi-resume loops) suppresses it before any settings read. 422 on a
ResumeData validation failure or duplicate source key (atomic).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesResumeData. Only contact.name and contact.email are required. 422 if any source fails validation or on a duplicate SOURCE key (re-running the same resume_key is a merge, not an error); atomic either way: nothing persisted on a 422.
briefNo
resume_keyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.7/5.0
Behavior5/5

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

Goes far beyond the annotations: it discloses draft state, first-write-wins profile seeding, merge-not-duplicate behavior on identical resume_key (matching idempotentHint), atomic 422 semantics, two-pass entity-name matching that can merge differently-spelled names, and that extra_sections are not persisted. This is exactly the behavioral context an agent needs before a mutating call.

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-loaded purpose followed by labeled blocks (HONESTY, ENTITY NAMES) makes the density navigable, and each section adds decision-relevant information. The entity-name matching paragraph is long and borders on internal mechanics, which slightly blunts conciseness, but little is pure filler.

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 specifies the return shape {report, next}, what report contains, when next is null, and the 422 failure conditions. Between this, the nested ResumeData breakdown, and the annotation-delimited safety profile, nothing needed to invoke it correctly is missing.

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?

With only 33% schema coverage, the description carries the load: it gives the resume_key regex ^[a-z0-9][a-z0-9_]*$, spells out the ResumeData shape and section list, notes only contact.name/email are required, and defines brief=True as suppressing the next hint in multi-resume loops. This meaningfully exceeds the bare schema.

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 – 'Persist one caller-parsed resume into the Career KB' – and immediately disambiguates scope with 'No in-house LLM', signalling the caller owns parsing. Combined with the draft/approval lifecycle, an agent can tell this apart from kb_capture or kb_create_entity without opening a schema.

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?

Gives clear lifecycle context: points land as DRAFTS and must be approved via kb_approve_points (or /career), and describes the re-run merge case. It stops short of naming when to prefer this over sibling capture tools like kb_capture, so it is clear but lacks explicit exclusions.

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