Skip to main content
Glama

Get Career Next Steps

get_career_next_steps
Read-onlyIdempotent

Find potential next occupations from the Career Pathways model for a given occupation ID, and discover available categories in its metadata.

Instructions

Find potential next occupations from the Career Pathways model. Discover available categories in metadata.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "occupation_id": "<occupation_id>"
    },
    "name": "get_career_next_steps"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
nationNous
dimensionNolotspecocc
categoriesNo
lot_versionNo7
occupation_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. Beyond that the description adds very little: it does not say what the pathways model returns, whether results are ranked, how the dimension/lot_version choices affect results, or how limit interacts with relevance ordering. The vague "metadata" sentence hints at a discovery behavior without explaining it.

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?

Two short sentences with the core purpose front-loaded and no filler. The second sentence is the only questionable element, since it sits at the same level as the main purpose and reads as an unrelated afterthought.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be spelled out, but for a 6-parameter tool with zero schema descriptions and two enum-typed parameters (dimension, lot_version) the description leaves an agent unable to choose parameter values sensibly. Neither the required occupation_id nor the limit range/default is contextualized.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 6 parameters, so the description must compensate and largely fails. Only "categories" is alluded to (via the metadata sentence), and there is nothing about the meaning of dimension, lot_version, nation, limit, or what occupation_id should refer to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Find potential next occupations from the Career Pathways model" states a specific verb (find) and resource (next occupations) and names the underlying model, which is enough to distinguish it from skill-gap or metadata siblings. The second sentence, "Discover available categories in metadata," muddies the purpose by describing a metadata-discovery capability that overlaps with the *_metadata siblings without indicating whether it is a separate mode or a side effect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use guidance, no prerequisites (does an occupation_id need to exist / be normalized first?), and no exclusions versus siblings like get_career_skill_gap or get_pathways_metadata. An agent must infer the usage context entirely.

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