Read-only space industry data: launches, slips, funding, companies, space weather, Moon race, jobs.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 14 tools
Most tools target clearly distinct resources or views, but the launch cluster (launch_ledger_record, launch_slips, next_launches, launch_on_time_record) has overlapping subject matter around launch dates and slips. Descriptions help differentiate granularity and purpose, but an agent could still misselect without careful reading.
All tool names use a consistent snake_case, descriptive noun-based pattern, which is predictable and readable. They do not follow the common verb_noun convention, but the cross-tool consistency is strong.
14 tools is well-scoped for a broad space-data platform covering companies, launches, funding, weather, jobs, and search. Each tool appears to earn its place, and the count sits comfortably in the ideal 3-15 range.
The surface covers the main data domains well: company profiles, funding rounds, launch ledgers and forecasts, moon race, promises, jobs, weather, datasets, scores, and site search. Minor gaps exist, such as dedicated rocket or launch-site profile tools and a company list endpoint, but agents can work around these via search and related tools.
Public profile facts for a space company: what it does, sector, country, headquarters, founding year, public or private, ticker, total funding and last round as shown on its profile, and its Space Score when it is ranked.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many matching companies to return (1 to 5). | |
| query | Yes | Company name, profile slug or stock ticker, e.g. "Rocket Lab", "rocket-lab" or "RKLB". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description contributes one genuinely useful behavioral note — Space Score is only present 'when it is ranked' — but omits matching/ambiguity behavior and what is returned when nothing 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?
A single front-loaded sentence that enumerates the payload without filler; every clause carries information. It is dense but not padded.
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 correctly carries the return-shape burden by listing the profile fields, including the conditional Space Score. It falls short only on edge cases such as zero matches or multiple matches from the 1-5 limit.
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 documents both parameters at 100% coverage, including the name/slug/ticker formats and the 1-5 result limit, so the baseline is 3. The description adds nothing about how matching works or what happens when several companies match the query.
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?
Names a specific resource (space company) and enumerates the returned facts, so an agent knows exactly what a call yields. It does not, however, contrast itself with siblings like funding_round_history or space_score_history, which overlap on some of the same fields.
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?
There is no statement of when to use this tool versus the many sibling lookups; the overlap with space_score_history and funding_round_history is left for the agent to infer. Only the implicit 'lookup by name/slug/ticker' usage is signaled, via the schema rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Needs a SpaceNexus API key (a free key is enough). The bulk SpaceNexus datasets: for each one its CSV and JSON download links, what it holds, its columns, its licence statement, its DOI when minted and the page that shows it, plus the Promise Ledger CSV. The downloads themselves need no key.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | No | One dataset by slug or a word of its title, e.g. "launch-slips" or "funding". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered, and the description adds real extra context: an authentication requirement with a cost qualifier ('a free key is enough') and the important distinction that fetching the catalog needs a key but the underlying downloads do not. It stops short of saying what happens when the API key is missing or invalid.
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, no filler, and the front-loaded auth caveat is placed before the payload list so an agent learns the prerequisite first. The long enumeration of returned fields is dense but every item earns its place since there is no output schema to fall back on.
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 correctly carries the burden of describing the return payload, and it does so field by field, including the bonus Promise Ledger CSV. The one gap is the no-argument case (dataset is optional), where the agent must infer that omitting it returns the full catalog.
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 sole parameter already documents its accepted form ('a slug or a word of its title', with examples), so the schema carries the meaning. The description adds nothing about the parameter, and notably never says what happens when it is omitted — baseline 3 is appropriate.
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 resource precisely (the bulk SpaceNexus datasets) and enumerates exactly what is returned for each: CSV/JSON download links, contents, columns, licence, DOI and DOI page. It is distinguishable from siblings such as launch_slips or funding_round_history, which return records rather than download links, though it never states the verb explicitly and never names an alternative tool.
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: 'The bulk SpaceNexus datasets' suggests this is the tool for bulk download links rather than live record lookups, but there is no explicit when-to-use or when-not-to-use statement and no sibling is named. It does supply a useful prerequisite (API key required, free key sufficient) and clarifies that the downloads themselves need no key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Needs a SpaceNexus API key on the Professional or Research plan. The full published history of private funding rounds into space companies, not only the last 90 days: date, amount (null when undisclosed or stated only approximately, never estimated), series and round type, pre- and post-money valuation where the source names the basis, lead investor and every listed investor, how the round is evidenced and its source link. Filter by company, investor, stage, dates and amount; page with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many rounds to return (1 to 25). | |
| since | No | Rounds dated on or after this day (YYYY-MM-DD). | |
| stage | No | Round stage or series label (substring), e.g. "Seed", "Series B". | |
| until | No | Rounds dated on or before this day (YYYY-MM-DD). | |
| offset | No | Rounds to skip, for paging (0 to 10000). | |
| company | No | Company name or profile slug (substring). | |
| investor | No | Investor name: matches the lead investor or any listed investor (substring). | |
| min_amount_usd | No | Only rounds with a disclosed amount at or above this, in US dollars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing the auth requirement (SpaceNexus key on Professional or Research plan) and, importantly, the data-quality contract: amount is null when undisclosed or only approximate and is 'never estimated'. That is exactly the behavioral context an agent needs to avoid misreporting values.
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?
Front-loads the access prerequisite, then the resource and returned field inventory, then filtering/paging. Information-dense with no filler, though the second sentence is a long enumerated run-on that could be tightened.
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 full return-value burden and does so thoroughly (date, amount and its null semantics, series/round type, valuation and basis, lead plus all listed investors, evidence type and source link). Auth, filtering and paging are all covered.
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% across all 8 parameters, so the schema already documents limit, since/until, stage, offset, company, investor and min_amount_usd. The description's 'filter by company, investor, stage, dates and amount; page with offset' restates those semantics and the lead-vs-listed-investor nuance without adding syntax or format detail.
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+resource with scope: 'the full published history of private funding rounds into space companies'. It explicitly contrasts its coverage with the last-90-days subset, which lets an agent distinguish it from the sibling recent_funding_rounds without opening either schema.
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?
'Not only the last 90 days' plus the filter/paging sentence tells the agent when this tool is the right choice versus a recent-rounds tool. It does not name the alternative sibling by name or state exclusions, so it stops short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Needs a SpaceNexus API key (a free key is enough). The full Launch Ledger record: every launch date change our ledger holds since recording began, one row per launch per UTC observation day, with the observation fields (live or catch-up, the catch-up reason, Launch Library 2's last-updated time), both dates at their precision and its basis, the size and kind of the move, and whether it counts as a slip. Filter by launch, provider, rocket, observation, kind and day; page with offset. The same rows as the free launch-slips dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only this kind of move: slip, pull-in, adjust, firmed, loosened or placeholder. | |
| limit | No | How many rows to return (1 to 25). | |
| since | No | Only changes observed on or after this UTC day (YYYY-MM-DD). | |
| launch | No | One launch: its name or mission (substring, e.g. "Starship Flight 14") or its Launch Library 2 id. | |
| offset | No | Rows to skip, for paging (0 to 10000). | |
| rocket | No | Only launches of this rocket (substring). | |
| provider | No | Only launches by this provider (substring or common short name, e.g. "ULA", "CASC"). | |
| observation | No | live: changes our sync saw when they happened; catch-up: changes it only caught up with late; all: both. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive/openWorld=false, so safety is covered. The description adds materially beyond them: an API-key requirement, the row grain (per launch per UTC observation day), the live vs catch-up observation model, and offset-based paging. It omits rate limits and any note on response size or ordering.
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?
Front-loads the auth requirement, then the row semantics, then filters, then paging. The middle sentence is a long run-on clause chain, but nearly every clause carries distinct information and nothing is redundant 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?
For an 8-parameter read tool with no output schema and no required params, the description does substantial work: it defines the row grain, enumerates the returned fields, lists the filterable dimensions, and states the paging mechanism. The remaining gap is the unresolved routing versus launch_slips.
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 is already documented in the schema; baseline is 3. The description's filter list ('launch, provider, rocket, observation, kind and day') merely mirrors the schema and is slightly looser than reality, since it says 'day' where the schema's parameter ('since') filters on-or-after.
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 resource and its exact contents: 'every launch date change our ledger holds... one row per launch per UTC observation day,' and enumerates the observation fields it carries. This is far more than a restatement of the name. It does not, however, crisply separate itself from siblings launch_slips or launch_on_time_record, so it stops short of 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?
Gives a real prerequisite ('Needs a SpaceNexus API key (a free key is enough)') and names the related free dataset. But the relationship is left ambiguous – 'The same rows as the free launch-slips dataset' tells an agent the rows match without saying which tool to pick or when. No explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How often launches fly on time: the share of flown launches that lifted off within 1 day and within 7 days of the first firm date on record, with mean and median delay, grouped by provider, vehicle or launch site.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Only groups whose name contains this text, e.g. "SpaceX" or "Falcon 9". | |
| limit | No | How many groups to return (1 to 25). | |
| group_by | No | Group the on-time record by launch provider, vehicle or launch site. | provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a read-only, idempotent, closed-world operation, so the bar is lower. The description adds meaningful methodological context — the 1-day and 7-day windows measured against the first firm date — which tells the agent how the numbers are derived and why results may differ from raw slip data.
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, front-loaded with the core metric and its exact thresholds, then the aggregate measures, then the grouping options. No filler or restatement of the title.
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 no-required-parameter aggregation tool with no output schema, the description defines the metrics well enough to interpret results. It stops short of describing the returned shape (group label, counts, sample size), which would help since no output schema exists, but nothing needed to invoke it correctly 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 description coverage is 100% — name, limit, and group_by are all documented in-schema, including the enum values and default. The description restates the grouping dimension but adds no filtering syntax or semantic nuance beyond the schema, 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?
The description states a specific computed resource (on-time launch record) with exact metric definitions: share lifted off within 1 day and 7 days of the first firm date, plus mean/median delay and grouping dimension. This distinguishes it clearly from siblings like launch_slips (individual slips) and next_launches (upcoming).
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 by the metric definition and the group_by parameter, but the description never states when to prefer this over launch_slips or launch_ledger_record, nor any preconditions. An agent can infer the niche but must do the routing work itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent launch date changes as the SpaceNexus slip ledger recorded them (old date, new date, size of the move, kind of move), with totals since recording began and the provider scorecard once the ledger is large enough. Each change carries observation: live (our sync saw it when it happened) or catch-up (our sync only caught up late, so observedAt is when we saw it, not when it changed). Caught-up changes are returned apart in caughtUpChanges and never counted in the summary figures.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent date changes to return (1 to 25). | |
| rocket | No | Only moves of this rocket (substring). | |
| provider | No | Only moves by this provider: a name or common short name (ULA, ISRO, CASC). | |
| real_moves_only | No | Leave out placeholder moves (a "NET 2026" style date firming or rolling); keep slips, pull-ins and adjustments. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm a safe, idempotent read, and the description goes well beyond them: it defines the live vs catch-up observation semantics, warns that observedAt reflects sync time rather than change time for catch-up entries, and states that caught-up changes are split out and excluded from summary figures. These are exactly the behavioral quirks an agent could not infer from annotations.
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?
Three sentences, no filler, and the core payload description leads. The sentences are dense and somewhat long, but each one carries distinct information (payload, observation semantics, exclusion from totals) rather than restating the name.
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 return-shape burden and does so: it names the per-change fields, the summary totals, the provider scorecard (with its size conditionality), and the separate caughtUpChanges collection. An agent knows what it will get and how the bucket is split.
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 each of the four parameters is already documented in the schema with ranges and semantics. The description adds no syntax, format, or defaulting detail beyond that, 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?
The description states a precise resource — recent launch date changes from the slip ledger — and enumerates the payload (old date, new date, size of move, kind of move) plus summary totals and a provider scorecard. This is far more specific than the name alone and reads differently from siblings like launch_on_time_record or next_launches, though it never explicitly names the tool it is not.
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 by 'Recent launch date changes' but there is no explicit when-to-use, when-not-to-use, or routing to an alternative sibling (e.g. launch_on_time_record or launch_ledger_record). The observation/filter explanation tells the agent how the data behaves, not when to pick this tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The US vs China Moon race tracker: milestones demonstrated on both 8-rung ladders (crewed landing and sustained presence), who leads each, the projection call with its date bands, official targets and the next uncrewed landing attempt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare that this is a safe, read-only, idempotent, non-destructive operation with no open-world side effects. The description adds no behavioral traits beyond content, such as caching, refresh frequency, or error behavior. A 3 is appropriate because annotations carry the safety profile and the description focuses on data rather than behavior.
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?
A single sentence that is front-loaded with the tool's domain. It is efficient and contains no filler, though the dense comma-separated list of return items could be made slightly more scannable.
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 input parameters and no output schema, the description carries the full burden of explaining return values. It does so thoroughly by listing the key data points (ladder milestones, leaders, projections with date bands, official targets, next uncrewed landing attempt), leaving no major gaps for an agent to call this tool 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?
The tool takes zero parameters, so there are no parameter semantics to document. Baseline of 4 is correct for a parameterless tool.
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 resource (US vs China Moon race tracker) and enumerates the returned data (milestones on 8-rung ladders, who leads each, projection call, official targets, next uncrewed landing attempt). This clearly distinguishes it from all siblings, which cover launches, funding, jobs, or space weather.
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?
Provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Usage is only implied by the content description, which is essentially tautological with the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upcoming orbital launches from the SpaceNexus manifest (the next 50 scheduled), filterable by provider, rocket, launch site and country. Each launch has its NET date and precision, status, the date changes our ledger recorded, and its page URL. realSlips and otherDateMoves count only changes our sync saw when they happened; caughtUpDateMoves counts changes it only caught up with late (made earlier, on a day we do not know), which are never counted as slips.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Launch site: a spaceport name or slug ("Cape Canaveral" includes Kennedy, "vandenberg", "Starbase", "Andoya") or any pad name. | |
| limit | No | How many launches to return (1 to 20). | |
| rocket | No | Rocket, matched as a substring, e.g. "Falcon 9", "Starship", "Long March". | |
| country | No | Country of the launch site, by name or code, e.g. "United States", "China", "France" (Kourou), "NZL". | |
| provider | No | Launch provider: a name or common short name, e.g. "SpaceX", "ULA", "ISRO", "CASC", "Rocket Lab". | |
| include_recent_outcomes | No | Also return launches flown in the last 30 days with their outcome. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world). The description adds meaningful behavioral context by explaining what each launch record contains and defining realSlips, otherDateMoves, and caughtUpDateMoves, including the caveat that caught-up changes are never counted as slips. This goes beyond the annotations.
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 purpose and filters, then moves to record fields and slip semantics. Three sentences with little waste, though the final sentence about slip counting is dense and could be trimmed or moved to a data dictionary without losing the core tool description.
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 read-only list tool with full annotations but no output schema, the description adequately covers return fields (NET date and precision, status, date changes, page URL) and data semantics. It does not mention pagination, ordering, or the relationship between the 50-item manifest and the limit parameter, but these are minor gaps for a simple list endpoint.
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 the schema already documents all six parameters in detail. The description names four filter dimensions (provider, rocket, launch site, country) but does not add syntax, format, or behavior beyond what the schema provides; limit and include_recent_outcomes are not mentioned. Baseline 3 is appropriate.
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 verb and resource: 'Upcoming orbital launches from the SpaceNexus manifest ... filterable by provider, rocket, launch site and country.' It is clear what the tool returns, though it does not explicitly differentiate itself from sibling tools like launch_slips or launch_ledger_record.
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?
There is no explicit when-to-use guidance, no alternatives named, and no conditions for choosing this tool over siblings such as launch_slips or launch_on_time_record. Usage is only implied by the phrase 'Upcoming orbital launches.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Needs a SpaceNexus API key (a free key is enough). Entries from the SpaceNexus Promise Ledger: dated public commitments about spaceflight by agencies, companies and executives, each with the verbatim quote, who said it and when, the deadline as stated and normalised, the status shown today, the outcome and its source, and every later revision. Filter by party, status, claim type or words; page with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many entries to return (1 to 25). | |
| party | No | An organisation or a person: name or slug, e.g. "SpaceX", "NASA", "elon-musk". | |
| query | No | Words to find in the claim, quote or context. | |
| offset | No | Entries to skip, for paging (0 to 10000). | |
| status | No | Only entries shown with this status today. | |
| claim_type | No | Only this kind of claim. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, idempotent, non-destructive read, so the bar is lower. The description adds genuinely new behavior: it requires a SpaceNexus API key (free tier sufficient), which the annotations do not convey, and it details the shape of returned records including revision history.
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 auth requirement, data shape and filtering/paging instructions are front-loaded in two dense sentences with no filler. The middle enumeration of fields is long but each clause earns its place by describing the record; a minor cost is that it reads as a run-on.
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 return-value burden and does so well, listing quote, speaker, date, stated/normalised deadline, status, outcome, source and revisions. Auth, filtering and paging are all covered; only ordering/recency of results and behavior at high offsets are left unstated.
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 the schema already documents all six parameters, including enums and bounds. The description restates the filter facets ('party, status, claim type or words') and offset paging but adds no syntax, format or edge-case detail beyond the schema — 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?
The description names the specific resource (SpaceNexus Promise Ledger entries) and enumerates what each entry contains, so an agent knows exactly what it retrieves — dated public commitments with quotes, deadlines, status and outcomes. It implicitly separates itself from launch-oriented siblings by entity type, but never names a sibling or an explicit verb like 'list/retrieve'.
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 states the entry point ('Filter by party, status, claim type or words; page with offset') and an auth prerequisite, which implies when the tool is useful. There is no explicit when-not guidance and no named alternative for adjacent data (e.g. launch_ledger_record or company_lookup), so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Closed private funding rounds into space companies in the last 90 days, newest first, with amount (null when undisclosed, never estimated), stage, investors, how the round is evidenced and its source link.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (1 to 90). | |
| limit | No | How many rounds to return (1 to 25). | |
| stage | No | Round stage, matched as a substring, e.g. "Seed", "Series B". | |
| company | No | Company name, matched as a substring. | |
| min_amount_usd | No | Only rounds with a disclosed amount at or above this, in US dollars. |
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 covered. The description adds genuine data-quality context the annotations cannot: amounts are null when undisclosed and 'never estimated', and each round carries its evidence trail and source link.
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 dense sentence that front-loads scope and ordering before the field list, with no filler. Slightly long, but each clause (null handling, evidence, source link) carries distinct 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 compensates by enumerating the returned fields (amount, stage, investors, evidence, source link) and the sort order, plus the null-amount rule. A reader can predict the response shape; only pagination/total-count behavior is left unspecified.
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%, so the schema already documents days, limit, stage, company, and min_amount_usd with ranges and matching semantics. The description adds only the placeholder/never-estimate rule for undisclosed amounts, which is marginal extra meaning over the schema 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 resource (closed private funding rounds into space companies), the scope (last 90 days), and the ordering (newest first), which cleanly separates it from the sibling funding_round_history that covers older/all rounds. An agent can identify what it returns without opening the schema.
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 by the 90-day window and the sibling set, but the description never states when to pick this over funding_round_history or company_lookup, and lists no exclusions. It is adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search spacenexus.us: companies, rockets, launches, launch sites, guides, charts, Moon missions, funding rounds and analysis. Returns titles, one-line descriptions and the canonical URL of each page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return (1 to 10). | |
| query | Yes | What to look for on spacenexus.us: a company, rocket, launch, guide, chart or topic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds real value by stating the return shape (titles, one-line descriptions, canonical URLs), which matters given there is no output schema. It says nothing about ranking or pagination, but that is a minor omission against annotation coverage.
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, zero filler, with the tool's scope front-loaded and the return format trailing. Every clause earns its place.
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 read-only, idempotent search tool with a fully documented two-parameter schema, the description covers what it searches and what it returns. Missing only ranking/relevance or result-ordering behavior, which an agent would benefit from knowing.
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 both parameters (query, limit) are already fully documented in the schema. The description restates the query domain but adds no syntax, matching, or format detail beyond it. Baseline 3 is appropriate.
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 (Search) and resource (spacenexus.us) and enumerates the content types covered: companies, rockets, launches, launch sites, funding rounds, etc. This implicitly positions it as the broad search tool versus the narrow sibling lookup tools, though it never names a sibling explicitly.
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?
No when-to-use or when-not-to-use guidance, and no routing to alternatives. With 13 highly specific siblings (company_lookup, launch_ledger_record, recent_funding_rounds, etc.) an agent must infer on its own whether to search broadly here or use a dedicated tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many open roles the SpaceNexus jobs board lists right now (mirrored daily from employers' careers pages), how many employers are hiring, how many roles are new this week or remote, and optionally one employer's open roles.
| Name | Required | Description | Default |
|---|---|---|---|
| company | No | Employer name; returns that employer's open roles on the board when we track it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and non-open-world, so the safety profile is covered. The description adds meaningful provenance context beyond that: counts are 'mirrored daily from employers' careers pages,' which tells the agent the data can be up to a day stale. It does not describe caching or rate limits.
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?
A single front-loaded sentence that leads with the primary counts before the optional per-employer case. It is slightly run-on with the parenthetical provenance note, but no sentence is wasted.
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 does so by enumerating the count categories an agent will receive. Combined with annotations covering safety and the daily-mirror freshness note, an agent has enough to call it correctly, though the exact response shape (field names) is unspecified.
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% for the single 'company' parameter, so the schema already documents it. The description contributes only the optionality framing ('optionally one employer's open roles'), which mirrors rather than extends the schema — baseline 3 is appropriate.
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 specific resource (SpaceNexus jobs board) and enumerates the metrics returned: open roles, hiring employers, new-this-week and remote counts, plus an optional per-employer breakdown. It is clearly distinct from siblings like company_lookup or launch_ledger_record, though it never states the verb 'count' or 'return' explicitly.
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: no-argument calls give global board counts, and passing an employer narrows to that employer's open roles. There is no explicit when-to-use vs alternatives guidance (e.g., versus company_lookup) and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Needs a SpaceNexus API key whose owner has SpaceNexus Research (the Space Score history is a Research product). One company's daily Space Score readings for up to 365 days: score, rank, the change from the previous reading, large moves flagged, and why a reading moved where the stored inputs can say. The current score stays free in company_lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (1 to 365). | |
| company | Yes | Company name or profile slug, e.g. "Rocket Lab" or "rocket-lab". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine value annotations cannot: the entitlement-gated API key requirement and the content of each reading, including that reasons are limited to 'where the stored inputs can 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?
Three sentences with little waste, and the prerequisite is front-loaded before the payload description. The final sentence on company_lookup is a useful routing cue rather than filler, though the first sentence is slightly dense.
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 enumerates what a reading contains and bounds the window to 365 days. Combined with the auth caveat and the sibling cross-reference, an agent has everything needed to call it 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 both parameters are documented in the schema. The description only echoes 'up to 365 days', adding no syntax or format 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 resource (daily Space Score readings for one company, up to 365 days) and enumerates the returned fields: score, rank, change, flagged large moves, and reason. It also distinguishes itself from the sibling company_lookup, which only serves the current score.
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?
Explicitly routes the agent to company_lookup when only the current score is needed and states the prerequisite (a SpaceNexus API key whose owner has the Research product). Clear context, though it doesn't spell out failure behavior when the key lacks the entitlement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current geomagnetic Kp and NOAA G-scale, solar wind speed, density and Bz, the NOAA 3-day flare outlook and flares in the last 14 days, with a plain-language read for satellite operators. NOAA SWPC and NASA DONKI data.
| 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, closed-world behavior, so the safety profile is fully covered. The description adds behavioral context the annotations cannot: the upstream data sources (NOAA SWPC, NASA DONKI) and the time windows of the data returned (3-day outlook, 14-day flare history), though it does not state refresh cadence or latency for 'current' values.
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?
A single dense sentence with the substantive content list front-loaded, followed by a short source attribution. Every listed field earns its place because it defines the return payload, which no output schema provides.
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 full burden of describing the return value, and it does so field by field, including the derived 'plain-language read' and the origin of each dataset. An agent can act on this without further documentation.
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 takes zero parameters, so there is nothing for the description to disambiguate; per the rubric this is the baseline 4. The description correctly avoids inventing parameter-like options (no filtering or date arguments).
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 resource (current space weather) and enumerates precisely which readings are returned: Kp/G-scale, solar wind speed, density, Bz, flare outlook and 14-day flare history. No sibling tool covers space weather, so the purpose is unambiguous and easily distinguished from the launch/funding/jobs tools listed.
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 through the stated audience ('a plain-language read for satellite operators'), which signals the operational use case, but the description gives no explicit trigger conditions, no 'use this when you need X' clause, and no mention of alternatives or when this tool is not appropriate. Adequate but with a clear gap.
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.
company_lookupdataset_linksfunding_round_historylaunch_ledger_recordlaunch_on_time_recordlaunch_slipsmoon_race_statusnext_launchespromise_ledger_entriesrecent_funding_roundssearch_sitespace_jobs_countspace_score_historyspace_weather_nowLive space data for AI agents - rocket launches, ISS passes, launch news. Free, no auth.
Rocket launch schedule: SpaceX, Falcon, Electron. $0.01/query, free testnet funds.
Sourced data on 95+ frontier-industry companies: profiles, dated milestones, funding, daily news.
Launch Library 2 MCP — global rocket launch data
Add one secure layer between your agents and this server.
