Price comparison for Microsoft Flight Simulator add-ons: search, deals, per-store prices, history.
Scored across 12 tools
Most tools have distinct targets, but several overlap: fetch and get_addon both retrieve a single add-on, search and search_addons both search the catalog, and compare_prices/get_addon both expose store offers. Descriptions help somewhat, but an agent could easily call the wrong one.
The majority follow a verb_noun pattern (compare_prices, find_aircraft_type, list_stores, search_addons), and list_* tools are clearly grouped. Minor deviations like fetch and price_history break the pattern but are still readable.
With 12 tools, the server is well-scoped for an add-on catalog: search, listing, price comparison, history, and store/developer queries each have a place. The count feels appropriate and not bloated.
The surface covers core catalog workflows: searching, retrieving add-ons, comparing prices, checking history, finding deals, and filtering by aircraft/airport. Minor gaps remain, such as no direct way to list add-ons for a developer after using list_developers, but most workflows can be completed.
Every store offer for one add-on, in-stock offers with known net prices first, ordered by net EUR price. Includes the listed price, tax status, known net price, EUR conversion, stock, sale expiry and an outbound link.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| slug | Yes | |
| as_of | Yes | |
| count | Yes | |
| title | Yes | |
| offers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent, and the description adds genuinely useful behavior: in-stock offers with known net prices are prioritized and results are ordered by net EUR price. It also enumerates returned attributes, including the outbound link, going beyond the minimal safety profile.
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 front-loaded sentence that states the core scope, ordering, and the full set of included data points. Every phrase earns its place and there is no fluff or repetition.
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 single-add-on comparison tool, the description covers the essential behavioral rules: what is included, what is prioritized, and how results are ordered. The output schema covers return structure, and annotations cover safety, so the main remaining gap is the undocumented slug semantics.
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 only parameter, 'slug', has no schema description, and the tool description never explicitly states that slug identifies the add-on. The phrase 'one add-on' hints at the resource, but the mapping from parameter to meaning is left implicit, which is risky for an agent.
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 ('one add-on') and output scope ('every store offer'), and it specifies sorting behavior and included fields. It doesn't explicitly contrast with sibling tools like price_history or get_addon, but the single-add-on scope makes its purpose identifiable.
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 one add-on' implies when to use the tool, but the description gives no explicit guidance about when not to use it or which sibling tool to prefer in other scenarios. It leaves the choice between compare_prices, price_history, and list_deals to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one add-on as a document, by the id returned from search (the add-on slug). Returns the full description plus every current store price.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description need not repeat those. It adds useful context about the return payload (full description and store prices) but does not disclose additional behavioral traits such as error handling, rate limits, or authentication requirements. This adds some value beyond annotations but not extensive behavioral detail.
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 states the action, the key prerequisite, and the return value without any filler or redundant information. Every clause earns its place, making it easy for an agent to parse quickly.
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 tool's simplicity (one required parameter, no nested objects), a valid output schema, and robust annotations, the description is complete. It tells the agent what input to provide, where to get it, and what the tool returns. No critical calling information is missing for correct invocation.
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 provides no description for the required 'id' parameter (schema coverage 0%), so the description carries the full burden. It explicitly explains that the id is the add-on slug returned from 'search', giving the agent the origin and format of the value. This fully compensates for the missing schema detail and leaves no ambiguity about the parameter's meaning.
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 ('Retrieve'), a resource ('one add-on'), and the source of the identifier ('the id returned from search'). It also specifies the return content ('full description plus every current store price'). However, it does not explicitly distinguish itself from the sibling tool 'get_addon', which may perform a similar retrieval, so it falls short of full 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?
Provides clear contextual guidance by instructing that the id comes from the search tool, implying a search-then-fetch workflow. However, it does not mention when to use this tool instead of alternatives like get_addon or search_addons, nor does it state any exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a plain-language aircraft name ("737 MAX", "Cessna 172", "A320neo") to its ICAO Doc 8643 designator, with how many add-ons we carry for it. Feed the designator to list_addons_for_aircraft.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Designator, model, family or manufacturer | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| count | Yes | |
| types | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, so the description does not need to cover safety. It adds useful detail about the kind of input accepted, that the result includes an add-on count, and that the designator can be fed to a sibling tool. It doesn't describe ambiguous-match behavior, but it still contributes meaningful context 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?
Two short sentences carry all the key information, with the lookup behavior front-loaded and the downstream usage in the second sentence. No filler or restatement.
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 tool's simplicity, the strong annotations, the presence of an output schema, and the explicit downstream routing, the description is complete enough for an agent to select and invoke the tool correctly. The only minor gaps are ambiguity and limit behavior, which are largely covered by the schema and output schema.
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 only 50%: q is documented but limit is not. The description adds examples and a purpose for q beyond the schema, but it does not explain limit's effect on result size, so it only partially compensates for the missing schema documentation.
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 ('Resolve') and resource (plain-language aircraft name to ICAO Doc 8643 designator), and it distinguishes itself from sibling list_addons_for_aircraft by framing it as the upstream lookup. The examples sharpen the scope.
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 gives clear context: use this when you have a plain-language aircraft name, and it explicitly routes the result to list_addons_for_aircraft. It does not spell out exclusions such as skipping this tool when the caller already has the ICAO designator, so it falls just short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything the catalog holds on a single add-on: description, developer, declared simulator compatibility, rating, every store offer with its VAT split and sale expiry, the lowest price ever recorded, and the real-world aircraft types and airports it implements.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Add-on slug, as it appears in https://fsaircraft.net/addons/{slug} |
| Name | Required | Description |
|---|---|---|
| addon | Yes | |
| as_of | Yes | |
| found | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds concrete detail about response contents, including VAT splits, sale expiry, lowest recorded price, and implemented aircraft/airports. No side effects are claimed or omitted that would contradict 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?
One dense, structured sentence that front-loads the tool's scope and then provides a colon-separated list of return categories. Every item earns its place, and there is no redundant or filler text.
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 one-parameter, read-only catalog lookup with an output schema, annotations, and full schema parameter coverage, the description gives an agent everything needed to select and invoke it correctly. The return content is enumerated, and no error or pagination context is required at this complexity.
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 description covers 100% of the single parameter, so the baseline is 3. The description only reiterates 'single add-on' and does not add slug format or lookup behavior beyond what the schema already documents.
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 title supplies the verb-resource pair 'Get one add-on', and the description specifies the exact scope: a single add-on's full catalog record. The enumerated contents (store offers, VAT split, sale expiry, lowest price, aircraft/airports) make it clearly distinct from sibling list and search tools.
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 clearly frames this as the tool for retrieving all catalog data for a single known add-on, implying use when the agent already has a slug and wants full detail rather than a search or list result. It does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every add-on implementing one real-world aircraft type, across all studios, cheapest first. The type link is our own classification (from the title and the store metadata), not the store's.
| Name | Required | Description | Default |
|---|---|---|---|
| sim | No | ||
| limit | No | ||
| icao_designator | Yes | ICAO Doc 8643 designator, e.g. 'B738', 'A20N', 'C172' |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| as_of | Yes | |
| count | Yes | |
| results | Yes | |
| icao_designator | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so safety is covered. The description adds meaningful behavior beyond that: results are ordered cheapest first, span all studios, and use a self-defined aircraft-type classification rather than the store's classification.
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, tight sentence that front-loads the core scope and ordering behavior. The classification caveat is useful and does not add noise.
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 listing tool with an output schema and safe annotations, the description covers the essential context: what is returned, the scope, and the ordering. The required parameter is documented in the schema, and optional parameters have clear defaults and enums.
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 only 33%, and the description provides almost no parameter-level guidance. It slightly clarifies what 'aircraft type' means, which relates to icao_designator, but it does not compensate for the undocumented sim and limit parameters.
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 action and resource: listing every add-on for a real-world aircraft type across all studios. It also adds scope ('cheapest first') and a classification caveat, which helps distinguish it from generic search tools, though it does not explicitly name a sibling.
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 usage context: use this when you want a comprehensive, price-sorted list of add-ons for a given aircraft type. It does not explicitly compare against alternatives such as search_addons or get_addon, but the scope statement ('Every add-on', 'across all studios', 'cheapest first') makes the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add-ons discounted right now, deepest discount first. A discount here means the current price is below the highest price we have ever recorded for that same offer at that same store — never a store-printed list price, so permanent markdowns do not appear.
| Name | Required | Description | Default |
|---|---|---|---|
| sim | No | ||
| limit | No | ||
| category | No | ||
| ending_within_days | No | Only sales with a published end date inside N days |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| count | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the read-only and idempotent annotations: it defines exactly what counts as a discount, states the sort order, and explains why permanent markdowns are excluded. This meaningfully helps an agent interpret results.
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 wasted words. The core function and sort order are front-loaded, and the important definitional clarification follows naturally.
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 tool is simple, read-only, and has an output schema, so the description covers the core deal semantics well. However, the lack of guidance for the undocumented category parameter and how limit/sort combine leaves an agent with some ambiguity when invoking the tool with filters.
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 only 25%, with only ending_within_days described. The description does not explain sim, limit, or category parameters, nor does it clarify what values category accepts or how the filter interacts with the sort. The discount definition is useful domain context but not parameter-level guidance.
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: add-ons currently discounted, sorted by discount depth. It is specific enough to distinguish itself from generic search and price tools, though it does not explicitly name siblings or contrast itself with 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?
The description implies when to use the tool: when the agent needs currently discounted add-ons rather than permanent markdowns. It gives a clear exclusion ('permanent markdowns do not appear') but does not mention alternative tools or provide explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add-on studios in the catalog, busiest first, optionally filtered by name.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Substring of the developer name | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| count | Yes | |
| developers | Yes |
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 covered. The description adds the behavioral detail of 'busiest first' ordering, which is useful. It does not disclose pagination behavior, default limit, or what happens when no results are found, but with annotations covering the safety profile, a 3 is appropriate.
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 sentence that front-loads the core action ('Add-on studios in the catalog'), then adds the ordering detail ('busiest first') and the optional filter. Every word earns its place; no fluff or repetition.
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 simple list tool with 2 optional parameters, an output schema, and annotations covering safety, the description is nearly complete. It explains the resource, ordering, and filtering. The only minor gap is not explicitly stating the default limit or pagination behavior, but the schema's default value and output schema likely cover the return shape. Given the low complexity, this is complete enough.
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 50%: the 'q' parameter has a description ('Substring of the developer name'), but 'limit' has no description beyond its schema constraints. The description's 'optionally filtered by name' maps to 'q', adding slight context. With 50% coverage, the description partially compensates but doesn't fully explain the limit parameter's semantics (e.g., it's the max number of results returned). 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 ('List') and resource ('developers' / add-on studios), and adds a distinguishing detail: 'busiest first, optionally filtered by name.' This clearly identifies what the tool does. It doesn't explicitly differentiate from siblings like list_addons_for_aircraft or search_addons, but the resource is distinct enough that an agent can tell it apart.
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 implies usage context: it lists add-on studios in the catalog, sorted by busiest first, with optional name filtering. It does not explicitly state when to use this tool versus alternatives like search or list_addons_for_aircraft, nor does it mention exclusions. The 'optionally filtered by name' hints at the q parameter, but there is no explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every add-on scenery we carry for one airport, by ICAO (or IATA) code, cheapest first.
| Name | Required | Description | Default |
|---|---|---|---|
| sim | No | ||
| icao | Yes | ICAO code, e.g. 'EGLL', 'KJFK'. IATA also accepted. | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| icao | Yes | |
| as_of | Yes | |
| count | Yes | |
| airport | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent behavior, so the description only needs to add traits beyond that; it usefully adds 'cheapest first' ordering and a comprehensiveness claim. However, 'Every ... we carry' conflicts in spirit with the schema's `limit` (default 25, max 50), and no pagination/truncation behavior is disclosed.
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 with no filler, front-loading the resource and scope before the ordering detail. Every phrase 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?
With an output schema and safety annotations present, the description provides enough to invoke the tool with the required `icao`. It is slightly incomplete because it doesn't clarify the `sim`/`limit` semantics or explicitly separate this from the sibling list tool, but nothing essential is missing for a basic 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 only 33%, and the description compensates only for `icao` by restating that IATA is accepted—which the schema already documented. It adds no meaning for `sim` or `limit`, leaving those parameters to be inferred from names/types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource—add-on scenery for one airport—and adds ordering ('cheapest first'), so the tool's function is unmistakable. It does not explicitly name a sibling alternative, so the differentiation from list_addons_for_aircraft must be inferred from the 'airport' scope 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 phrase 'for one airport, by ICAO (or IATA) code' clearly identifies the intended call pattern: a single-airport lookup by code. It provides no explicit 'when not to use' guidance or alternative tool names, but the context is strong enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every storefront in the catalog, with how many add-ons we track there, how many are discounted right now, and whether its prices include VAT. Use it to answer "which stores do you actually cover" and to get the store slug vocabulary for search_addons.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| count | Yes | |
| stores | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds meaningful behavioral context beyond annotations by describing the output contents (tracked add-on counts, current discounts, VAT inclusion). It does not mention ordering or pagination, but the existence of an output schema reduces the need for that detail.
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, front-loaded with the core output and purpose, with no filler. Every clause contributes to understanding what the tool does and when to use it.
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 zero-parameter, read-only list tool with an output schema and strong annotations, the description is complete. It tells the agent what data is returned, why to call it, and how it supports search_addons. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the schema to document. The description adds value by hinting at the 'store' slug vocabulary used by search_addons, giving the agent a sense of the identifier format even without a parameter. Baseline 4 is appropriate here.
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 as returning 'every storefront in the catalog' with specific details (add-on counts, discounts, VAT). It also names concrete use cases ('which stores do you actually cover' and getting 'store' slug vocabulary), which distinguishes it from sibling tools that focus on add-ons, deals, or prices.
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 explicitly states when to use the tool: to answer store coverage questions and to obtain the 'store' slug vocabulary for search_addons. While it doesn't explicitly mention alternatives or when not to use it, the purpose is clear enough for an agent to select it for store-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily lowest known VAT-excluded price in EUR, using current exchange rates, plus min/max/current and whether it is at its lowest ever. Answers "has this ever been cheaper than X?".
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| days | Yes | |
| slug | Yes | |
| as_of | Yes | |
| points | Yes | |
| price_basis | Yes | |
| max_eur_cents | Yes | |
| min_eur_cents | Yes | |
| is_lowest_ever | Yes | |
| current_eur_cents | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context: prices are VAT-excluded, in EUR, converted using current exchange rates, and represent 'known' data with a potential completeness limitation. It does not cover edge cases or data freshness, but it 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 two dense sentences with no filler. It front-loads the core output semantics and then gives a concrete use-case question, making every clause valuable.
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 output schema and rich annotations, the description adequately explains the return semantics. However, it leaves a significant gap around the required 'slug' parameter and how 'days' affects the result, so an agent may not know exactly how to invoke the 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?
Schema description coverage is 0%, and the description does not define either parameter. 'slug' is never mentioned, and 'days' is only weakly implied by the word 'Daily'. The description fails to compensate for the schema's lack of parameter documentation.
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 precisely defines the tool's purpose: it returns daily lowest VAT-excluded EUR prices, derived min/max/current values, and whether the price is at its lowest ever. The phrase 'Answers "has this ever been cheaper than X?"' reinforces the intended use. It does not explicitly contrast with sibling tools like compare_prices, but the content is specific enough to distinguish it.
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 sentence 'Answers "has this ever been cheaper than X?"' provides a concrete trigger condition for when to use the tool. It gives clear usage context, though it does not mention exclusions or point to alternatives such as compare_prices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the fsaircraft.net MSFS add-on catalog and return documents in the shape ChatGPT deep-research and company-knowledge connectors expect. id is the add-on slug; pass it to fetch. Prefer search_addons when filters or prices matter.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by explaining the connector-specific return shape and the relationship between `id` and `fetch`.
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 sentences are front-loaded with the core purpose, followed by a useful next-step hint and an explicit alternative. No filler or 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 one-parameter, read-only search with an output schema, the description plus annotations is nearly sufficient. It names the alternative search_addons and points to fetch, though it leaves the exact query semantics 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 0%, and the description does not explain the `query` parameter beyond what the name implies. The `id` note refers to returned documents, not the input, so it does not compensate for the missing parameter documentation.
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 action (search) on a specific resource (the fsaircraft.net MSFT add-on catalog) and describes the output contract (documents shaped for ChatGPT connectors). It also points to the sibling search_addons, so an agent can tell this tool apart from the more filter-oriented search.
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 says to prefer search_addons when filters or prices matter, giving a clear decision rule. It also tells the agent that returned `id` values are add-on slugs to pass to `fetch`, which links to the next step in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the fsaircraft.net catalog of payware Microsoft Flight Simulator add-ons (aircraft, scenery, liveries, utilities) across every tracked store. Returns the cheapest live offer for each add-on with its discount and MSFS 2020/2024 compatibility as declared by the selling store.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free text: title, developer, ICAO code or aircraft type | |
| sim | No | Only add-ons declared compatible with this simulator | |
| limit | No | ||
| store | No | Store slug, e.g. 'simmarket' — see list_stores | |
| on_sale | No | Only add-ons currently below their recorded high | |
| category | No | Category slug, e.g. 'aircraft', 'scenery', 'livery', 'utility' | |
| max_price_eur | No | Inclusive ceiling on the known VAT-excluded price, in euros |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| count | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a read-only, idempotent, non-destructive profile, so the description only needs to add context beyond that. It discloses that results are 'cheapest live offer' with discount and store-declared MSFS compatibility, which are useful behavioral caveats. No contradiction.
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 that front-load the search scope and then explain the return value. Every clause adds information, with no repetition of schema content or 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 seven optional parameters, high schema coverage, an output schema, and safe read-only annotations, the description provides enough context for an agent to call the tool correctly. It covers scope, result meaning, and the compatibility caveat.
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 86%, and parameters like q, sim, limit, store, on_sale, category, and max_price_eur already carry their own descriptions. The main description adds little parameter-level detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: search the fsaircraft.net catalog of payware MSFS add-ons across every tracked store. It also clarifies the result semantics (cheapest live offer, discount, compatibility), which distinguishes it from generic search/list siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: querying the catalog across all tracked stores and surfacing the cheapest live offer. It does not explicitly name alternatives or exclusion conditions, so it stops 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_prices2 fields changedOutput schema / properties / offers / items / properties / tax_statusAdded value: +{
+ "enum": [
+ "included",
+ "excluded",
+ "unknown"
+ ],
+ "type": "string"
+}Output schema / properties / offers / items / requiredPrevious value: -[
- "store",
- "store_slug",
- "price_cents",
- "currency",
- "price_eur_cents",
- "net_price_cents",
- "net_price_eur_cents",
- "vat_percent",
- "in_stock",
- "discount_pct",
- "was_price_cents",
- "sale_ends_at",
- "price_low_30d_cents",
- "last_seen_at",
- "store_url",
- "deep_link"
-]New value: +[
+ "store",
+ "store_slug",
+ "price_cents",
+ "currency",
+ "price_eur_cents",
+ "net_price_cents",
+ "net_price_eur_cents",
+ "vat_percent",
+ "tax_status",
+ "in_stock",
+ "discount_pct",
+ "was_price_cents",
+ "sale_ends_at",
+ "price_low_30d_cents",
+ "last_seen_at",
+ "store_url",
+ "deep_link"
+]get_addon1 field changedOutput schema / properties / addon / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "aircraft_types": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "icao_designator": {
- "type": "string"
- },
- "manufacturer": {
- "type": "string"
- },
- "model": {
- "type": "string"
- }
- },
- "required": [
- "icao_designator",
- "manufacturer",
- "model"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "airports": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "country": {
- "type": [
- "string",
- "null"
- ]
- },
- "icao": {
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "icao",
- "name",
- "country"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "also_listed_as": {
- "description": "Other slugs merged into this add-on by cross-store dedupe",
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "category": {
- "type": [
- "string",
- "null"
- ]
- },
- "currency": {
- "type": [
- "string",
- "null"
- ]
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "developer": {
- "type": [
- "string",
- "null"
- ]
- },
- "discount_pct": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "first_seen_at": {
- "type": "string"
- },
- "image_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "is_lowest_ever": {
- "type": "boolean"
- },
- "net_price_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "VAT-excluded, where the store VAT rate is known"
- },
- "offer_count": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "offers": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "currency": {
- "type": "string"
- },
- "deep_link": {
- "type": "string"
- },
- "discount_pct": {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- "in_stock": {
- "type": "boolean"
- },
- "last_seen_at": {
- "type": "string"
- },
- "net_price_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "net_price_eur_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "VAT-excluded and EUR-converted: the only figure that compares across stores"
- },
- "price_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "price_eur_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "price_low_30d_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "sale_ends_at": {
- "type": [
- "string",
- "null"
- ]
- },
- "store": {
- "type": "string"
- },
- "store_slug": {
- "type": "string"
- },
- "store_url": {
- "type": "string"
- },
- "vat_percent": {
- "type": [
- "number",
- "null"
- ]
- },
- "was_price_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "store",
- "store_slug",
- "price_cents",
- "currency",
- "price_eur_cents",
- "net_price_cents",
- "net_price_eur_cents",
- "vat_percent",
- "in_stock",
- "discount_pct",
- "was_price_cents",
- "sale_ends_at",
- "price_low_30d_cents",
- "last_seen_at",
- "store_url",
- "deep_link"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "price_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Cheapest live offer, minor units of `currency`"
- },
- "price_eur_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "description": "Same price converted to EUR at ECB rates"
- },
- "price_low_all_time_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "rating": {
- "type": [
- "number",
- "null"
- ]
- },
- "rating_count": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- },
- "released_at": {
- "type": [
- "string",
- "null"
- ]
- },
- "sale_ends_at": {
- "type": [
- "string",
- "null"
- ]
- },
- "sims": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "slug": {
- "type": "string"
- },
- "store": {
- "type": [
- "string",
- "null"
- ]
- },
- "summary": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": "string"
- },
- "url": {
- "type": "string"
- },
- "version": {
- "type": [
- "string",
- "null"
- ]
- },
- "was_price_cents": {
- "anyOf": [
- {
- "maximum": 9007199254740991,
- "minimum": -9007199254740991,
- "type": "integer"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "slug",
- "title",
- "developer",
- "category",
- "sims",
- "price_cents",
- "currency",
- "price_eur_cents",
- "net_price_cents",
- "store",
- "discount_pct",
- "was_price_cents",
- "sale_ends_at",
- "offer_count",
- "rating",
- "url",
- "description",
- "summary",
- "version",
- "released_at",
- "rating_count",
- "first_seen_at",
- "image_url",
- "aircraft_types",
- "airports",
- "offers",
- "price_low_all_time_cents",
- "is_lowest_ever",
- "also_listed_as"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "aircraft_types": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "icao_designator": {
+ "type": "string"
+ },
+ "manufacturer": {
+ "type": "string"
+ },
+ "model": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "icao_designator",
+ "manufacturer",
+ "model"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "airports": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "country": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "icao": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "icao",
+ "name",
+ "country"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "also_listed_as": {
+ "description": "Other slugs merged into this add-on by cross-store dedupe",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "currency": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "developer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "discount_pct": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "first_seen_at": {
+ "type": "string"
+ },
+ "image_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "is_lowest_ever": {
+ "type": "boolean"
+ },
+ "net_price_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "VAT-excluded, where the store VAT rate is known"
+ },
+ "net_price_eur_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "offer_count": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "offers": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "type": "string"
+ },
+ "deep_link": {
+ "type": "string"
+ },
+ "discount_pct": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "in_stock": {
+ "type": "boolean"
+ },
+ "last_seen_at": {
+ "type": "string"
+ },
+ "net_price_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "net_price_eur_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "VAT-excluded and EUR-converted: the only figure that compares across stores"
+ },
+ "price_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "price_eur_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "price_low_30d_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "sale_ends_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "store": {
+ "type": "string"
+ },
+ "store_slug": {
+ "type": "string"
+ },
+ "store_url": {
+ "type": "string"
+ },
+ "tax_status": {
+ "enum": [
+ "included",
+ "excluded",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "vat_percent": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "was_price_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "store",
+ "store_slug",
+ "price_cents",
+ "currency",
+ "price_eur_cents",
+ "net_price_cents",
+ "net_price_eur_cents",
+ "vat_percent",
+ "tax_status",
+ "in_stock",
+ "discount_pct",
+ "was_price_cents",
+ "sale_ends_at",
+ "price_low_30d_cents",
+ "last_seen_at",
+ "store_url",
+ "deep_link"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "price_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Cheapest live offer, minor units of `currency`"
+ },
+ "price_eur_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Same price converted to EUR at ECB rates"
+ },
+ "price_low_all_time_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "rating": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "rating_count": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "released_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sale_ends_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sims": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "store": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "summary": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tax_status": {
+ "enum": [
+ "included",
+ "excluded",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "was_price_cents": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "developer",
+ "category",
+ "sims",
+ "price_cents",
+ "currency",
+ "price_eur_cents",
+ "net_price_cents",
+ "net_price_eur_cents",
+ "tax_status",
+ "store",
+ "discount_pct",
+ "was_price_cents",
+ "sale_ends_at",
+ "offer_count",
+ "rating",
+ "url",
+ "description",
+ "summary",
+ "version",
+ "released_at",
+ "rating_count",
+ "first_seen_at",
+ "image_url",
+ "aircraft_types",
+ "airports",
+ "offers",
+ "price_low_all_time_cents",
+ "is_lowest_ever",
+ "also_listed_as"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]list_addons_for_aircraft3 fields changedOutput schema / properties / results / items / properties / net_price_eur_centsAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / results / items / properties / tax_statusAdded value: +{
+ "enum": [
+ "included",
+ "excluded",
+ "unknown"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / requiredPrevious value: -[
- "slug",
- "title",
- "developer",
- "category",
- "sims",
- "price_cents",
- "currency",
- "price_eur_cents",
- "net_price_cents",
- "store",
- "discount_pct",
- "was_price_cents",
- "sale_ends_at",
- "offer_count",
- "rating",
- "url"
-]New value: +[
+ "slug",
+ "title",
+ "developer",
+ "category",
+ "sims",
+ "price_cents",
+ "currency",
+ "price_eur_cents",
+ "net_price_cents",
+ "net_price_eur_cents",
+ "tax_status",
+ "store",
+ "discount_pct",
+ "was_price_cents",
+ "sale_ends_at",
+ "offer_count",
+ "rating",
+ "url"
+]list_deals3 fields changedOutput schema / properties / results / items / properties / net_price_eur_centsAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / results / items / properties / tax_statusAdded value: +{
+ "enum": [
+ "included",
+ "excluded",
+ "unknown"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / requiredPrevious value: -[
- "slug",
- "title",
- "developer",
- "category",
- "sims",
- "price_cents",
- "currency",
- "price_eur_cents",
- "net_price_cents",
- "store",
- "discount_pct",
- "was_price_cents",
- "sale_ends_at",
- "offer_count",
- "rating",
- "url"
-]New value: +[
+ "slug",
+ "title",
+ "developer",
+ "category",
+ "sims",
+ "price_cents",
+ "currency",
+ "price_eur_cents",
+ "net_price_cents",
+ "net_price_eur_cents",
+ "tax_status",
+ "store",
+ "discount_pct",
+ "was_price_cents",
+ "sale_ends_at",
+ "offer_count",
+ "rating",
+ "url"
+]list_sceneries_for_airport3 fields changedOutput schema / properties / results / items / properties / net_price_eur_centsAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / results / items / properties / tax_statusAdded value: +{
+ "enum": [
+ "included",
+ "excluded",
+ "unknown"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / requiredPrevious value: -[
- "slug",
- "title",
- "developer",
- "category",
- "sims",
- "price_cents",
- "currency",
- "price_eur_cents",
- "net_price_cents",
- "store",
- "discount_pct",
- "was_price_cents",
- "sale_ends_at",
- "offer_count",
- "rating",
- "url"
-]New value: +[
+ "slug",
+ "title",
+ "developer",
+ "category",
+ "sims",
+ "price_cents",
+ "currency",
+ "price_eur_cents",
+ "net_price_cents",
+ "net_price_eur_cents",
+ "tax_status",
+ "store",
+ "discount_pct",
+ "was_price_cents",
+ "sale_ends_at",
+ "offer_count",
+ "rating",
+ "url"
+]price_history2 fields changedOutput schema / properties / price_basisAdded value: +{
+ "const": "net",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "as_of",
- "slug",
- "days",
- "points",
- "min_eur_cents",
- "max_eur_cents",
- "current_eur_cents",
- "is_lowest_ever",
- "url"
-]New value: +[
+ "as_of",
+ "slug",
+ "days",
+ "price_basis",
+ "points",
+ "min_eur_cents",
+ "max_eur_cents",
+ "current_eur_cents",
+ "is_lowest_ever",
+ "url"
+]search_addons4 fields changedInput schema / properties / max_price_eur / descriptionPrevious value: -"Inclusive ceiling on the cheapest offer, in euros"New value: +"Inclusive ceiling on the known VAT-excluded price, in euros"Output schema / properties / results / items / properties / net_price_eur_centsAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / results / items / properties / tax_statusAdded value: +{
+ "enum": [
+ "included",
+ "excluded",
+ "unknown"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / requiredPrevious value: -[
- "slug",
- "title",
- "developer",
- "category",
- "sims",
- "price_cents",
- "currency",
- "price_eur_cents",
- "net_price_cents",
- "store",
- "discount_pct",
- "was_price_cents",
- "sale_ends_at",
- "offer_count",
- "rating",
- "url"
-]New value: +[
+ "slug",
+ "title",
+ "developer",
+ "category",
+ "sims",
+ "price_cents",
+ "currency",
+ "price_eur_cents",
+ "net_price_cents",
+ "net_price_eur_cents",
+ "tax_status",
+ "store",
+ "discount_pct",
+ "was_price_cents",
+ "sale_ends_at",
+ "offer_count",
+ "rating",
+ "url"
+]compare_pricesfetchfind_aircraft_typeget_addonlist_addons_for_aircraftlist_dealslist_developerslist_sceneries_for_airportlist_storesprice_historysearchsearch_addonsGame prices across Steam, Epic, GOG and Microsoft, with real price history and giveaways.
Game prices across verified stores, with price history and a buy-now-or-wait verdict.
PC game prices from Steam, GOG, Gamivo, G2A, Kinguin: deals and upcoming releases.
Price comparison across partner retailers. Read-only, 90-day history, disclosed affiliate.
Add one secure layer between your agents and this server.
