Skip to main content
Glama

Create Resume from Career KB

create_base_resume_from_kb

Compose a new base resume from selected approved Career KB entities and a role label or category; only approved points are included, with no LLM involved.

Instructions

Compose a new base resume from selected Career KB entities. LLM-free.

entity_ids is REQUIRED. An empty list composes nothing and 422s — that is
deliberate; omitting the argument is not allowed because it would have to
mean "the whole KB". A role_label or role_category is required (no slug
argument). role_category is strict: an unknown value 422s naming the
closest categories, no normalization. An unmatched role_label maps to
role_category "other" and slug `other`/`other_2`…; display_name never
affects the slug, which is `base.slug` in the response. Only APPROVED
points under the selected entities compose —
points from kb_ingest_resume are DRAFTS and contribute nothing until
kb_approve_points (or the user, at /career) approves them.
skills and contact arrive in full from the KB profile regardless of entity
selection (the KB has no per-entity skill data), so skills may need trimming
on the resulting base. The
whole-career summary is dropped unless include_summary, or pass a reviewed
summary. A selected job or project with no approved point is left out, and
a 422 "None of the items you picked has approved bullets." means none has any.

Response is {base, next}. next is a hint (null when suppressed or when its
settings read fails; the base is created either way, and repeating the call
mints a second slug, <slug>_2).

Input Schema

NameRequiredDescriptionDefault
summaryNo
entity_idsYes
role_labelNo
display_nameNo
role_categoryNo
include_summaryNo

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?

Extensive disclosure beyond the annotations: which 422s fire and why (empty entity_ids, unknown role_category, no approved bullets), that unmatched role_label falls back to 'other'/slug other/other_2, that skills and contact always arrive in full from the KB profile and may need trimming, that the summary is dropped without include_summary, and that a job/project with no approved point is omitted. It also documents the {base, next} response and warns that repeating the call mints a second slug — consistent with idempotentHint=false.

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-loads the purpose and the hard requirement in the first three sentences, then spends the rest on failure modes and side effects that genuinely matter. It is dense and slightly run-on in the middle (the summary/skills paragraph), but no sentence is 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?

There is no output schema, yet the description explains the return value ({base, next}) and even the meaning of next being null. For a mutation tool with six parameters and no structured documentation, the definition supplies everything an agent needs to call it correctly and to interpret the result.

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 coverage is 0%, yet the description covers all six parameters: entity_ids (required, non-empty semantics), role_label/role_category (mutually sufficient, strict validation), display_name (never affects the slug), summary (pass a reviewed summary), and include_summary. This compensates fully for the empty schema and adds meaning no schema field could carry.

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?

"Compose a new base resume from selected Career KB entities. LLM-free." states a specific verb (compose), resource (base resume) and source (Career KB entities), which separates it from the sibling create_base_resume that doesn't draw on the KB. It never names that sibling explicitly, so the differentiation is implied rather than stated.

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 conditions for use: entity_ids must be non-empty because empty would have to mean 'the whole KB', and one of role_label/role_category is required since there is no slug argument. It explains the approval prerequisite (points from kb_ingest_resume are drafts until kb_approve_points). It lacks an explicit 'use create_base_resume instead when...' contrast, but the operational context is unusually complete.

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