Open space-industry jobs (launch, satellites, spacecraft) from 47 employers, with posted pay.
Scored across 4 tools
Each tool has a distinct primary purpose: dataset/product info, market counts, pay statistics, and role search. The only mild overlap is between get_hiring_radar (dataset coverage) and get_space_jobs_market (current counts), but the descriptions make the boundary reasonably clear.
All names are snake_case and verb-first, which is readable. However, the convention is inconsistent: three use get_ while one uses search_, and get_hiring_radar omits the space_jobs domain prefix used by the others.
Four tools is well-scoped for a focused space-industry jobs data server. Each tool covers a distinct access pattern—discovery, aggregate counts, pay benchmarks, and dataset metadata—without redundancy.
The surface covers search, aggregate market counts, pay benchmarks, and dataset/product details, which supports the main workflows. Minor gaps remain, such as direct employer lookup, individual role detail beyond search results, and historical trend access.
Hiring radar is the investor dataset from SpaceJobs.Now. It holds every space industry role seen on an employer's own job board from the first time that board was read: a row per role (posted pay, field, eligible countries, opening and closing dates), daily figures per employer, and a change log. The tool reports current coverage, the available files, who uses it, the price and how to request a sample.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description usefully adds that this is a commercial dataset with a price and a sample-request path, and that it returns metadata rather than job rows — meaningfully beyond what the annotations say.
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?
It is a single sprawling sentence chain where the actual tool behavior ('The tool reports...') arrives only at the end. The dataset inventory (row per role, daily figures, change log) is informative but front-loads what the tool does not return.
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 and no parameters, the description must convey the return shape, and it does: coverage, file list, audience, price, sample-request instructions. It never clarifies the response format (e.g., whether files are URLs), but for a informational tool this is largely sufficient.
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?
Zero parameters, so the baseline is 4. Nothing in the description contradicts the empty schema, and no parameter semantics are needed.
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 final sentence states a concrete set of outputs (coverage, available files, users, price, sample request), so the agent knows this is a dataset-metadata/commercial-info tool. However, the majority of the description describes the underlying dataset's contents rather than the tool's action, and no sibling is named, so the distinction from get_space_jobs_market or search_space_jobs must be inferred.
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 investor framing plus price/sample-request mentions imply this is the tool to call when evaluating or licensing the dataset, but that is never stated as a rule. There is no explicit when-to-use, when-not-to-use, or pointer to the sibling tools that actually return job/pay data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts of space industry openings: the total open now, the number first listed over the past 7 days, and breakdowns by kind of work and by employer (each employer comes with the slug search_space_jobs accepts). Pass a country to count only roles that accept applicants from it.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Two-letter ISO 3166-1 country code such as 'US' or 'KE'; limits the counts to roles that accept applicants from there. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real behavioral context: the 7-day recency window and the fact that employer breakdowns carry slugs usable in another tool. No cost, pagination, or caching notes, but little is needed for a stateless counting call.
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 dense sentence that front-loads what is counted and reserves the final clause for the optional parameter. Every clause carries information, though the employer-slug parenthetical makes the sentence long enough to require a second read.
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 describing return shape and does so fully: totals, a 7-day delta, and two breakdown dimensions with their key format. Nothing an agent needs in order to call or interpret the result is missing.
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 coverage is 100% and the single parameter is fully documented with ISO format and examples. The description restates the filtering semantics ('roles that accept applicants from it'), which slightly clarifies that this is eligibility rather than job location, but adds no format or edge-case detail beyond the schema. Baseline 3 applies.
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 (counts) and resource (space industry openings) and enumerates exactly what is aggregated: total open now, newly listed in 7 days, breakdowns by kind of work and employer. The parenthetical tying employer entries to the slug that search_space_jobs accepts makes the distinction from the sibling search tool explicit.
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 only implied: it's evidently the aggregate-stats counterpart to search_space_jobs, and the country parameter's effect is described. But there is no explicit when-to-use / when-not guidance relative to get_hiring_radar or get_space_jobs_pay, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current pay in the space industry for each kind of work, as a year's pay (an hourly posting counts at 2,080 hours), taken from the pay posted on open roles: the median, the middle half (25th to 75th percentile), and the number of posted figures and employers behind each. A figure appears only where three or more employers post pay.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior. Beyond that, the description discloses important behavioral details: hourly postings are annualized at 2,080 hours, figures come from posted pay on open roles, and results are suppressed unless at least three employers post pay.
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 two sentences and front-loads the core purpose before adding computation and suppression details. Every sentence adds useful meaning with no filler.
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 parameters and no output schema, the description does a good job explaining the returned statistics and the three-employer suppression rule. It could still say more about how results are grouped or ordered, but it is largely complete for this tool.
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 tool has no input parameters, so there are no parameters to explain. Per the rubric, a zero-parameter tool receives a baseline of 4.
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 states a specific resource and scope: current space-industry pay for each kind of work, including median, interquartile range, and counts. It is clear what the tool returns, but it does not name or distinguish itself from siblings such as get_space_jobs_market or search_space_jobs.
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 description explains what data is available but gives no explicit guidance on when to use this tool versus sibling tools. An agent must infer its role from the title and data description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up open roles across the space industry (launch providers, satellite and spacecraft makers, and the suppliers behind them), gathered from the job boards of 150 employers. Each result gives the title, employer, kind of work, posted pay, the countries it accepts applicants from and an apply link on SpaceJobs.Now. Any filter can be left out.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Restrict results to one kind of work, given as an enum slug such as 'propulsion', 'mechanical-structures', 'avionics-electrical'. | |
| limit | No | Maximum number of results, anywhere from 1 to 25. | |
| query | No | Words to look for in role titles, such as 'propulsion', 'avionics', 'technician' or 'mission operations'. | |
| country | No | Two-letter ISO 3166-1 country code such as 'US', 'IN' or 'BR'; keeps only roles that accept applicants from there. | |
| platform | No | Employer slug, e.g. 'spacex', 'blue-origin', 'rocket-lab'. get_space_jobs_market lists them. | |
| min_pay_usd | No | Minimum pay as a year's pay in US dollars, e.g. 120000: a role passes when the top of its posted range reaches it. An hourly posting counts at 2,080 hours (40 a week for 52 weeks). | |
| min_hourly_usd | No | The same floor as an hourly rate, counted at 2,080 hours a year. Use min_pay_usd unless the person asked in hourly terms. |
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 still adds real value with provenance (aggregated from 150 employers' job boards) and an explicit enumeration of returned fields, but says nothing about result ranking, freshness, or what happens when filters are combined with no matches.
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 core action and scope, followed by the return-shape summary and the optional-filters note. Every clause carries information; only the employer-count and field list push slightly toward padding.
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?
For a seven-parameter, fully optional search tool with no output schema, the description covers what is searched, the corpus behind it, and the shape of each result. The remaining gap is guidance on how to choose it over the three sibling tools, which matters given the crowded namespace.
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%, with enums, ISO code formats, the 1-25 limit and the 2,080-hour pay conversion all documented in the schema itself. The description adds no syntax or interpretation guidance beyond what the schema already provides, so the baseline 3 applies.
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 ('Look up open roles across the space industry') and narrows scope with data provenance ('gathered from the job boards of 150 employers') plus the sub-sectors covered. It never names sibling tools like get_space_jobs_market or get_hiring_radar, so differentiation from them 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?
Usage is only implied by the verb 'look up' and the closing note 'Any filter can be left out.', which conveys that all filters are optional but not when to prefer this tool over get_space_jobs_market, get_hiring_radar or get_space_jobs_pay. The one routing hint to a sibling ('get_space_jobs_market lists them') lives in the platform parameter schema rather than in the description.
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.
search_space_jobs3 fields changedInput schema / properties / min_hourly_usd / descriptionPrevious value: -"Minimum pay in US dollars per hour: a role passes when the top of its posted hourly range is at least this figure."New value: +"The same floor as an hourly rate, counted at 2,080 hours a year. Use min_pay_usd unless the person asked in hourly terms."Input schema / properties / min_hourly_usd / maximumPrevious value: -1000New value: +2000Input schema / properties / min_pay_usdAdded value: +{
+ "description": "Minimum pay as a year's pay in US dollars, e.g. 120000: a role passes when the top of its posted range reaches it. An hourly posting counts at 2,080 hours (40 a week for 52 weeks).",
+ "maximum": 4160000,
+ "minimum": 1,
+ "type": "integer"
+}get_space_jobs_market1 field changedInput schema / properties / country / descriptionPrevious value: -"ISO 3166-1 alpha-2 code (e.g. 'US', 'KE'): count only roles open to applicants in that country."New value: +"Two-letter ISO 3166-1 country code such as 'US' or 'KE'; limits the counts to roles that accept applicants from there."search_space_jobs5 fields changedInput schema / properties / country / descriptionPrevious value: -"ISO 3166-1 alpha-2 code (e.g. 'US', 'IN', 'BR'): only roles open to applicants in that country."New value: +"Two-letter ISO 3166-1 country code such as 'US', 'IN' or 'BR'; keeps only roles that accept applicants from there."Input schema / properties / kind / descriptionPrevious value: -"Kind of work. One of the listed slugs, e.g. 'propulsion', 'mechanical-structures', 'avionics-electrical'."New value: +"Restrict results to one kind of work, given as an enum slug such as 'propulsion', 'mechanical-structures', 'avionics-electrical'."Input schema / properties / limit / descriptionPrevious value: -"How many roles to return (1 to 25)."New value: +"Maximum number of results, anywhere from 1 to 25."Input schema / properties / min_hourly_usd / descriptionPrevious value: -"Only roles whose advertised hourly ceiling reaches this many US dollars."New value: +"Minimum pay in US dollars per hour: a role passes when the top of its posted hourly range is at least this figure."Input schema / properties / query / descriptionPrevious value: -"Keywords matched against role titles, e.g. 'propulsion', 'avionics', 'technician', 'mission operations'."New value: +"Words to look for in role titles, such as 'propulsion', 'avionics', 'technician' or 'mission operations'."get_hiring_radarget_space_jobs_marketget_space_jobs_paysearch_space_jobsCareer-site jobs from Workday, Greenhouse, Lever, Ashby, iCIMS and more, with salaries where posted.
Job postings search: find, count and read open jobs from employer career sites, with pay and links.
Live job postings from company career pages on Greenhouse, Lever, Ashby and SmartRecruiters.
Open roles from public Greenhouse, Lever, Ashby, Workable job boards as clean data. Winters Works.
Add one secure layer between your agents and this server.