OffLadder

Explore unusual career directions

explore_career_directions

Read-onlyIdempotent

Suggests kinds of work that might suit someone, for questions about what to do with their life or which careers fit their interests, strengths, values or past experience, e.g. 'what jobs suit someone who likes fixing things', 'careers for people who love the outdoors', 'what else can I do with my teaching experience', 'jobs for creative people that pay', 'careers that aren't just coding', 'new jobs AI is creating', 'jobs that help with climate change', 'meaningful work in health care without being a doctor', 'I'm good with people and spreadsheets, what fits'. Returns two or three emerging directions of work from OffLadder's library of 24, each with what the days contain and one small way to test it, plus a link to carry on with OffLadder's coach.

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": {
      "interests": "<interests>"
    },
    "name": "explore_career_directions"
  }
}

Input Schema

Name	Required	Description	Default
`count`	No	How many directions to return (default 3).
`interests`	Yes	What they enjoy, are good at or are curious about, in their words.

Output Schema

Name	Required	Description
`cta_label`	Yes	A short label for that link.
`start_url`	Yes	OffLadder's short onboarding, with a starting world picked if one was clear.
`browse_url`	Yes	All of OffLadder's directions.
`directions`	Yes
`continue_url`	Yes	The same link, as the suggested next step.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine value beyond that: it discloses the size of the underlying library (24 directions), the result cardinality (two or three), the shape of each result (what the days contain, one small way to test it), and that a link to OffLadder's coach is appended. No auth, latency, or pricing context, but none is needed for a read-only suggestion call.

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 purpose and return behavior are front-loaded and the examples do help routing, but nine near-duplicate example queries in a single unstructured paragraph bloat the definition well past what is needed; five or six would carry the same signal. The final sentence on returns is dense but informative.

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?

An output schema exists, so the description need not explain return values, yet it briefly previews the result shape anyway. With 100% schema coverage, four annotations, and only two parameters, the definition gives an agent everything needed to call it correctly and interpret the response.

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 coverage is 100%, with both 'interests' and 'count' fully documented (including default 3 and the 1-3 maximum), so the schema does the heavy lifting. The description adds only a hint of parameterization via 'two or three directions', which loosely reflects the count parameter, and its examples imply that free-text phrasing is acceptable input. 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?

States a specific verb and resource ('Suggests kinds of work') and adds scope detail: two or three emerging directions drawn from a library of 24, each with what the days contain plus a way to test it. That distinguishes it from reference-style siblings like read_career_guide or check_career_change_facts, though it never names an alternative explicitly.

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?

The long list of example user questions ('what jobs suit someone who likes fixing things', 'careers that aren't just coding', 'I'm good with people and spreadsheets') effectively defines the trigger conditions for an open-ended exploration request. It stops short of stating when NOT to use it or which sibling to pick instead, so an agent facing a lookup-style question has to 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 OffLadder 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.