Price comparison for Microsoft Flight Simulator add-ons: search, deals, per-store prices, history.
Scored across 12 tools
Several tools have overlapping boundaries: fetch and get_addon both retrieve a single add-on with descriptions and current prices, and compare_prices largely duplicates the offer data in get_addon. search and search_addons also both query the catalog, and although descriptions hint at intended use, an agent could easily select the wrong one.
Tool names are consistently snake_case and mostly use clear verbs, but the pattern is mixed: five tools use list_*, while others use bare verbs like fetch, fetch search, get_addon, and the noun-style price_history. There is no uniform verb_noun convention across the set, though it remains readable.
Twelve tools is a reasonable count for a catalog server covering add-ons, stores, aircraft, airports, deals, and price history. The count is slightly higher than necessary because a few tools overlap in purpose, but none feel truly gratuitous.
The surface covers search, retrieval, price comparison, history, deals, developers, stores, aircraft, and airport scenery, which is strong for a read-only catalog. Minor gaps exist, such as no dedicated list-addons-by-developer tool, but most browsing needs can be satisfied through search_addons or get_addon.
Every store offer for one add-on, cheapest first, with the gross price in the store currency, the VAT-excluded net price where the rate is known, the EUR conversion, stock, sale expiry and an outbound link. This is the question the website cannot answer in one shot.
| 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 establish read-only, idempotent, non-destructive behavior, and the description adds meaningful behavioral detail: sorting by cheapest first, returning all store offers for one add-on, and including conditional net price/cross-currency fields. It does not cover failure modes or pagination, but the output schema reduces that burden.
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 with the core scoping ('Every store offer for one add-on, cheapest first') front-loaded before the field list. The first sentence is dense but earned; the second sentence adds a positioning statement that is helpful, though slightly vague.
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 single-parameter read-only tool with an output schema and strong annotations, the description covers the result shape, sort order, and key edge case ('where the rate is known'). The main completion gap is the undocumented slug parameter, but this is minor given the low 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?
Schema coverage is 0% and the only parameter is an undocumented 'slug'. The phrase 'one add-on' implies slug is the add-on identifier and adds some meaning, but the description never explicitly defines slug, its format, or where to obtain it, so it only partially compensates for the schema's lack of 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 clearly identifies a singular resource ('one add-on') and the action ('Every store offer ... cheapest first'), plus the returned price details, so an agent knows what the tool computes. It does not explicitly contrast itself with siblings such as price_history or list_deals, though the scope 'one add-on' plus title is enough to separate it from the broader listing 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 final sentence ('the question the website cannot answer in one shot') provides a rough use case but no explicit when-to-use or when-not-to-use guidance. It never names an alternative tool or states conditions that should route the agent to price_history, search_addons, or list_deals.
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 destructiveHint, so safety is covered. The description adds useful detail about the breadth of the returned record, but it does not disclose operational details such as pagination, data freshness, or how 'declared' compatibility should be trusted. That is acceptable but not exceptional.
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 but front-loaded sentence; the opening phrase establishes the operation before the comma-separated list of content. Every listed item contributes information, though the sentence is slightly long.
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 operation with a full output schema and read-only annotations, the description covers the important selection signal: it returns all catalog details for a single add-on. 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 description coverage is 100% and the slug parameter already has a descriptive definition with a URL example. The description adds no additional meaning to the parameter, so it meets the baseline but does not exceed it.
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 resource ('a single add-on') and a clear scope ('everything the catalog holds'), then itemizes the data returned. This makes it easy to distinguish from siblings like price_history, list_deals, and list_addons_for_aircraft, which serve narrower or multi-item purposes.
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 implies this is the tool to use when a complete record for one add-on is needed, and the field list signals that narrower tools like price_history or search_addons are for different jobs. However, it never explicitly names alternatives or says 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.
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 readOnlyHint=true and idempotentHint=true, so the read-only safety profile is covered. The description adds valuable behavioral context beyond those annotations: the type link is the tool's own classification from title and store metadata rather than the store's, and results are ordered cheapest first.
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 tight sentences with no filler. It front-loads the core behavior, scope, and ordering, then adds one short caveat about the classification link, which is essential for correct interpretation.
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 one required parameter and an output schema, the description covers the essential semantics: scope, ordering, and the meaning of the type link. It is slightly incomplete because it omits parameter-level detail and usage alternatives, but it is enough for an agent 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 only 33%, with sim and limit lacking descriptions. The description does not explain these parameters or how they affect results; it only vaguely maps to the aircraft-type concept behind icao_designator. Given the low coverage, the description should have compensated but does not.
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 the resource (add-ons for a real-world aircraft type), the scope (every add-on across all studios), and the ordering (cheapest first), which makes the purpose unmistakable. It does not explicitly name or differentiate from sibling tools like search_addons, so it falls 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?
The description implies when the tool is appropriate: when you want a comprehensive, price-sorted list of add-ons for a single aircraft type. However, it gives no explicit guidance about when to prefer this tool over alternatives such as search_addons, compare_prices, or get_addon.
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 meaningful behavioral context beyond the annotations: the definition of discount as historical-high comparison rather than store list price, and the sorting by deepest discount first. Annotations already cover read-only/idempotent safety, so the description enriches rather than repeats.
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-loads the primary purpose, and provides a crucial definition without any fluff. Every sentence earns its place, and the structure is efficient.
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 core behavioral nuance (discount definition) and is backed by an output schema, but it fails to explain parameter usage (especially sim and category) and does not mention pagination or result limits beyond the schema. Given 4 params and low schema coverage, more context is needed for full completeness.
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% (only ending_within_days has a description). The tool description does not explain sim, limit, or category at all, leaving them ambiguous. With low schema coverage, the description should compensate, but it does not, so parameters remain under-specified.
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 purpose: listing add-ons that are discounted right now, ordered by discount depth. It also clarifies the resource (add-ons) and the specific criterion (current price below historical high). This distinguishes it from generic search or listing tools, though it does not explicitly name 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 implies when to use it (when current deals are wanted) but does not provide explicit when-to-use vs. alternatives, nor any exclusions. The discount definition helps avoid misuse (e.g., permanent markdowns), but no alternative tools are mentioned.
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 declare readOnly, idempotent, and non-destructive behavior; the description adds useful context with 'every...we carry' and 'cheapest first'. It does not reconcile that 'every' is capped or affected by the default `limit` of 25, nor does it address pagination/rate limits, so behavioral coverage is only partial.
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 15-word sentence that front-loads the resource and scope and ends with the ordering behavior. No filler or repetition of the name/title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 'list all sceneries for an ICAO code' call the definition is sufficient, and an output schema exists to clarify return fields. However, the `sim` and `limit` options are left to the schema, and the 'every' wording needs reconciliation with the default limit, so the description is not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% and the description adds no real parameter meaning beyond what the schema already says for `icao`. It does not explain `sim` (filter by simulator) or `limit` (cap on returned rows), leaving two of three parameters under-documented.
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 ('add-on scenery we carry'), the key qualifier ('for one airport'), the input key ('ICAO (or IATA) code'), and the ordering ('cheapest first'), making it immediately distinct from broader 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 scenario is clear: use it when you need the complete scenery listing for a specific airport rather than a general search. It does not explicitly name sibling alternatives or say when not to use it, so it misses the fifth point.
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 cheapest recorded price for one add-on across all its offers, 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 | |
| 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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context: daily granularity, aggregation across offers, and the min/max/current and lowest-ever fields. This enriches the agent's understanding without contradicting 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 concise sentences, front-loaded with the core data returned and ending with a memorable use-case question. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations cover safety, so the description explains the core result well. However, it omits how `days` shapes the data—for example, does 'lowest ever' span all time or just the requested window? This ambiguity could lead agents to misinterpret results.
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 must compensate for parameter meaning. It only implicitly ties slug to 'one add-on' and never mentions the `days` parameter, its default, range, or how it affects the history window. This is a significant gap for a tool with only two 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 states what the tool does: returns the daily cheapest recorded price for one add-on across all its offers, plus min/max/current and a lowest-ever flag. The specific resource and the mention of 'one add-on' distinguish it from siblings like compare_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 provides an explicit use-case question it answers ('has this ever been cheaper than X?'), which implies when to use it. It does not explicitly name alternatives or exclusions, but the single-add-on historical focus is clear enough.
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 cheapest offer, 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 declare readOnlyHint=true and idempotentHint=true, so the agent knows it's a safe, side-effect-free operation. The description adds valuable context: it returns the cheapest live offer and compatibility as declared by the selling store, which indicates the source of data and potential variability. It does not over-explain destructive behavior since none exists.
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 primary purpose, and each component (search scope, return content) earns its place. It's concise but not overly terse—it gives enough detail without redundancy. Minor deduction for not being perfectly optimized, but it's well-structured.
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 complexity (7 optional filters, output schema exists), the description is complete enough for an agent to understand its functionality and invoke it correctly. The output schema likely describes the return structure, so the description need not repeat it. It covers the core value proposition and key constraints like store cross-reference.
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 high (86%), so most parameters are already described in the schema. The description adds extra context by explaining the return is the 'cheapest live offer' and mentions 'discount' which helps interpret 'on_sale' and 'max_price_eur'. It also references list_stores for the store parameter, going beyond the schema. This added value lifts it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the fsaircraft.net catalog of payware MSFS add-ons across all tracked stores, and specifies what it returns (cheapest live offer, discount, compatibility). This verb+resource+scope is precise and distinguishes it from generic sibling tools like 'search' and 'list_addons_for_aircraft'.
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 it: when searching for add-ons by free text with cross-store filtering, and mentions the 'store' parameter references list_stores for slugs. However, it doesn't explicitly contrast with siblings like 'search' (which might be broader) or 'compare_prices' (which might be for price comparison). Still, the context is clear for most use cases.
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_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.
Price comparison across partner retailers. Read-only, 90-day history, disclosed affiliate.
Search 86 US retailers — 260M+ products with real-time pricing, stock, and price history.
Add one secure layer between your agents and this server.
