Simulate electric UAV powertrains and search a public motor, propeller and battery database.
Scored across 7 tools
Each tool has a clearly distinct role: search_components vs get_component (find vs read-one), estimate_propeller (single prop closed-form) vs simulate_powertrain (whole powertrain operating point) vs sweep_powertrain (range), plus get_result and get_validation_summary for retrieval/accuracy. The overlapping-sounding propeller tools are distinguished by scope and model in their descriptions.
All seven tools follow a predictable snake_case verb_noun pattern (estimate_propeller, get_component, get_result, get_validation_summary, search_components, simulate_powertrain, sweep_powertrain). The get_/search_/simulate_/sweep_ prefixes are used consistently.
Seven tools is well-scoped for a propulsion simulation service, covering estimation, simulation, sweep, component lookup, result retrieval and validation without redundancy or bloat. Each tool earns its place.
The surface covers the core lifecycle: find components, read one, estimate, simulate, sweep, retrieve results, and check model accuracy. Minor gaps exist (e.g. no direct comparison of multiple setups or component-creation tools), but core agent workflows are covered.
Thrust, torque and shaft power for one propeller, from its printed size.
A closed-form momentum plus blade-element equation — no motor, no battery,
no account. Give the size as it is printed: a 10x5 is `diameter_in=10`,
`pitch_in=5`. `chord_ratio` is the chord at 75 % radius over the diameter:
0.065 thin electric, 0.07 sport, 0.10 slow flyer, 0.11 multirotor.
| Name | Required | Description | Default |
|---|---|---|---|
| rpm | Yes | ||
| blades | No | ||
| pitch_in | Yes | ||
| altitude_m | No | ||
| camber_pct | No | ||
| chord_ratio | No | ||
| diameter_in | Yes | ||
| airspeed_m_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the bar is lower. The description usefully adds that the result comes from a closed-form momentum plus blade-element model and requires no account or external service, telling the agent the output is deterministic and offline. It does not cover accuracy limits or validity ranges of the model, which would have pushed it to 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?
Three short paragraphs, zero filler, and the output/scope statement is front-loaded before the input conventions. Every sentence 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?
An output schema exists, so return values need no explanation, and the description fully covers what the tool is and the two most ambiguous inputs. The gap is that a majority of parameters, including the required rpm and the default-zero altitude_m and airspeed_m_s that govern the model's operating point, are left undocumented.
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% across 8 parameters, so the description carries the full burden. It does well for two: the 10x5 -> diameter_in/pitch_in example clarifies the printed-size convention, and chord_ratio gets a definition plus four concrete recommended values. The other six (rpm, blades, altitude_m, camber_pct, airspeed_m_s) are never mentioned, leaving the required rpm and the static-vs-forward-flight meaning of airspeed_m_s entirely to inference.
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?
Specific verb-and-resource statement ('Thrust, torque and shaft power for one propeller, from its printed size') that names the exact outputs. The 'no motor, no battery, no account' clause explicitly separates it from the powertrain simulation siblings, so an agent can route 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?
Gives clear selection context by excluding motor/battery/powertrain cases, which implicitly routes the agent to simulate_powertrain or sweep_powertrain for those. It does not name the alternative explicitly or state a positive 'use this when...' condition, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one database row by its id (comp_…), with provenance.
Propeller rows give diameter, pitch, blade count, weight and maximum rpm.
Blade station geometry is never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| component_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the description is not carrying the safety burden. It still adds real behavioral context beyond the annotations: this returns provenance data and propeller-specific attributes, and it explicitly states that blade station geometry is never returned, which head-offs a predictable follow-up query.
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-loaded with the core action, then two short supporting sentences, one of which covers return payload and one the hard exclusion. No filler; 'with provenance' is the only mildly opaque phrase and it is clarified by the sentence that follows.
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?
An output schema exists, so return values need not be enumerated, yet the description usefully characterizes the propeller row contents and the deliberate omission of blade station geometry. For a single-parameter read tool, an agent has nearly 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 0% for the single parameter, so the description must compensate, and it does: it discloses the id format and prefix ('comp_…'). That is concrete value the schema does not provide, though it stops short of saying whether a bare or prefixed id is accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read one database row by its id') and scopes it to a single entity, which implicitly separates it from the sibling search_components list operation. It does not name any sibling tool explicitly, so the differentiation is inferable rather than stated.
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 requirement of an id ('by its id') implies when to reach for this tool versus a search, but there is no explicit when-to-use/when-not statement and no alternative is named. The note about blade station geometry being withheld is a boundary on output rather than on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a stored result: a share token from a run, or a simulation_id.
`simulation_id` needs a ThrustLab API key in `Authorization: Bearer` and
reads only that account's own runs.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| simulation_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond them: the authentication requirement (`Authorization: Bearer` API key) and the account scoping limitation ('reads only that account's own runs') for the simulation_id path.
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 short sentences, front-loaded with the core action and the branch distinction, with the auth caveat attached to the branch it applies to. No wasted prose, though the line-break fragmentation adds no value.
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?
An output schema exists, so return values need not be described. With annotations covering the safety profile and the description covering auth and account scoping, the definition is nearly complete; the only real gap is the unresolved question of parameter mutual exclusivity given zero required params.
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%, so the description carries the burden and does explain what each of the two parameters means. However, it omits mutual-exclusivity/requirement semantics, and with 0 required parameters it never clarifies whether one of them must be supplied or what happens if both (or neither) are given.
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 verb and resource ('Read a stored result') and enumerates the two retrieval modes (share token vs. simulation_id). It is unambiguous against siblings like get_component or get_validation_summary, though it does not explicitly contrast itself with any of them.
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 clear selection rule between the two access paths: use a share `token` for a run's public result, or `simulation_id` for your own account's runs, which additionally requires a ThrustLab API key. It does not state when to prefer this tool over the sibling read tools, but the in-tool branch guidance is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How accurate a model is, measured against wind-tunnel and bench data.
`model` is "fast", "full", or an exact report slug such as "prom-5.3". The
numbers are error against measured data by partition and channel, with the
envelope they were measured inside. Quote the model name with the number.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | full |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered without description help. The description adds genuinely new behavioral context about the payload (error against measured data by partition and channel, with measurement envelope) and the 'quote the model name with the number' instruction, but says nothing about caching, freshness, or cost.
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-loaded and short, which is good, but the closing sentence 'Quote the model name with the number.' is cryptic — it is unclear whether it addresses formatting the request or citing the response, which costs clarity without clearly earning 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?
The description covers the parameter well and an output schema exists so return values need not be explained, but for a zero-usage-guidance tool among six siblings it does not say when this summary is the right call versus running a simulation or fetching a result.
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% and the single parameter has no description, so the description must carry the load — and it does, enumerating 'fast', 'full', and an exact report slug like 'prom-5.3'. It also notes the default-adjacent 'full' option implicitly, though it doesn't state which is the default or what 'fast' versus 'full' costs.
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 clear resource and scope: model accuracy measured against wind-tunnel and bench data, broken down by partition and channel. It is specific enough that an agent can distinguish it from simulate_powertrain or get_result, though it never names a sibling verbatim.
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 reach for this tool versus the sibling tools such as get_result or the simulation tools. The only guidance given concerns the valid values of `model`, which is parameter semantics rather than when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find motors, propellers or batteries in the ThrustLab database.
component_type is "motor", "propeller" or "battery". query is a
case-insensitive substring of the part name or its maker ("APC", "T-Motor",
"13x6.5"). The maker sits under spec.brand for motors and batteries and under
spec.type for propellers. limit is capped at 200 rows a
page; when has_more is true, pass the returned next_offset as offset to
read the next page. Each row carries its datasheet values, its source and the
CC BY 4.0 attribution line. Pass a returned id to
simulate_powertrain.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No | ||
| sort_by | No | name | |
| sort_order | No | asc | |
| component_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world behavior, so the description's added value is the pagination contract (limit capped at 200 rows/page, has_more/next_offset loop) and row payload (datasheet values, source, CC BY 4.0 attribution) — genuinely useful context beyond the annotations. It stops short of noting rate limits or query cost.
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?
Dense and front-loaded: purpose first, then the two most-used parameters, then pagination, then follow-up routing. Every sentence carries information; nothing restates the name or 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?
Given an output schema exists and annotations cover the safety profile, the description supplies everything needed to call correctly except sort_by/sort_order semantics. For a 6-param, 0%-coverage tool that is nearly complete.
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?
With 0% schema description coverage the description must carry the load, and it does for most params: component_type enum values, query as a case-insensitive substring of part name or maker, where the maker lives (spec.brand vs spec.type), and the limit/offset relationship. sort_by and sort_order remain undocumented in both schema and 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?
Starts with a specific verb+resource ('Find motors, propellers or batteries in the ThrustLab database') and implicitly distinguishes itself from sibling get_component, which fetches a single item by id. An agent can tell search from retrieval 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?
Explicitly routes the agent onward: pass a returned id to simulate_powertrain, and loop with next_offset while has_more is true. It never states when to prefer get_component over this search, so the retrieval-vs-search boundary is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve one operating point of a whole powertrain on the Fast model.
Battery, ESC, motor and propeller are solved together, so the answer is a
real thrust and current, not a propeller curve. The numbers come back in
`result` (`result.All` = system totals in SI units: thrust N, current A,
power W, time s; one entry per rotor; `result.Battery`), with a share URL.
No second call is needed to read them.
| Name | Required | Description | Default |
|---|---|---|---|
| powertrain | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly false, destructive false, non-idempotent), so the bar is lower. The description adds real behavioral context: the battery/ESC/motor/propeller are solved together so the output is a coupled thrust and current rather than a propeller curve, and a share URL is produced, which is consistent with the non-read-only, non-idempotent hints.
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?
Purpose is front-loaded in the first sentence, and the two paragraphs stay tight with no filler. The parenthetical unit dump is dense but earns its place by defining the output fields.
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 an output schema present the description need not explain returns, yet it sensibly names result.All and result.Battery and their units. Given a single nested input parameter it is close to complete, though it omits any guidance on the catalog-id vs label input paths that materially change a call.
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 reported as 0%, so the description must carry input meaning, yet it says nothing about motor_id, battery_id, throttle, altitude, or the propeller_id vs propeller_label choice. It only characterizes the return payload, leaving the only input ('powertrain') semantically unexplained in the 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 (solve) and resource (one operating point of a whole powertrain) on a named model, and the single-operating-point scope implicitly contrasts with the sweep sibling. An agent can tell what it computes 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 clear context ('solve one operating point', 'Fast model') and explicitly forecloses a follow-up read call ('No second call is needed to read them'), which routes away from get_result. It never names sweep_powertrain or the catalog-vs-label input choice as an alternative, so it stops short of explicit when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve a powertrain across a throttle or airspeed range, up to 25 points.
`sweep.steps` is the NUMBER OF POINTS, not a step size: start 40, stop 100,
steps 4 gives 40, 60, 80 and 100. One sweep beats a loop of single points.
The points come back in `result.points` with the share URL; no second call
is needed to read them.
| Name | Required | Description | Default |
|---|---|---|---|
| sweep | Yes | ||
| powertrain | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is not read-only, not destructive, not idempotent, and closed-world. The description adds useful behavioral context: the result comes back in result.points with a share URL, so no second call is needed to read the points.
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 range, then immediately addresses the steps ambiguity with a worked example. Every sentence earns its place, 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?
Given the nested schemas and the presence of an output schema, the description provides exactly the extra clarification an agent needs: the range limit, the steps-as-points semantics, and the fact that the result is returned directly. Safety behavior is covered by annotations.
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 top-level schema properties have no descriptions, so the description carries extra burden. It clarifies the most error-prone parameter with a concrete example: sweep.steps is the number of points, not a step size, and start 40, stop 100, steps 4 yields 40, 60, 80, 100.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: solve/sweep a powertrain across a throttle or airspeed range. It also distinguishes itself from a loop of single-point simulations, which is the key alternative an agent would otherwise choose.
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?
Clearly recommends using one sweep instead of a loop of single points, giving context for when this tool is appropriate. It does not explicitly name the simulate_powertrain sibling as the alternative, so the routing guidance is strong but not exhaustive.
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.
estimate_propellerget_componentget_resultget_validation_summarysearch_componentssimulate_powertrainsweep_powertrainReal BEM engineering for propellers, wings and turbines — design, optimize, visualize, export.
Design, solve and simulate HVAC systems from real components, weather years and buildings.
Search real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Spacecraft component specs from vendor datasheets: search, digests, facts, gaps, budgets, bus design
Add one secure layer between your agents and this server.
