Jetopolis

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description adds real value beyond that by explaining the year filter semantics and what availabilityInYear means (sold new vs used only). It still omits anything about result size or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences that front-load the resource and then the conditional year behavior; there is little waste, though the attribute enumeration verges on listing return fields the output schema already defines.

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, non-destructive catalog lookup with an output schema and strong annotations, the description covers the ambiguous behavior (year filtering and availability semantics). The only real gap is routing guidance against the sibling price tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, above the midway mark, and the description largely restates the schema-documented year semantics while explaining the derived availabilityInYear field. It adds nothing for lang or category, which the schema leaves partially bare.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (aircraft types in the game catalog) and enumerates the attributes returned, so the agent knows exactly what it resolves to. It does not, however, distinguish itself from the sibling aircraft_price, which appears to cover overlapping pricing data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this versus alternatives such as aircraft_price, nor any prerequisites or exclusions beyond the mechanical effect of the year parameter. Usage is only implied by the resource name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by disclosing the pricing model (entry-into-service price inflated by US CPI, returned in both nominal and 2024 dollars) and the candidate-list behavior on ambiguous matches, which the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads what the tool returns and then covers input format and ambiguity handling. Every clause carries information, though the sentence is long enough to be slightly taxing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description does not need to explain return fields, and the annotations cover safety. The pricing basis and candidate-fallback behavior are the remaining non-obvious details, and both are stated, leaving only minor gaps (e.g. rounding or units).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description restates the same id-or-name convention and hints that the year acts as a disambiguator, but adds little syntax or format detail beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('in-game catalogue price of a new aircraft in a given year') and pins the scope to catalogue prices rather than market/resale values. An agent can distinguish it from the sibling aircraft_catalog (a lookup) without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the accepted input ('an id from aircraft_catalog or part of the name') and the ambiguity fallback ('when several types match and the year does not settle it, returns candidates'). It gives clear usage context but never explicitly says when not to use it or names a preferred alternative tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds useful domain behavior: a world may have ended, in which case finishedAt is present, which tells the agent how to interpret a result rather than just fetch one.

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, front-loaded with the verb and resource, then the differentiating return detail. 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?

With an output schema present, return values needn't be explained, and annotations cover the safety profile; the description's job is to route and frame, which it does. Only the optional lang parameter's behavior is left entirely to the 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 description coverage is 100%, so both worldId and lang are documented in the schema. The description only reinforces worldId's provenance ('by id') and says nothing about the lang locale parameter, so it adds little beyond the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('one world by id') and explicitly contrasts with the sibling list_worlds by noting it returns 'the same card as in list_worlds plus finishedAt'. An agent can distinguish it from list_worlds without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'by id' phrasing plus 'id from list_worlds' (echoed in the schema) makes the single-lookup use case clear and points to the sibling that supplies the required id. It stops short of an explicit when/when-not statement or naming what to do when the id is unknown.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safe read profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower, yet the description still adds real behavioral value: decade-level precision on network data, the meaning of servedCountries, and the networkKnown=false case. It does not discuss pagination behavior beyond the limit cap or response envelope, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences, but each carries non-redundant information and the core purpose is front-loaded in the first clause. Density is high with no filler, though the data-precision caveats could be tightened slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the description still helpfully clarifies output semantics (servedCountries, networkKnown, sort order by airline size). Combined with the 100% schema coverage, an agent has what it needs to call and interpret the tool; only a brief note on result volume/pagination is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters including enums and ISO pattern, setting the baseline at 3. The description reinforces the year bounds but adds no syntax or interpretive detail for kind/region/country/limit beyond what the schema states.

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 specifies exactly what is returned — real airlines operating in a year, with fields (name, IATA, country/region, type, years of operation, served countries) — so an agent can instantly tell this apart from aircraft_catalog or get_world. It never names an alternative sibling, but the resource is unambiguous, so no sibling differentiation is needed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the year range (1950-2030) and the filtering parameters, but there is no explicit when-to-use or when-not guidance and no alternative named among the siblings. The caveats about decade-precision network data and networkKnown=false function as usage guidance for interpreting results, which lifts it above a bare minimum.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds content scope (steps, world pace, links) but no behavior beyond that, such as caching, freshness, or size of the guide, so it earns a moderate score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the purpose and packs the content scope and language options without any filler. Nothing is redundant with the name or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the single optional parameter is covered. The description sufficiently characterizes what the agent will get, though it could note the guide is static content rather than live game data.

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%, but there is only one parameter and its enum already constrains it to en/ru. The description compensates by stating 'English or Russian', clarifying that the lang value selects the output language of the guide, adding meaning the bare enum does not convey.

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+resource: it delivers the onboarding steps for the game Jetopolis, plus world pace and links. This is clearly distinct from the data-lookup siblings (aircraft_catalog, world_standings), but it never explicitly names or contrasts them, so it stops 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?

'How to start playing' implies the audience (new players needing an intro) but there is no explicit when-to-use statement, no when-not-to-use, and no named alternative among the sibling tools. Usage is inferable from the name and description rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only/idempotent/non-destructive profile, so the bar is lower. The description adds genuinely useful behavior beyond the structured fields: 'Worlds never pause' (no pausing means the listing stays current) and the 24-hour activity window, which tells the agent what 'active' means. It does not mention pagination or result caps, hence not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded correctly and the closing sentence 'Worlds never pause' earns its place. However, the bulk of the text is a long enumeration of returned fields (name, region, pace, years, dates, players, active counts, link) — content an output schema already provides, so much of the sentence is redundant here.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value detail needn't live in the description, and annotations handle the safety profile; the required context for this tool is mostly covered. The remaining gap is the absence of any guidance on filtering behavior or how this list relates to the sibling get_world.

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 75%, so the schema largely carries the load. The description restates the pace semantics (Standard = 20 minutes, Blitz = 5) that the schema already documents for `type`, and gestures at region and 'open right now' but says nothing about `lang` or the status enum values (RUNNING/FINALE/FINISHED). Marginal added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: 'Public Jetopolis worlds open right now', which clearly implies a listing operation for live worlds. This is distinguishable from the singular sibling get_world, but the description never names that sibling or explicitly contrasts the two, leaving differentiation to inference.

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 'open right now' implies when the tool is appropriate (browsing live worlds), but there is no explicit when-to-use or when-not-to-use guidance and no reference to get_world or world_standings as alternatives. Usage is suggested rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: the data is refreshed once per game day, and cash, fares and profit are explicitly excluded because they are private to each player. It does not cover pagination or limit behavior, but the privacy/freshness notes are real added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core idea (player airlines ranked by rating) followed by the field list and freshness/privacy notes. The field enumeration is long but each item is informative; nothing is redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, yet it does so usefully and adds data-freshness and privacy constraints. The main gap is the absence of usage guidance relative to siblings, which is a moderate omission for a listing tool in a crowded namespace.

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 67%: lang and worldId carry descriptions (including fallback behavior for lang), but limit is undocumented in both schema and description. The description mentions no parameters at all, so it neither compensates for the gap nor adds meaning over the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and scope: player airlines in one world, ranked by rating, and even enumerates the returned fields. It is clearly distinct in content from siblings like aircraft_catalog or historical_airlines, but it never names or contrasts an alternative, so differentiation is implicit rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this tool versus alternatives such as get_world, list_worlds or historical_airlines, and no preconditions or exclusions. A reader must infer its role from the return-value list alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.