OffLadder

Find a small experiment to test a career

find_career_experiment

Read-onlyIdempotent

Finds a small way to try, test or get a feel for a career, job, trade or field before committing to it, for someone weighing whether to quit, retrain or switch into it, e.g. 'how do I know if I'd like UX design', 'try nursing before going back to school', 'test a career change this weekend', 'is product management right for me', 'a cheap way to see if I'd enjoy teaching', 'should I quit my job to become a data analyst', 'how can I try coding before a bootcamp', 'what's it really like to be an electrician'. Works for any named career. Returns one small real-world experiment that can be finished in an evening or a weekend, what is worth noticing, and 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": {
      "career": "<career>"
    },
    "name": "find_career_experiment"
  }
}

Input Schema

Name	Required	Description	Default
`career`	Yes	The career, field or kind of work they're curious about, in their words.

Output Schema

Name	Required	Description
`field`	No	The field named, when OffLadder holds a field-specific test for it.
`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.
`experiment`	Yes	The direction with its test, a field-specific test, or null for the general method.
`continue_url`	Yes	The same link, as the suggested next step.
`exact_direction`	Yes	True when the experiment comes from one of OffLadder's written directions.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavioral facts: exactly one experiment is returned, it is scoped to an evening or weekend, it includes 'what is worth noticing' and a handoff link to OffLadder's coach. That unpublished output shape and the single-result constraint are the useful additions. Minor gap: no mention of what happens with an unrecognised or vague career string.

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 core purpose and output are front-loaded and well formed, but the run of eight long quoted examples is bloated and repetitive, consuming most of the sentence without adding distinctions beyond the first two or three. It is clear but not tight; trimming half the examples would lose nothing.

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?

For a single-parameter read tool with an output schema, the description covers purpose, trigger situations, what the result contains and the coach handoff, which is close to everything an agent needs. The only missing piece is an explicit alternative when the user wants reference information rather than an experiment.

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% and the single parameter is documented in the schema itself as 'the career, field or kind of work they're curious about, in their words'. The description reinforces this only by stating 'Works for any named career' and showing example phrasings, which adds modest value rather than new syntax or constraints. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose5/5

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

States a specific verb and resource ('Finds a small way to try, test or get a feel for a career') plus the exact output ('one small real-world experiment that can be finished in an evening or a weekend'). The examples and the sentence 'Works for any named career' distinguish it from the sibling guide-checking tools, which return reading material rather than an experiment.

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?

Gives clear trigger context: use when someone is weighing whether to quit, retrain or switch into a field and wants hands-on validation before committing. The sample queries map directly onto that situation. It stops short of explicitly naming when not to use it or pointing to specific siblings like find_career_guide for general information instead.

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.