Spacecraft component specs from vendor datasheets: search, digests, facts, gaps, budgets, bus design
Scored across 10 tools
Each tool has a clearly defined role, but a few pairs overlap in surface behavior: ask_datasheet versus search_datasheet_facts both query datasheet content, and build_budget versus design_stack both compute budgets. The detailed descriptions mostly resolve these boundaries, so confusion is possible but unlikely with careful reading.
All ten tool names follow the same imperative verb_noun pattern in snake_case: ask_datasheet, build_budget, check_fit, design_stack, explain_properties, find_data_gaps, get_component_specs, get_datasheet_digest, match_components, search_datasheet_facts. This is highly predictable and consistent.
Ten tools is well-scoped for the domain of spacecraft component datasheet analysis, matching, fit checking, budgeting, and design. The count is high enough to cover a complex workflow without becoming bloated or redundant.
The tool set covers the full workflow: exploring datasheets, understanding properties, searching facts, matching components, checking fit, building budgets, assembling a full design, and identifying data gaps. There are no obvious dead ends—even missing data is handled by find_data_gaps and ask_vendor references.
Ask a product datasheet a question and get the closest excerpts with page numbers (pre-indexed text), or scan ALL datasheets of a category for an exact term (term + category) and get the exact list of products mentioning it with an excerpt each.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | question to one datasheet | |
| term | No | exact word/phrase for the category scan, e.g. SpaceWire, ITAR | |
| category | No | ||
| product_id | No |
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 behavior is covered. The description adds genuinely useful behavior beyond that: the corpus is pre-indexed text, single-datasheet answers are 'closest excerpts' with page numbers, and category scans return an exact product list with one excerpt each. No output schema exists, so this return-shape detail is doing real work.
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, but well front-loaded: the primary ask-a-datasheet mode comes first, the scan alternative second. Every clause carries content; only the repeated 'and get...' construction adds mild redundancy.
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 4-parameter, dual-mode, closed-world tool with no output schema, the description covers both modes and roughly what each returns. It still leaves gaps an agent needs: that product_id is the single-datasheet selector, that category is required for the scan path, and that no parameters are formally required, so an under-specified call is possible.
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 50%, so the description must compensate. It does explain q and the term+category pairing implicitly, and its 'exact term' note aligns with the schema's 'exact word/phrase' wording, but product_id is never explained and category's role as a mode selector is only implied by the phrase 'of a category'.
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 two concrete verbs (ask/get excerpts vs. scan/list products) against named resources (a single datasheet, all datasheets of a category). An agent can tell what the tool does, though it never contrasts itself with close siblings like search_datasheet_facts or get_datasheet_digest.
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 clearly routes the agent between the two modes by naming the parameter combinations that select each (q for one datasheet; term + category for a category-wide scan). It stops short of stating exclusions or when to prefer a sibling search tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Engineering budget for a component stack: pass product ids (from the other tools) and your bus voltage, get total mass, total steady-state power, per-item data interfaces, voltage-compatibility verdicts and an honest list of what could NOT be counted because the vendor does not publish it. Use it to assemble and sanity-check a subsystem, e.g. 3-4 reaction wheels for an ADCS.
| Name | Required | Description | Default |
|---|---|---|---|
| bus_v | No | power bus voltage, V — each item is checked against its supply range | |
| items | Yes | components of the stack |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond that: it performs voltage-compatibility checking and transparently reports items that could not be counted due to missing vendor data. This gives the agent an honest picture of what the tool will and won't provide.
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 with no filler. It front-loads the primary function, enumerates specific outputs, adds the important limitation about unpublished vendor data, and closes with a concrete usage example. Every sentence 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 tool with no output schema, the description enumerates the return values well: total mass, total steady-state power, per-item data interfaces, voltage-compatibility verdicts, and excluded items. It explains the integration with sibling tools and provides a realistic usage scenario. The parameter schema is complete, so no critical information 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?
The input schema already documents both parameters fully, including the bus voltage supply-range check and the items array with id and qty. The description adds value by clarifying that product ids come from other tools and that bus voltage is 'your' power bus voltage, tying the parameters to the intended workflow. This goes slightly beyond the schema's plain definitions.
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 identifies the tool's purpose: building an engineering budget for a component stack. It specifies the inputs (product ids, bus voltage) and outputs (mass, power, data interfaces, voltage verdicts, excluded items), and distinguishes itself from sibling tools by focusing on budget assembly rather than component lookup or matching.
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 gives clear guidance on when to use the tool: 'assemble and sanity-check a subsystem' with a concrete example (3-4 reaction wheels for ADCS). It also implies the ids come from other tools, which routes the agent to the correct workflow. It does not explicitly list exclusions or name sibling alternatives, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a set of products docks together, by the interface template of each product type: deployer and CubeSat structure form factor and satellite mass, separation system and spacecraft mass, solar panel size and EPS solar input (Voc/Vmp, power), battery and EPS, EPS output rails or the unregulated bus against each unit supply range, EPS charge current against the battery limit, satellite envelope against the deployer envelope for its form factor, on-board computer against unit data interfaces, board stack format, free volume, radio against antenna and ground station (frequency, band, connector, protocol and modulation), antenna against ground station polarization, GNSS receiver signals against the GNSS antenna band, magnetorquer coil current against the driver channel, PPU output power against the electric thruster, array drive against panel power, propulsion propellant against tank media, steady power budget. Verdicts fits / conflict / check / unknown, plus ask_vendor: exactly which values are missing to decide.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | products of the spacecraft, deployer or ground segment (ids from match_components) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral detail beyond that by specifying the verdict categories (fits / conflict / check / unknown) and the ask_vendor behavior that reports exactly which values are missing to decide.
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?
This is one very long, run-on sentence that compresses dozens of interface checks into a single block. The content is informative, but the lack of bullet points or paragraph separation makes it difficult to parse. It is front-loaded with the core purpose, yet the enormous checklist hurts readability.
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 complex compatibility-checking tool with no output schema, the description does a good job of explaining what is checked and what verdicts are returned, including the ask_vendor fallback. It is missing only minor details such as how quantities affect the fit check or the exact structure of the returned verdicts.
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 input schema covers 100% of the single parameter's semantics: items is described as products of the spacecraft, deployer or ground segment, and each item has an id and optional qty. The description does not add parameter-level detail, but the baseline of 3 applies because the schema already carries the load.
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 opens with a specific verb and resource: 'Check whether a set of products docks together,' followed by an exhaustive enumeration of the interface checks performed. This makes the tool's purpose unmistakable and distinguishes it from match_components, which is about finding compatible parts rather than verifying a given set.
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 intended use is implied by the purpose: call this after a set of products has been identified, likely following match_components. However, the description never explicitly says when to use this tool versus siblings, nor does it state when not to use it or suggest an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assemble a whole spacecraft bus from a plain-language task: the service plans the subsystems, matches every item deterministically against the stated requirements, computes the mass/power budget and writes an evidence-bound rationale. Pass fixed = product ids you have already chosen (from match_components or get_datasheet_digest): they stay in their subsystems, are checked against the requirements (selected.fixed, fixed_verdict, fixed_fails) and the rest is assembled around them. LLM-backed and rate-limited (6/min, 30/h anonymous).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | the task, e.g. "6U CubeSat bus on 12 V with S-band radio and GNSS, star tracker better than 10 arcsec" | |
| fixed | No | product ids to keep (locked parts) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only the safety profile (readOnly, non-destructive, openWorld=false), and the description goes well beyond them: LLM-backed execution, anonymized rate limits (6/min, 30/h), deterministic matching, and specific result fields (selected.fixed, fixed_verdict, fixed_fails). This is exactly the extra behavioral context an agent needs and cannot get 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?
Two sentences, front-loaded with the primary action and the fallback/`fixed` path, with no filler. The parenthetical output-field list is dense but earns its place since no output schema exists.
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?
No output schema exists, yet the description names the returned evidence fields, documents the rate limit, and explains determinism and the role of `fixed`. For a 2-parameter LLM-backed assembly tool, nothing an agent needs 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 coverage is 100%, so baseline is 3, but the description adds real meaning: `fixed` ids stay in their subsystems, are validated against stated requirements, and surface as selected.fixed/fixed_verdict/fixed_fails. The example task for `q` also clarifies its acceptable syntax beyond the schema's generic description.
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 ('Assemble a whole spacecraft bus') and the full pipeline: planning, deterministic matching, budget computation, rationale. It also names the sibling tools (match_components, get_datasheet_digest) whose output feeds it, so an agent can place it in the workflow without opening a 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?
Explains the key usage pattern: pass `fixed` with product ids you have already chosen from match_components or get_datasheet_digest, and the rest is assembled around them. That is clear context for the main branch of use, but there is no explicit statement of when NOT to use it (e.g., when to prefer build_budget or find_data_gaps instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What every property of a product category means: definition, how it is measured and what goes into the measurement condition, how to use it when selecting, what it is commonly confused with, typical range and related properties. Call this before interpreting specs of an unfamiliar category.
| Name | Required | Description | Default |
|---|---|---|---|
| subtype | No | optional subtype slug, e.g. cmg, heatpipe, sequencer | |
| category | Yes | category slug, e.g. reaction-wheels, deployers, thermal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It describes what the output contains and positions the tool as a reference lookup, but it does not explicitly state read-only behavior, output format, or potential limitations/errors. It is adequate but not fully transparent.
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 a single dense sentence that front-loads the purpose and then lists concrete content areas. Every clause contributes value, and there is 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?
The description enumerates the return content and gives an explicit call-timing recommendation. Given that there is no output schema, this is sufficient for an agent to understand what it will receive and when to invoke the tool. It stops short of detailing exact response formatting or edge cases.
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 input schema already covers both parameters with descriptive examples (category slug, subtype slug). The description does not add parameter-level meaning, but because schema coverage is 100%, the baseline of 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 clearly states that this tool explains property definitions, measurement, usage, confusions, ranges, and related properties for a product category. It frames its role as a pre-spec reference, though it does not explicitly distinguish itself from sibling tools by name.
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 gives explicit usage guidance: 'Call this before interpreting specs of an unfamiliar category.' It names the context clearly but does not provide exclusions or explicitly compare against alternatives like search_datasheet_facts or get_component_specs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is missing for a product, a company or a category and where to get it: in_digest (already read from the datasheet — value, page), in_datasheet_text (the datasheet mentions it — page, excerpt), not_in_datasheet (ask the vendor), no_datasheet (ask the vendor for a datasheet). For vendors: what to publish; for buyers: what to ask.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| category | No | ||
| company_id | No | ||
| product_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description adds real value by explaining what each result state means (already read, mentioned but unread, absent from datasheet, no datasheet at all) and the recommended action per state. It still doesn't describe the response shape or pagination/limits, keeping it short of 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?
A single dense sentence with parenthetical clarifications; every clause carries information and the enumeration of statuses is front-loaded. The heavy parenthetical nesting slightly taxes readability, but there is 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?
There is no output schema and no annotation-level detail on returns, so the description should do more than explain status values — it omits how results are shaped and how company_id/product_id/category scope the query. Adequate for a read-only lookup tool, but not complete given the 0% schema coverage.
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 0% with 4 parameters, so the description must compensate. It nicely explains the four `status` enum values (in_digest, in_datasheet_text, not_in_datasheet, no_datasheet), but says nothing about the `category` enum, `company_id`, or `product_id`, leaving half the parameters unilluminated.
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 a specific verb-phrase ('find what is missing') and the resources it operates on (product, company, category), framing the tool as a gap analysis over datasheet coverage. It does not explicitly name or contrast any sibling (e.g., get_datasheet_digest or search_datasheet_facts), so it is clear but not sibling-differentiating.
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 line 'For vendors: what to publish; for buyers: what to ask' implies audience-driven use, but no explicit when-to-use-this-vs-another-tool guidance or prerequisites are given. Usage context is only weakly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full typed layer of a category — every item with every value (number, canonical unit, bound, measurement condition, datasheet source page, confidence L0/L1) plus the property dictionary grouped by interface port (perf/power/data/mech/thermal/env/supply) — for arbitrary comparison, budgeting or trade studies on your side.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | component class (default reaction-wheels) | |
| confidence | No | pass L1 to get only human-verified rows |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds meaningful behavioral context by enumerating exactly what data is included and how it is grouped, which helps the agent set expectations about the returned content.
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 a single dense sentence with multiple parenthetical enumerations. It is information-rich but reads as a run-on, and the long list of interface ports could be more scannable. The core purpose is front-loaded, which helps, but the structure is not as clean as it could be.
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 only two optional parameters and no output schema, the description must explain what the tool returns, and it does so thoroughly: full data details and property dictionary grouping by port. It covers likely use cases and value granularity. Minor omissions like pagination or response format are not critical for a read-only spec retrieval 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 input schema fully documents both parameters, category and confidence, including enums, defaults, and short descriptions (100% schema coverage). The description does not add parameter-level syntax or behavior beyond what the schema already provides, so the baseline score of 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 clearly states what the tool returns: the full typed data layer for a component category, including every item, value, unit, bound, measurement condition, datasheet source page, and confidence. It conveys a read/retrieval purpose with strong specificity. However, it does not explicitly distinguish itself from sibling tools like build_budget or match_components.
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 phrase 'for arbitrary comparison, budgeting or trade studies on your side' gives an implied usage context: call this when raw, complete data is needed for the user's own analysis. It does not explicitly state when to prefer siblings or when not to use this tool, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Facts machine-read from a product datasheet, by section (identity, performance, electrical, interfaces, mechanical, thermal, environmental, qualification, lifetime, options, compliance, commercial). Each fact carries unit, condition, the page and a verbatim quote it was verified against (confidence L0) plus a link into the PDF. Use it for what the typed layer does not hold: connectors, protocols, survival temperature, vibration, radiation, heritage, options, export control, lead time. Pass product_id from match_components or a product name.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | product name if no id | |
| product_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds useful behavioral context (confidence L0, verbatim quote verification, PDF link per fact), but doesn't state result limits, pagination, or what happens when a section is absent.
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 what the tool returns and its section taxonomy, then verification semantics, then usage and param routing. The section list is long but each item is informative; only slight trimming possible.
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 does the work of describing the returned fact shape (unit, condition, page, verbatim quote, confidence, PDF link), which is valuable. It also names where product_id comes from. The main gap is not distinguishing itself from sibling tools like get_component_specs.
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 50% (only the 'q' param is described in schema). The description adds meaning by saying product_id can come from match_components or a product name, which compensates for the undocumented product_id. Baseline 3 given the mixed coverage.
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 ('Facts machine-read from a product datasheet, by section') and enumerates the sections covered, so an agent knows this retrieves structured datasheet extractions. It doesn't explicitly contrast with the sibling get_component_specs or search_datasheet_facts, which is the missing sibling differentiation.
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 partial usage guidance: 'Use it for what the typed layer does not hold' and 'Pass product_id from match_components', which implies a workflow. But it never states when to prefer this over ask_datasheet or get_component_specs, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse search over a typed spec layer: pass a category and engineering requirements, get every catalogued item grouped as A (meets all stated requirements), B (fails a named requirement, both figures quoted) or C (could fit, data missing). Verdicts cite the datasheet page. Omit parameters you do not care about. Categories: reaction-wheels, star-trackers, obc-computers, batteries, radios, solar-panels, propulsion, sun-sensors, magnetometers, magnetorquers, imus-gyros, gnss-receivers, eps, deployers, thermal, antennas, sdr-modems, cameras, structures, ground-stations, sadm, tanks-valves, separation-systems, pointing-mechanisms.
| Name | Required | Description | Default |
|---|---|---|---|
| band | No | radio: frequency band UHF|VHF|S|X|L|C|Ku|Ka | |
| bus_v | No | your power bus voltage, V — the unit must accept it | |
| media | No | tank/valve: propellant/media, e.g. xenon, hydrazine | |
| export | No | required export status: ITAR-free | EAR99 | ITAR | |
| form_u | No | structure: CubeSat form factor, U | |
| acq_max | No | star trackers: max lost-in-space acquisition time, s | |
| arw_max | No | IMU: worst angle random walk, deg per sqrt hour | |
| data_if | No | required data interface: CAN, RS-422, RS-485, SpaceWire, I2C, SPI, UART, MIL-STD-1553 | |
| mpx_min | No | camera: min sensor resolution, Mpx | |
| ram_min | No | OBC: min RAM, MB | |
| tid_min | No | any category: min radiation tolerance TID, krad | |
| category | No | which component class to search (default reaction-wheels) | |
| lead_max | No | max lead time, months | |
| mass_max | No | max unit mass, grams | |
| material | No | structure: alloy, e.g. Al 7075 | |
| ttff_max | No | GNSS: worst cold TTFF, s | |
| bands_min | No | camera: min spectral bands | |
| clock_min | No | OBC: min CPU clock, MHz | |
| gsd_max_m | No | camera: worst ground sample distance, m | |
| isp_min_s | No | propulsion: min specific impulse, s | |
| power_max | No | max steady-state power, W (peak/regenerative not counted) | |
| prop_type | No | propulsion: electric | chemical | cold-gas | water | |
| cycles_min | No | battery: min cycle life | |
| dish_min_m | No | ground station: min antenna diameter, m | |
| gt_min_dbk | No | ground station: min G/T, dB/K | |
| sunacc_max | No | sun sensor: worst acceptable accuracy, deg | |
| torque_min | No | wheels: min torque, mN*m | |
| update_min | No | star trackers: min update rate, Hz | |
| mag_res_max | No | magnetometer: worst resolution, nT | |
| pos_acc_max | No | GNSS: worst position accuracy, m | |
| res_max_deg | No | pointing: max angular resolution, deg | |
| shock_max_g | No | separation: max release shock, g | |
| slip_min_ch | No | SADM: min slip-ring channels | |
| storage_min | No | OBC: min storage, GB | |
| txpow_min_w | No | radio: min TX RF power, W | |
| accuracy_max | No | star trackers: worst acceptable cross-boresight accuracy, arcsec | |
| beam_max_deg | No | antenna: max beamwidth, deg | |
| channels_min | No | GNSS: min channels | |
| eirp_min_dbw | No | ground station: min EIRP, dBW | |
| gain_min_dbi | No | antenna: min gain, dBi | |
| meop_min_bar | No | tank/valve: min operating pressure, bar | |
| momentum_min | No | wheels: min angular momentum storage, N*m*s | |
| outpow_min_w | No | EPS: min total output power, W | |
| polarization | No | antenna: RHCP|LHCP|linear|circular | |
| ptrans_min_w | No | SADM: min power transfer, W | |
| range_min_ut | No | magnetometer: min field range, uT | |
| sun_excl_max | No | star trackers: max acceptable sun exclusion angle, deg | |
| swath_min_km | No | camera: min swath width, km | |
| volume_min_l | No | tank/valve: min volume, L | |
| bias_max_degh | No | IMU: worst bias instability, deg/h | |
| constellation | No | GNSS: required constellation GPS|Galileo|GLONASS|BeiDou | |
| paymass_min_g | No | deployer: min payload mass capability, g | |
| price_max_eur | No | max indicative price, EUR (few vendors publish it — expect group C) | |
| range_min_deg | No | pointing: min travel range, deg | |
| rate_min_kbps | No | radio: min data rate, kbps | |
| thrust_min_mn | No | propulsion: min thrust, mN | |
| capacity_min_u | No | deployer: min capacity, U (your satellite size) | |
| dipole_min_am2 | No | magnetorquer: min dipole moment, A*m2 | |
| impulse_min_ns | No | propulsion: min total impulse, N*s | |
| preload_min_kn | No | separation: min preload/holding force, kN | |
| reltime_max_ms | No | separation: max release time, ms | |
| capacity_min_wh | No | battery: min capacity, Wh | |
| panel_power_min_w | No | solar panel: min BOL output, W | |
| conductance_min_wk | No | thermal strap: min conductance, W/K | |
| gyro_range_min_dps | No | IMU: min gyro range, deg/s |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only establish the safety profile (read-only, idempotent, non-destructive), and the description adds substantial behavior beyond that: the A/B/C grading semantics, that B verdicts quote both the requirement and the failing figure, that verdicts cite a datasheet page, and that group C exists because data is missing. That is exactly the interpretive context needed to read the results correctly.
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 core is front-loaded and tight, but the final clause reprints all 24 category values that are already enumerated in the schema's category enum — a long duplicated list with no added meaning. The duplicated enumeration roughly doubles the length for no informational gain.
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 explains the return shape (A/B/C grouping, quoted figures, datasheet page citations), which is the critical missing structure. It does not describe the individual fields carried on each returned item (price, mass, lead time, etc.), a minor residual gap given full input-schema coverage.
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 baseline is 3 and the schema already carries per-parameter meaning. The description adds one piece the schema cannot express: omitted filters are ignored rather than required, plus it frames the whole parameter set as 'engineering requirements' being matched. It does not clarify category-parameter compatibility beyond what the per-property text says.
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 precise, unusual function — reverse search over a catalogued component database, matching an engineering requirement vector and returning items graded A/B/C with datasheet citations. The 'reverse search' framing inherently separates it from retrieval siblings like get_component_specs and search_datasheet_facts, which look up a known item or fact rather than match requirements to a catalog. An agent can tell what this does and how it differs from the rest of the family 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?
Gives real invocation guidance — 'omit parameters you do not care about', i.e. unspecified requirements are not treated as must-meet — and enumerates the categories that are valid targets. It stops short of naming an explicit alternative (e.g. get_component_specs when you already know the part) or a when-not-to-use condition, so it is clear context without explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One fact key across a whole category: which products state it in their datasheets and what value — e.g. connector, data_interface, protocol, survival_temperature, tid_tolerance, flight_heritage, trl, export_control, lead_time, price, design_life. One row per product with page and quote. Reports coverage (how many products of the category have a digested datasheet).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| category | Yes | ||
| contains | No | keep only values containing this text |
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 then adds real behavioral value beyond that: one row per product with page and quote, plus a coverage report of how many products in the category have a digested datasheet. Auth and rate-limit behavior remain unstated.
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 purpose and scope are front-loaded in the first clause, followed by the concrete key examples and the return shape. The key list is long but earns its place because it documents an otherwise-undescribed parameter; no filler sentences.
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-format burden and does so by specifying row-per-product with page and quote plus a coverage count. For a 3-parameter, single-category read tool this is nearly complete; only when-to-use guidance and auth requirements are absent.
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?
Only one of three parameters has schema coverage (33%), and the undocumented 'key' parameter is the important one. The description compensates well by enumerating example keys (connector, survival_temperature, trl, export_control, price...), effectively documenting the vocabulary the 'key' field accepts. The 'contains' filter is described in the schema itself.
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: pulling one fact key across an entire product category, and it gives a concrete list of example keys (connector, data_interface, protocol, etc.), so an agent knows exactly what query this serves. It does not explicitly differentiate itself from siblings like get_datasheet_digest or ask_datasheet, which keeps it 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 only implied by the shape of the result ('one fact key across a whole category'); there is no statement of when to pick this over ask_datasheet or get_datasheet_digest, and no exclusions or prerequisites. The agent must infer the trigger condition from the description alone.
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.
explain_propertiescheck_fitdesign_stackask_datasheetfind_data_gapsget_datasheet_digestmatch_components2 fields changedInput schema / properties / exportAdded value: +{
+ "description": "required export status: ITAR-free | EAR99 | ITAR",
+ "type": "string"
+}Input schema / properties / price_max_eurAdded value: +{
+ "description": "max indicative price, EUR (few vendors publish it — expect group C)",
+ "type": "number"
+}search_datasheet_factsbuild_budgetget_component_specsmatch_componentsSearch real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Electronic component datasheets for AI agents — specs, pinouts, package data on demand.
SpecProof: Search standards specs with MCP-ready precision.
IC datasheet search: parametric part finding, spec lookup, price comparison — grounded in real PDFs.
Add one secure layer between your agents and this server.
