One U Education

Get occupation basic facts

get_base_occupation

Read-onlyIdempotent

Basic occupation facts only: identity and ANZSCO version, names, tasks, skill level, lists, shortages and assessing authority references. Does not fetch assessment pathways, courses or other topics. This public endpoint returns English natural-language text, preserving sources, conditions and pagination.

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": "<occupation>"
    },
    "name": "get_base_occupation"
  }
}

Input Schema

Name	Required	Description	Default
`locale`	No	Language of names/descriptions in the result: zh-CN (default, Simplified Chinese plus English names), en-US, zh-TW. Also selects the language prefix of returned oneuedu.com URLs.	zh-CN
`occupation`	Yes	Internal occupationCode from search_occupations, or occupation URL/slug. anzsco is a shared classification code, not a unique identity. Exact internal code matches take precedence; search to select a candidate only if no exact match exists.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 12, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description earns credit for adding that this is a public endpoint returning English natural-language text with preserved sources, conditions and pagination. That return-shape and sourcing context goes beyond the structured hints.

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 tight sentences with no filler; the inclusion list and exclusion clause are front-loaded before the endpoint-behavior note. Dense but readable, and every clause carries information.

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?

With no output schema, the description partially compensates by describing the return format (English natural-language text, preserved sources/conditions/pagination), and annotations plus 100% schema coverage carry the rest. A little more on return structure or an explicit sibling routing would make it fully complete.

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 both the occupation and locale parameters are already well documented in the schema, including the exact-match precedence rule and enum semantics. The description adds nothing further about parameter behavior, so the baseline 3 is appropriate.

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 gives a specific resource ('occupation basic facts') and enumerates its contents (identity, ANZSCO version, names, tasks, skill level, lists, shortages, assessing authority references). It clearly distinguishes itself from content-bearing siblings like get_occupation_courses and get_course_pathways by stating what it does not cover, though it never explains how it differs from the plain get_occupation sibling.

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?

Usage is only implied through the exclusion clause 'Does not fetch assessment pathways, courses or other topics', which signals when-not-to-use without naming the alternative tools that should be used instead. No explicit routing (e.g. 'use get_course_pathways for...') is provided, so an agent must infer the boundary.

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

All One U Education 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.

Resources

Need Help?