Skip to main content
Glama

add_career_entry

Saves a new career journal entry to the user's GigHQ profile. Use this to document professional achievements, projects, skills acquired, or reflections tied to a specific role.

Entry types: 1 = achievement — a concrete win, result, or impact (default) 2 = project — a specific initiative the user owned or contributed to 3 = skill_acquired — a new skill, tool, or capability gained 4 = reflection — a lesson learned or professional observation

Tip: if the user hasn't specified a role, call list_experiences first, present the options, and ask which role this entry belongs to. Then pass the confirmed integer ID as experience_id. experience_id is optional — entries without one are valid but less useful for resume generation and interview prep, since they can't be linked to a specific role.

STAR structure (achievement entries): walk the user through their story in order, one piece at a time — don't interrogate with a checklist — Situation: the context or challenge beforehand Task: what specifically needed to be done or the goal to achieve Action: the concrete steps actually taken Result: the outcome, ideally with (1) scale of action: how much, how many, what scope (team size, users, codebase size, budget, requests/sec, etc.), (2) direct result: the measurable outcome (latency reduced by X%, errors down by Y, shipped Z weeks ahead of schedule), and (3) organizational impact: what that result meant for the business, team, or users (saved $X, unblocked N engineers, contributed to Y% revenue growth) Write description as a clearly labeled STAR narrative — "Situation: ... Task: ... Action: ... Result: ..." — rather than one unstructured paragraph. Before calling this tool for an achievement entry, confirm you have all four STAR parts from the user. If the Result's numbers are genuinely unavailable, note that in the description and ask the user to follow up later via update_career_entry. Project entries benefit from the same Result-quantification numbers but don't need the full STAR narrative structure. Put the quantified numbers from Result in the metrics field as well — not buried only in the description.

Input Schema

NameRequiredDescriptionDefault
tagsNoComma-separated skill or topic tags, e.g. 'TypeScript, system design, stakeholder management'.
typeNoEntry type: 1=achievement, 2=project, 3=skill_acquired, 4=reflection. Pass an integer or the label string. Defaults to 1.
titleYesShort headline summarising the entry (e.g. 'Led migration of payments service to microservices').
metricsNoThree-number quantification: (1) scale of action, (2) direct result, (3) organizational impact. E.g. 'Serving 50k daily users [scale] — reduced checkout latency from 2.1s to 0.4s [result] — increased conversion rate by 12%, adding ~$180k ARR [impact]'. For skill_acquired or reflection entries this can be omitted.
entry_dateNoISO 8601 date when this happened, e.g. '2024-03-15'. Defaults to today if omitted.
descriptionYesFull narrative in the user's own words. For achievement entries, write it as a labeled STAR narrative — "Situation: ... Task: ... Action: ... Result: ..." — not one unstructured paragraph. For other types, capture the what, why, and impact — not bullet points.
experience_idNoInteger ID of the GigHQ experience record (role) this entry belongs to. Use list_career_entries or the gighq://experience resource to find the ID.

Output Schema

NameRequiredDescriptionDefault
uuidNo
entryNo
messageYes
profileUrlYes
updatedFieldsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare a non-destructive, closed-world write, so the description focuses on the useful extra context: `experience_id` is optional but degrades downstream resume/interview utility, and `type` defaults to 1. It also gates the call on collecting all four STAR parts first. It does not discuss duplicate entries or validation failures, but the output schema covers the response shape.

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?

The purpose and routing tip are front-loaded and well-structured, but a substantial portion restates the schema verbatim — the four entry types, the three-number metrics definition, and the STAR format all already appear in the field descriptions. The STAR/Result guidance is also long enough that an agent may skim past the actionable routing tip.

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?

For a 7-parameter write tool in a multi-step career-journaling workflow, this covers everything the agent needs: entry-type taxonomy, the role-confirmation prerequisite, content-quality requirements per type, follow-up routing to update_career_entry, and reliance on the output schema for return values.

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 100%, so 3 is the baseline, but the description earns more: it explains why `experience_id` matters downstream rather than just what it is, and specifies that Result quantification should be mirrored into `metrics` rather than buried in `description`. The STAR-in-`description` requirement and the note that `metrics` is omittable for skill/reflection types add real semantic guidance.

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?

Opens with a specific verb and resource ('Saves a new career journal entry to the user's GigHQ profile') and immediately scopes the content domain (achievements, projects, skills, reflections tied to a role). That framing separates it cleanly from update_career_entry, list_career_entries, and the job-application note siblings without needing the 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?

Explicitly states when to use it, then adds a concrete prerequisite workflow: if no role is specified, call `list_experiences` first, present options, and confirm the ID. It also names `update_career_entry` as the follow-up path when Result numbers are unavailable, which is exactly the alternative-routing an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.