Skip to main content
Glama

Save Work Experience

save_work_experience

Add or update a work experience entry (upsert). Omit id to create a new entry (title and startDate are required); pass an id (from get_profile) to update an existing one, changing only the fields you send. Every description should cover WHAT was built, HOW (technologies), IMPACT (users served, performance gains, revenue, uptime), and SCOPE (team size, scale). Push for measurable outcomes ("Built React frontend" -> "...serving 50K users, 40% faster"). Always populate technologies; they feed job matching. Check get_profile first to avoid duplicates, and don't fabricate. Ask the user to confirm vague dates or fill real gaps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoPresent: update this work-experience entry (only the fields you pass change). Omit: create a new one (title and startDate are required to create).
titleNoJob title
endDateNoEnd date: a date, e.g. "2024-01-15". Omit it for a current role
isRemoteNoWhether this job is remote (default false on create)
isCurrentNoWhether this is your current job (default false on create)
startDateNoStart date: a date, e.g. "2024-01-15"
companyUrlNoCompany website URL
companyNameNoCompany name
descriptionNoJob description
technologiesNoTechnologies used (e.g. ["React", "Node.js"]). They feed job matching

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / endDate / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 64,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / endDate / description
      Previous value: -"End date (ISO 8601), or null if current"New value: +"End date: a date, e.g. \"2024-01-15\". Omit it for a current role"
    • changedInput schema / properties / startDate / description
      Previous value: -"Start date (ISO 8601, e.g. \"2024-01-15\")"New value: +"Start date: a date, e.g. \"2024-01-15\""
    • addedInput schema / properties / startDate / maxLength
      Added value: +64
    • addedInput schema / properties / title / minLength
      Added value: +1
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=false, which is consistent with 'Add or update'. The description adds valuable behavioral context: it demands measurable outcomes in descriptions ('Built React frontend' -> '...serving 50K users'), instructs not to fabricate, and mandates always populating technologies for job matching. These are behavioral traits not captured in annotations.

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?

The description is about 200 words, which is a bit long, but every sentence earns its place. It front-loads the core operation and then adds essential usage rules and content guidelines. No fluff, though it could be tightened slightly by moving content-quality guidance into a separate section.

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 tool with 10 parameters, no output schema, and annotations that only cover read/write flags, this description is remarkably complete. It covers the upsert behavior, required fields for create, the duplicate-avoidance strategy (check get_profile), and content quality expectations. An agent has everything needed to call it correctly.

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 the baseline is 3. The description adds extra semantics for the id parameter (create vs update behavior) and for description (content requirements) and technologies (feed job matching). It does not add extra explanation for every parameter (e.g., isRemote, companyUrl), but the schema already explains those. The added value pushes it to a 4.

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 description opens with 'Add or update a work experience entry (upsert)', giving a clear verb and resource. It distinguishes itself from siblings like save_education and save_project by naming the specific resource (work experience) and the operation (upsert). No ambiguity.

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?

It explicitly states when to create (omit id) vs update (pass id from get_profile), and instructs to 'Check get_profile first to avoid duplicates'. It also tells the agent to ask the user to confirm vague dates, which is a clear usage rule. This goes beyond a basic description by giving actionable when-to-use guidance.

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.