Skip to main content
Glama
Sign In

OffLadder

by com.offladder
OverviewDiscussionsAdmin

Get the full write-up of a career direction

get_career_direction
Read-onlyIdempotent

Returns everything OffLadder holds on one emerging direction of work: what the days contain, why it is appearing now, what AI changes about it, the human abilities it leans on, the experience it grows out of, one small test and what is still unknown. Without a name, lists all 24 directions by family with one line each. Fits questions about what a newer kind of job involves, or requests for a list of emerging careers, e.g. 'what does a robot fleet supervisor do', 'what is an AI workflow designer', 'jobs in energy retrofit', 'list emerging careers', 'what new jobs exist in climate and energy', 'careers in AI that aren't engineering'.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_career_direction"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoThe direction's name or a close description, e.g. 'digital accessibility engineer'. Leave out to list them all.

Output Schema

NameRequiredDescriptionDefault
familiesNoEvery direction by family, when no name was given.
directionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely useful behavior beyond that: the section structure of the returned write-up and the fact that omitting the name switches to a grouped 24-item list. It does not discuss matching fallbacks or what happens when a name is not recognized.

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 two modes are front-loaded and the content enumeration is dense but purposeful. The trailing list of six example queries is longer than needed and repeats the same idea, adding bulk without new 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 an output schema present and a single well-documented optional parameter, the description covers both invocation modes and the expected question types. The remaining gap is routing versus similarly named siblings, which the description never addresses.

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, but the description earns credit by explaining the consequence of omitting the optional parameter (all 24 directions listed by family with one line each), which the schema only states tersely as 'Leave out to list them all.'

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 names a specific verb and resource and enumerates exactly what the write-up contains (day-to-day work, why it is emerging, AI impact, human abilities, prior experience, a small test, open questions), plus the fallback list mode. It does not differentiate itself from the confusingly similar sibling 'explore_career_directions' or 'read_career_guide', which keeps it off a 5.

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

Usage Guidelines4/5

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

It states the question shapes the tool fits and backs that with six concrete example queries, and it explains the no-name list behavior. It stops short of naming an alternative tool or stating when to prefer a sibling, so the when-not guidance is absent.

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

All OffLadder toolsInspect
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