goldseam

Find Transitions

find_transitions

Read-only

Where can this occupation lead? For a SOC code: destination occupations, each with its typed roads (published by ONET or by a credential serving both; mapped through the CIP-SOC crosswalk), each road with its source, basis and its class's karat; the bridges (credentials with their exam, education and experience conditions, and programs with checklists nearest the state given); and demand as ONET publishes it. Roads only, no person data.

Input Schema

TableJSON Schema

Name	Required	Description
`from`	No	Or the job in everyday words, e.g. welder; several matching occupations answer candidates to pick from
`class`	No	Optional: only destinations with a road of this class (published, mapped)
`limit`	No	Optional page size (default 10, at most 25)
`state`	No	Optional two-letter state for the program bridges
`offset`	No	Optional: the next_offset from a previous answer
`prefer`	No	Optional preference such as less physical; answered not held when O*NET work context is not held
`from_soc`	No	The occupation's SOC code, e.g. 51-4121 (an O*NET .00 code is accepted)

Output Schema

TableJSON Schema

Name	Required	Description
`facets`	No
`results`	No	The destination cards
`contract`	Yes
`statement`	Yes
`understood`	No
`next_actions`	No
`total_matching`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 15, 2026
RemovedSep 15, 2026

Changed4 schema fields changedSep 12, 2026

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "from_soc"
+    ]
+  },
+  {
+    "required": [
+      "from"
+    ]
+  }
+]

addedInput schema / properties / class

Added value: +{
+  "description": "Optional: only destinations with a road of this class (published, mapped)",
+  "type": "string"
+}

addedInput schema / properties / from

Added value: +{
+  "description": "Or the job in everyday words, e.g. welder; several matching occupations answer candidates to pick from",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "from_soc"
-]
```

AddedSep 12, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: results contain only roads, no person data; sources are O*NET or credential mappings via CIP-SOC; bridges include credential conditions and programs; demand is as published by O*NET. This substantially clarifies the tool's data scope and privacy posture.

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 description is a single dense run-on sentence packed with specialized terms. It conveys a lot, but the nested structure and unexplained 'karat', 'CIP-SOC crosswalk', and 'nearest the state given' make it harder to parse than necessary.

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

Completeness4/5

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

Given the output schema exists and all parameters are documented, the description covers the main output categories and explicitly disclaims person data. It could be more complete by mentioning the 'from' everyday-words alternative and how unspecified filters behave, but those gaps are largely covered by the parameter schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all seven parameters. The description reinforces that from_soc is the primary input and mentions optional preferences indirectly, but adds no new semantic detail beyond the schema.

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?

The description clearly states this tool maps an occupation (by SOC code) to destination occupations and associated roads/bridges/demand. It goes beyond a tautology, but relies on unexplained domain jargon like 'typed roads' and 'karat', and does not explicitly distinguish itself from the closely named sibling find_pathways.

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

Usage Guidelines3/5

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

The opening question 'Where can this occupation lead?' implies when the tool is appropriate, and 'For a SOC code' gives a concrete input condition. However, it does not name alternatives or give exclusion criteria, so an agent must infer when to prefer this over siblings like find_pathways or compare_destinations.

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

All goldseam tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.