Skip to main content
Glama
seinun-ai

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Add Career Points as Drafts

kb_add_points
Idempotent

Adds user-written bullet points to an existing career knowledge base entity as drafts, without model processing, so they stay off resumes and exports until approved.

Instructions

Add bullets the caller wrote to an existing Career KB entity as DRAFT points, with no LLM call (kb_capture with entity_id, minus the model that splits and places free text). Drafts appear on no resume and in no career export until approved with kb_approve_points (or at /career). The text is stored as the user's own words and facts; the server does not verify it.

Store-time rules: en and em dashes become a hyphen in a range
("2020-2023") and a comma elsewhere, and one opening a bullet is dropped.
Resume text is implied first person:
a bullet where I, he or she opens a clause, his/her/my opens one or follows
its verb ("Grew his team"), or the owner's name appears returns 400 naming
the lines and stores nothing; they/their and pronouns about other people
are stored. A bullet already on the entity in any state
(case and spacing ignored), or repeated in the call, is skipped, so a
repeated call adds nothing; a rephrasing is added as a new draft
(kb_groom_entity reports similar bullets).

Returns {entity_id, entity_title, point_ids, skipped}: the new DRAFT point
ids and the skipped texts. An unknown entity_id is a 404; kb_list_entities
returns the ids, and kb_create_entity makes a new entity.

Input Schema

NameRequiredDescriptionDefault
pointsYes1-50 bullets for the one entity, each at most 1000 characters.
entity_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.0

TDQS

A4.5/5.0
Behavior4/5

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

Goes well beyond the annotations: drafts are invisible to resumes/exports until approved, text is unverified, there are dash-normalization rules, a 400 for first-person phrasing with nothing stored, dedupe skipping, and a 404 for unknown entities. These are consistent with readOnlyHint=false, destructiveHint=false and idempotentHint=true (repeat calls add nothing), though idempotency could have been tied explicitly to that annotation.

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?

Front-loaded and information-dense with no filler, but the store-time rules paragraph is long and reads like spec text rather than selection guidance. It is defensible because these rules change what a caller should send, yet the definition could be tightened.

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 fully documents the return payload ({entity_id, entity_title, point_ids, skipped}) and the error modes. For a two-parameter draft-creation tool, an agent has everything needed to call it and interpret the result.

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?

Schema coverage is only 50% and entity_id has no schema description, but the text compensates by explaining that entity_id must be an existing entity (404 otherwise) and where to get ids. For points it adds content-level validation rules (dash handling, first-person rejection, dedupe) beyond the schema's 1-50/1000-char limits.

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 (add bullets to an existing Career KB entity as DRAFT points) plus the key mechanism (stored as-is, no LLM splitting). It explicitly distinguishes itself from kb_capture by noting the missing model step, so an agent can tell the two apart without opening either schema.

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?

Names the alternatives and the conditions that select them: kb_capture when free text needs splitting, kb_approve_points (or /career) to move drafts out of draft state, kb_list_entities to resolve ids, kb_create_entity for a new entity, kb_groom_entity for near-duplicates. Usage is fully routed rather than inferred.

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