Search open robot training jobs (robot teleoperation, demonstration data collection, at-home video recording, robot QA, robot fleet operations, autonomous vehicle and drone operator roles) from about 60 employers, with the hourly pay each role advertises. Updated daily from the employers' own job feeds.
Scored across 3 tools
The three tools are clearly separated by output type: aggregate market counts, aggregate pay statistics, and individual job listings. The only mild overlap is that market and pay both summarize the same underlying job pool, but the descriptions make the distinction (counts vs. hourly rates) explicit.
All three tools follow a predictable verb_noun pattern with a shared 'robot_training' domain prefix: get_robot_training_market, get_robot_training_pay, search_robot_training_jobs. The verb choice (get for aggregates, search for listings) is used consistently and meaningfully.
Three tools is on the lean side but each covers a distinct need (demand snapshot, pay benchmark, job search) with no redundancy. A small surface is defensible for a niche job-board dataset, though one more tool (e.g. job detail or employer lookup) would round it out.
The core discovery workflow is covered: search listings, then check market and pay context. However, there is no way to fetch a single job's full detail or list all employers/programs directly, so an agent hitting a role in search results must leave the server to learn more.
How many robot training jobs are open right now, how many were listed in the last 7 days, and the open roles by kind of work and by employer (with each employer's slug for search_robot_training_jobs). Optionally scoped to the roles open to applicants in one country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 code (e.g. 'US', 'KE'): count only roles open to applicants in that country. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real substance beyond that: the 7-day lookback window, the grouping dimensions of the aggregation, and the meaning of the optional country scope. Minor gap only in not stating whether results are live or cached snapshots.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that front-loads the headline counts, then the breakdowns, then the optional scope — no filler and nothing that could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return shape, and it does so adequately by enumerating the counts and the two breakdown dimensions plus the employer slug field. It stops short of describing structure (e.g., whether counts are nested objects or fields), which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single 'country' parameter is already fully documented with ISO 3166-1 alpha-2 examples. The description's 'roles open to applicants in one country' phrasing reinforces the semantics but adds no syntax or constraint information beyond the schema, so this sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact metrics returned — total open jobs, jobs listed in the last 7 days, and breakdowns by kind of work and by employer — rather than restating the title. It also names the sibling tool search_robot_training_jobs as the consumer of the employer slugs, so an agent can tell this apart from the search and pay siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the right context (market-level aggregation, with employer slugs intended as a handoff into search_robot_training_jobs) and explains that the country filter is optional scoping. There is still no explicit 'use this instead of get_robot_training_pay when...' statement or exclusion guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What robot training work pays per hour today, by kind of work: the median and the typical range (25th to 75th percentile) of the rates open roles advertise, with how many rates and employers each figure comes from. A rate is shown only when at least three employers advertise it. Name a kind of work to have its figure first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Kind of work to answer first, e.g. 'teleoperation'. The other kinds follow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent operation, so the bar is lower. The description still adds meaningful behavioral context: it reports advertised hourly rates via median and interquartile range, includes sample sizes by rates and employers, and suppresses figures when fewer than three employers advertise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core output and stays compact while covering the key metrics, suppression rule, and optional ordering behavior. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and no output schema, the description provides enough context to invoke the tool correctly: it explains the statistics returned, the minimum-employer threshold, and how the optional kind parameter affects ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage for the single enum parameter and already explains that it selects which kind of work appears first. The description reinforces that the named kind is shown first, but adds little semantic detail beyond the schema's own description and example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (robot training pay per hour by kind of work) and the specific outputs (median, 25th–75th percentile range, sample counts). It does not explicitly differentiate itself from siblings like get_robot_training_market or search_robot_training_jobs, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool returns pay figures and the optional kind parameter moves a chosen category to the front. There is no explicit guidance on when to use this instead of the sibling job-search or market tools, nor any stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the open robot training jobs (paid work piloting, teaching, recording for and testing robots, autonomous vehicles and drones) across about 100 employers and programs such as Tesla, Figure, Waymo, Zipline, micro1 and Claru. Returns each role's title, employer, kind of work, advertised pay, where it is open and a link to apply on RobotTraining.jobs. All filters are optional.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Kind of work. One of the listed slugs, e.g. 'teleoperation', 'egocentric-wearable', 'av-drone-operator'. | |
| sort | No | 'recent' for the newest roles first, 'pay' for the highest advertised pay first. Default: a mix across employers. | |
| limit | No | How many roles to return (1 to 25). | |
| query | No | Keywords matched against role titles, e.g. 'teleoperator', 'drone', 'test driver', 'humanoid'. | |
| country | No | ISO 3166-1 alpha-2 code (e.g. 'US', 'IN', 'BR'): only roles open to applicants in that country. | |
| platform | No | Employer slug, e.g. 'tesla-optimus', 'waymo', 'micro1'. get_robot_training_market lists them. | |
| remote_only | No | Only roles that can be done remotely (from home). | |
| min_hourly_usd | No | Only roles whose advertised hourly ceiling reaches this many US dollars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real context beyond that: the corpus spans roughly 100 employers, each result carries title, employer, work kind, advertised pay, location and an application link. It omits pagination/coverage behavior beyond the schema's 25-item cap, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the search scope and followed by the return shape. The employer roll-call ('Tesla, Figure, Waymo, Zipline, micro1 and Claru') is longer than strictly needed, but it earns its place by signaling the site's coverage to an agent deciding relevance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns and it does so explicitly, enumerating the six fields per role and the application link. Combined with full schema coverage and existing annotations, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including enums, defaults and the ISO country code already has authoritative documentation. The description adds only the blanket statement that all filters are optional, which is already implied by zero required parameters, so it neither clarifies nor misleads.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the open robot training jobs') and defines the domain with concrete examples of work types and employers, so an agent knows exactly what corpus is being queried. It stops short of naming the sibling tools (get_robot_training_market, get_robot_training_pay), so the boundary between searching roles and listing employers or pay data is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing 'All filters are optional' tells the agent it can call with no arguments, which is genuine usage guidance. There is no statement of when to prefer this tool over get_robot_training_market or get_robot_training_pay, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_robot_training_pay1 field changedInput schema / propertiesAdded value: +{
+ "kind": {
+ "description": "Kind of work to answer first, e.g. 'teleoperation'. The other kinds follow.",
+ "enum": [
+ "teleoperation",
+ "demonstration-collection",
+ "egocentric-wearable",
+ "embodied-annotation",
+ "robot-qa-eval",
+ "fleet-ops",
+ "av-drone-operator"
+ ],
+ "type": "string"
+ }
+}search_robot_training_jobs2 fields changedInput schema / properties / remote_onlyAdded value: +{
+ "description": "Only roles that can be done remotely (from home).",
+ "type": "boolean"
+}Input schema / properties / sortAdded value: +{
+ "description": "'recent' for the newest roles first, 'pay' for the highest advertised pay first. Default: a mix across employers.",
+ "enum": [
+ "recent",
+ "pay"
+ ],
+ "type": "string"
+}get_robot_training_marketget_robot_training_paysearch_robot_training_jobs
Add one secure layer between your agents and this server.