Skip to main content
Glama

Combine Career Points

kb_combine_points
Idempotent

Combine multiple Career KB bullet points into one keeper, retiring the others as alternate wordings while leaving existing resumes unchanged; the fold can be reversed later.

Instructions

Fold Career KB points into one: the keeper stays the bullet, and every point in point_ids (the others, not the keeper) is retired and recorded as one of the keeper's wordings. Resumes that use any of them keep their text; combining never edits a resume. Reversible from /career (Make its own bullet). The grouping written is the user's decision about the listed points; the server does not check that the user reviewed them (a convention, not enforcement, the same gate as kb_approve_points). Same entity required (400); a retired or user_cannot_confirm keeper, a user_cannot_confirm loser, and a loser the user stopped (retired but not folded) are refused (400), and so is a keeper that is itself folded into another; a loser already folded elsewhere moves to this keeper. Returns {keeper, repointed}: the keeper with its wordings, and any combined claims the fold moved from a loser onto it. 1-50 ids.

Input Schema

NameRequiredDescriptionDefault
keeper_idYes
point_idsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations it discloses the key side effect (losers retired and folded as wordings), that resumes are never edited, full reversibility, the convention-not-enforcement gate, the 400 refusal cases (cross-entity, retired/cannot-confirm keeper, user-stopped loser, already-folded keeper), the loser-moves-to-keeper rule, and the return shape. This is consistent with destructiveHint=false and idempotentHint=true.

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?

Purpose is front-loaded in sentence one, then behavior, reversibility, and error cases follow. The long error sentence packs several conditions together and is the densest part, but nothing is wasted.

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?

No output schema exists, yet the description documents the return value ({keeper, repointed}), reversibility, limits, and failure modes. For a 2-param destructive-adjacent merge tool, an agent has everything needed to call it correctly 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?

With 0% schema coverage the description carries the burden: it defines keeper_id as the surviving bullet and point_ids as 'the others, not the keeper', and adds the 1-50 constraint. It could go further on ID format, but it meaningfully compensates for the empty 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?

The first sentence gives a precise verb and resource: fold Career KB points into a keeper, retire the rest as wordings. It explicitly delineates the keeper vs. point_ids roles and sets it apart from kb_retire_points and kb_merge_entities by the 'same entity required' scope.

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?

It states the reversibility path ('/career → Make its own bullet') and frames the grouping as the user's decision with a convention gate matching kb_approve_points, giving clear context on when/how it applies. It stops short of naming a concrete alternative sibling for a different case (e.g. kb_merge_entities), so it's not a full when/when-not map.

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