Skip to main content
Glama
seinun-ai

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Approve or Retire Career Points

kb_approve_points
DestructiveIdempotent

Approve or retire Career KB points in bulk so they appear on composed resumes and career exports; submit 1-500 ids and get per-id results.

Instructions

Batch-set Career KB point state to approved or retired. Approved points are the only ones that appear on composed resumes and the career export; this is the single approval path available over MCP. The state written is the user's decision about the listed points; the server does not check that the user reviewed them (a convention, not enforcement, as with record_consent).

state is approved|retired only; bulk-to-draft is impossible. 1-500 ids;
repeats collapse to one result row. Per-id results are honest: unknown ids
return ok=false detail="not found" and the rest still proceed; a failed id
fails the same way until corrected (kb_list_points returns the current ids).

Response is {results: [{id, ok, state, detail}], next}. next is a hint
(null when suppressed or unavailable).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateNoapproved
point_idsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare the mutation profile (destructiveHint=true, idempotentHint=true), but the description adds real substance beyond them: approved points are the only ones surfaced on resumes/exports, the server does NOT verify user review ('a convention, not enforcement'), and unknown ids fail per-id while the rest proceed. Minor deduction for not stating auth/permission requirements for this write path.

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 and the key scoping constraint are front-loaded in the first sentence, and the response shape is last. It runs dense across several lines and includes a couple of low-yield asides (the record_consent analogy, the slightly tangled 'fails the same way until corrected' phrasing) that 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?

No output schema exists, so the description supplies the return contract ({results:[{id, ok, state, detail}], next}) including the semantics of next. Combined with the partial-failure behavior, an agent has everything needed to call it and interpret results in a batch context.

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 description coverage is 0%, so the description carries the load and does: it constrains state to approved|retired, bounds point_ids to 1-500, and discloses that duplicate ids collapse to one result row. These are non-obvious constraints not derivable from the schema alone.

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 (batch-set) plus resource (Career KB point state) and the exact value domain (approved or retired). It also self-identifies as 'the single approval path available over MCP', which distinguishes it from sibling mutators like kb_edit_point and kb_list_points.

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 frames when to reach for it ('the single approval path'), rules out a category of misuse (bulk-to-draft is impossible), and points to kb_list_points for obtaining valid ids. An agent knows both the trigger and the guard rails without opening a schema.

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