Georgia MCP

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses filtering behavior (readings older than 24 hours are dropped), ordering (stations come worst first), aggregation semantics (a station level is its worst reading), the level vocabulary, units including the CO exception in mg/m³, and the upstream timestamp quirk where NEA publishes some readings ahead of the clock. These are exactly the traits an agent cannot get from structured fields.

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

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

Dense but front-loaded: scope first, then reading contents, then ordering, freshness cutoff, and the timestamp caveat. Every clause carries information an agent would otherwise have to discover empirically; there is no filler.

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

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

For a read-only query tool with full schema coverage and an output schema, this is nearly complete — freshness window, ordering, units, and timezone caveat are all covered. The only gap is the missing explicit hand-off to air_list_history for historical queries.

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

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

Schema coverage is 100%, so city, station, limit, and language are already documented, and the description's 'city or station, not both' note duplicates the schema. What it adds is mostly output semantics (units, level scale, ordering) rather than new parameter meaning, 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?

The description opens with a specific verb and resource — 'Returns the newest air quality readings of the automatic stations of the National Environmental Agency of Georgia' — and states the three scoping modes (a city, one station, or every station). It is easy to separate from the sibling air_list_history based on the 'newest readings' framing alone.

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 says the tool works for a city, a single station, or every station, and the schema reinforces the mutual exclusivity of city and station. It does not explicitly name air_list_history as the alternative for historical data, so the agent must infer the boundary from the 'newest' wording.

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 read-only, idempotent, non-destructive, open-world behavior, and the description adds genuinely non-obvious traits: the 7-day maximum window, newest-first ordering, the 24-hour default, and the NEA quirk that some readings are timestamped a few hours ahead ('the time is as published'). It does not cover behavior on empty results or invalid station codes.

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

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

Front-loaded with what is returned and the time window, followed by the prerequisite and the timestamp caveat, so the most decision-relevant facts come first. The trailing 'Data from the NEA.' repeats the attribution already given in the first sentence and could be dropped.

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, annotations cover the safety profile, and the schema fully documents all six parameters, so the description only needs to supply window limits, defaults, the prerequisite call, and the timestamp anomaly — all of which it does. Nothing an agent needs in order 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%, so every parameter is already documented, including the 7-day from/to pairing, limit 1-100, pollutant enum list, and language codes. The description restates the 7-day cap and the 24-hour default but adds no new syntax, format, or interdependency detail beyond the schema, so the 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?

Names a specific verb and resource ('Returns the hourly readings of one station'), pins the source (NEA Georgia), and states the scope (at most 7 days, newest first, with the level of each reading). An agent can distinguish it from air_get_quality, which the description explicitly frames as the lookup step rather than the history fetch.

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

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

Gives an explicit prerequisite sequence: 'Call air_get_quality first to find the station code', plus the default behavior when no date range is supplied (last 24 hours). It stops short of stating when NOT to use it, e.g. what to do for periods longer than 7 days or for other stations' comparison.

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, and open-world, and the description adds real context beyond them: the map is re-read from the server on every call (no caching), no seat is held, and sessions already started are out of scope. It does not discuss failure modes (e.g., invalid or expired session code) or rate/availability constraints, so it is strong but not exhaustive.

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

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

The core purpose and the payload contents are front-loaded, and most sentences carry information (not-started restriction, no reservation, purchase happens on cavea.ge). The trailing 'Data from the web site of Cavea, cavea.ge' partially repeats the title and resource name, a minor 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?

An output schema exists, so the description need not enumerate return fields, yet it summarizes them briefly and adds the one behavioral fact the schema cannot convey — fresh server read, no reservation. Combined with the not-started precondition, this is sufficient for correct invocation, with only error/edge-case handling left implicit.

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%: the 'session' parameter already documents its format and provenance from cinema_list_sessions, and 'language' documents the ka/en values and the en default. The description adds nothing further about either parameter, so the 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?

The description gives a concrete verb and resource ('Returns the seats of the hall of one session of Cavea') and even enumerates the payload: rows, seats, class, taken mark, special-needs mark, free-seat count, and per-class price in lari. It does not explicitly name or contrast a sibling tool (cinema_list_sessions only appears in the schema), 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?

It states a clear applicability condition — the session must not have started — and clarifies the boundary of the tool ('It reserves no seat. A person buys the ticket on cavea.ge'), which tells the agent this is a preview/inspection call, not a booking step. It lacks an explicit 'use X instead when...' pointer to siblings, which keeps it below 5.

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 and openWorld, so the safety profile is covered. The description adds useful context beyond them: the listing is limited to currently open cinemas, and the data originates from cavea.ge, which explains freshness and coverage. It does not discuss ordering or rate limits, keeping it short of a 5.

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

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

Three short sentences, front-loaded with the core purpose and then the return fields and the routing hint. The provenance sentence ("Data from the web site of Cavea, cavea.ge") is the weakest, but it still conveys a source an agent may care about.

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-required-parameter read listing with an output schema and full annotation coverage, nothing an agent needs is missing. It even names the returned fields and the downstream consumer of the codes, which is more than the structured data alone supplies.

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 single "language" parameter is fully documented in the schema (values ka or en, default en). The description never mentions the parameter or how it affects the returned names, so it adds no meaning beyond the schema — baseline 3.

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 ("Lists the open cinemas of Cavea") plus geographic scope (Tbilisi and Batumi), and enumerates the returned fields. This clearly distinguishes it from cinema_list_sessions and cinema_list_movies, which deal with sessions and films rather than the cinema roster.

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

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

Gives an explicit chaining instruction: "Use the code in cinema_list_sessions," which tells the agent this is the discovery step before session lookup. There is no explicit when-not or mention of the other cinema siblings, so it stops short of full alternative routing.

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 tool read-only, idempotent, non-destructive, and open-world, so safety traits are covered outside the description. The description adds the data source (cavea.ge) and enumerates returned fields, but says nothing about pagination behavior, rate limits, or freshness of 'now showing' data that annotations do not cover.

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

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

Purpose is front-loaded in the first sentence, followed by return fields, the downstream workflow step, and provenance. The enumeration of return fields is somewhat redundant given an output schema exists, but the description stays compact and has 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?

For a simple read-only list tool with full schema coverage, an output schema, and complete annotations, the description covers purpose, scope, output fields, data provenance, and the follow-up call. The only missing piece is how 'now showing' vs 'coming soon' relates to the status parameter and result limits.

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 all three parameters (limit, status, language) are already fully documented with defaults and allowed values. The description's phrase 'shows now, or coming soon' loosely maps to the status parameter but adds no syntax, default, or format information beyond the schema, so the 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 ('Lists') and resource ('movies') with clear scope: now showing or coming soon from Cavea. It differentiates itself implicitly from cinema_list_sessions by telling the agent to pass the returned code there, but it never contrasts itself with sibling cinema_search_movies, 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?

Gives a clear workflow cue: use the returned code in cinema_list_sessions, which tells the agent when this tool fits in a sequence. It provides no explicit exclusions or comparison against cinema_search_movies, so guidance is contextual rather than complete.

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 only say read-only/idempotent/non-destructive; the description adds the non-obvious behavior that only not-yet-started sessions are returned and that output shape is conditional — price per seat class when a movie is given, price of the Standard class otherwise. It also discloses provenance ('cavea.ge'), which matters for an openWorld tool.

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

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

Front-loaded with the core scope and ordering, then filters, then return fields, then the cross-tool pointer. Every sentence carries information, though the filter enumeration mildly duplicates the schema and the closing provenance sentence is optional.

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?

Thorough for a 7-parameter, zero-required read tool: scope, filtering, ordering, conditional output shape, and next-step integration are all covered, so an agent can call it correctly with no parameters or with any filter subset.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: specifying 'movie' changes the price granularity of the response, an effect not visible in the parameter's own description. It also names the upstream tools that supply movie and cinema codes, though that is partly redundant with the schema.

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 ('Lists the sessions of the movies of Cavea') plus two sharp constraints that distinguish it from siblings: one date only, and only sessions that have not started. The ordering rule (by start time) further pins down the semantics an agent can rely on.

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 how to narrow the result set (movie, cinema, audio language, format) and gives a downstream workflow pointer ('Use the session code in cinema_get_seat_map'), which tells the agent where this tool sits in a chain. It lacks an explicit exclusion or 'use X instead' statement relative to cinema_list_movies, 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.

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds one useful behavioral caveat, that the backend matches only English names, but otherwise restates the returned fields, which the output schema already enumerates. No mention of matching semantics (substring vs prefix), case handling, or empty-result 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?

The definition is three short sentences, with the core purpose and search key front-loaded before the return fields. The final sentence about the data source, cavea.ge, is largely redundant with the tool name and title, so there is minor waste but no clutter.

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?

Because an output schema exists, the description need not explain return values, and the input schema fully documents all three parameters. What is missing for a search tool of this complexity is behavior on no matches, case sensitivity, and whether the tool differs meaningfully from cinema_list_movies, which an agent must infer.

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

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

Schema coverage is 100%, so both limit and language, including the partial-English-name constraint, are already documented in the schema. The description's added meaning is limited to reinforcing the English-only matching rule; it says nothing about how query substrings are matched or how limit interacts with results beyond the schema's stated bound.

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 uses a concrete verb and resource ("Finds the movies of Cavea") and adds scope detail ("now showing or coming soon, by a part of the English name"). This implicitly separates it from the broader list-oriented sibling cinema_list_movies, but it never names that sibling or any other alternative, so the differentiation is inferred 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?

It gives a practical input rule (pass English text; Georgian names will not match), which is real usage guidance for calling the tool. However, it never states when to prefer this search over cinema_list_movies or how to proceed if a search returns nothing, so the when/when-not guidance is only implied.

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/openWorld/idempotent/non-destructive, so the description is not carrying the safety burden. It adds genuinely non-obvious behavior: prices are today-only with no history, prices are per unit with explicit units per grade, and a missing self_service_price means the company offers no self-service product. The repeated "publishes no effective date" notes hint at a data-quality caveat but never say how it affects the returned prices, which keeps this from 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?

Front-loaded with the core action and scope, then layered into product/price semantics and company codes. It is on the long side and repeats the eight grade names already present in the schema, plus the "publishes no effective date" parenthetical seven times, but each sentence still carries information.

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

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

With an output schema present, the description need not explain return shape, and it covers the remaining agent questions: units, today-only freshness, the meaning of a missing self-service price, and the valid company codes. The unexplained "no effective date" caveat is the one loose end for a tool this data-centric.

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

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

Schema coverage is 100% and the schema already documents grades, default language, and empty-array-means-all behavior, so the baseline is 3. The description does add real value by enumerating the eight company codes with their display names, which the schema only gestures at ("The description of the tool lists the codes"), but the grade and language semantics are pure restatement.

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 opening sentence names a specific verb and resource ("Returns the current fuel prices of Georgian fuel companies") and immediately pins down the unit (GEL per unit of product). It is unambiguous against every sibling in the list (rates, transit, stats, etc.), none of which touch fuel.

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 concrete use cases (price of petrol/diesel/gas at a company today, or comparing companies) and rules out the biggest misuse with "The tool has no history." The only gap is that no sibling or alternative is named for historical or other-currency lookups, but the scope statement is strong enough that an agent will not wander.

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, and open-world behavior, so the safety profile is covered. The description adds the useful look-up-by-search-result semantics and the expectation of returning a URL to present to the user. It says nothing about failure behavior for an unknown id or bank, or about rate limits, which would raise this above a 3.

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, front-loaded with what is returned, then the source of the inputs, then the user-facing action. No filler or repetition of the 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?

With an output schema and full annotation coverage, the description only needs to establish purpose, input provenance, and how to present results, and it does all three. The one gap is the unmentioned language parameter and any not-found behavior, which are minor for a simple read 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 description coverage is 100%, so both required parameters are documented in the schema and the baseline is 3. The description reinforces that bank and id come from offers_search_offers, which is mildly additive. The optional language parameter (ka/en, default en) is not mentioned in the description at all.

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 uses a concrete verb and resource ('Returns the full conditions of one offer of a Georgian bank'), which tells an agent exactly what comes back, and it implicitly distinguishes itself from offers_search_offers by dealing with a single offer rather than a search. It stops just short of 5 because 'full conditions' remains generic about the payload, though the output schema covers that.

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 names the prerequisite workflow explicitly: take the bank and the id from offers_search_offers, which routes the agent to the sibling search tool first. It also gives an output-handling instruction (surface the offer URL with the conditions). No when-not-to-use case is stated, so it is clear context rather than full exclusions.

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 cover the read-only, idempotent, open-world profile, and the description adds meaningful behavior the annotations do not: pagination is per bank via next_offset, limit is per bank, and the benefit text is unparsed bank prose from which the percent, cap, and conditions must be read. That last point is a genuinely useful disclosure that prevents an agent from expecting structured numbers.

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 opening sentence is well front-loaded and the long code lists are necessary, but "benefit is the text of the bank" is stated twice and "Compare the banks by reading it" is vague filler. The card code catalogue also consumes a large share of the text for what is essentially lookup data.

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 an 11-parameter search tool with an output schema and full annotation coverage, the description covers filters, pagination, semantics of obscure codes, and the critical caveat about parsing benefit text. Only minor things are absent, such as what an empty result looks like or how per-bank limits interact with offset advancement.

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 already 100%, but the description goes well beyond it: the bank code list, the per-bank card code list, the tier definitions (standard/premium incl. SOLO at BOG, private incl. Wealth Management at BOG, youth), and the note that "other" means the bank states no kind. These resolve the code enumerations that the schema itself defers to the description for.

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?

"Finds the current offers that Georgian banks give to card holders at partners: discounts, cashback, and points" states a specific verb (finds), resource (card offers), and scope (partner offers from Georgian banks). It is clearly distinguishable from offers_get_offer by being a search, though it never names that sibling explicitly.

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

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

Gives concrete operating guidance: "For 'this month', give the first and the last date of the month", and "When a bank has a next_offset, call again with that offset to read more", plus "Give the person the url of each offer that you name". It lacks an explicit statement of when to use this versus offers_get_offer, which is the main remaining gap.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the coverage limitation that Georgian Post assigns street-level codes only in the three largest cities, plus the source of the data. It does not mention rate limits or result-ordering 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?

Four sentences, front-loaded with the core purpose and input scope, then the important coverage caveat. The closing attribution ("Data from the web page of Georgian Post") is mildly redundant with the first sentence's mention of Georgian Post, but costs little.

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 three-parameter lookup tool with an output schema and full annotation coverage, this covers purpose, inputs, languages, geographic caveats, and source. Minor omissions are the limit behavior and what happens when nothing matches, but nothing essential to calling 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%, so the schema already documents query, limit, and language. The description reinforces the accepted input types and the Georgian/English option, which maps loosely to the language parameter, but says nothing about limit or the 3-100 character constraint. 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 and resource ("Finds the postal codes of Georgian Post") and scopes it to Georgia with accepted input types (address, street, town, village) and languages. It also states the return shape (matching address, 4-digit postal code, district), so the tool is fully identifiable and cannot be confused with any sibling, all of which serve unrelated domains.

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 actionable usage rules: use street-level lookup in Tbilisi, Batumi, and Kutaisi, and "For another town or a village, search its name" elsewhere. There are no alternative postal tools to route to, and no explicit exclusions or failure cases are stated, so it falls just 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.

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds genuine domain behavior on top: the data is same-day only, there is no historical data, results can be compared across banks, and the buy/sell price definitions prevent misinterpretation of the returned values. It does not cover failure modes (e.g. a bank not quoting a currency) or any rate limits, which keeps it from 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?

Front-loaded with the purpose, then the when-to-use, then the parameter semantics, which is a sensible order. The closing 'The rates are of today. The tool has no history.' repeats information already implied by 'current' and 'today' earlier in the text, so a sentence of redundancy remains.

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 structure need not be explained, and annotations carry the safety profile. The description supplies the remaining agent-critical context: what the numbers mean (buy vs sell), which bank codes are legal, the currency-count limit, and that only today's data is available.

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

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

Schema coverage is 100%, so both parameters are already documented, which sets the baseline at 3. The description adds real value by enumerating all fourteen valid bank codes with their full names and legal kinds (a substitute for the missing enum), but for currencies it only restates the schema's '1 to 10 ISO 4217' rule without adding format examples beyond the schema's own USD/EUR hint.

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 opening sentence gives a specific verb and resource ('Returns the current commercial exchange rates of Georgian banks') and defines the unit being priced (GEL per one unit of currency). The word 'commercial' implicitly separates it from the official-rates siblings, and 'The tool has no history' rules out the history siblings, but no sibling is named explicitly.

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?

'Use it for the price of a currency at a bank today, or to compare banks' gives a clear context for selection, and 'Ask for 1 to 10 currencies' sets the usage envelope. It stops short of explicitly naming alternatives such as rates_get_official_rates or rates_list_official_history, so the agent must infer that official/central-bank rates belong elsewhere.

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 safety profile (readOnly, idempotent, non-destructive, open world), and the description adds genuinely non-obvious behavior: publication around 17:00 Tbilisi, effect from the next day until the next set, and that a weekend or holiday returns the set in force. The caveat that the official rate is indicative and not a bank price further prevents misinterpretation of 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?

Purpose is front-loaded, followed by usage contexts then behavioral timing notes — a sensible order with no filler sentences. Minor overhead comes from explaining output fields ('quantity' units vs `rate_per_unit`) that an output schema already covers.

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 annotations, a full output schema, and 100% parameter coverage already present, the description supplies exactly the missing operational context: publishing schedule, effective dates, and holiday behavior. Only edge-case error handling for out-of-range dates is left implicit in the schema text.

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 date bounds, the en/ka language choice, and the ISO 4217 currency list with a 50-item cap are already fully documented in the schema. The description adds no parameter-level detail (e.g., no guidance on combining currencies with an empty date beyond what the schema states), so the 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?

The first sentence names a specific verb and resource ('Returns the official exchange rates of the lari ... for one date'), giving a precise read operation with a single-date scope. It also conceptually separates itself from commercial/bank pricing ('It is not the price of a bank'), though it never names the sibling tool rates_get_commercial_rates or rates_list_official_history.

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 supplies concrete use contexts ('the rate of a currency today or on a past date, for a contract, an invoice, or a tax form'), which tells an agent when this tool is appropriate. It stops short of excluding alternatives — nothing says to use rates_get_commercial_rates for bank pricing or rates_list_official_history for ranges.

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 and non-destructive, so the safety profile is covered. The description still adds real substance beyond that: the 31-day ceiling, one data point per rate set in force including the first day, and the unit semantics of the returned rate. It does not discuss permissions or rate limits, but neither is relevant for a public read.

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 tight sentences, front-loaded with the core purpose and free of filler. The 31-day restriction is stated twice (description and schema for `to`), a minor redundancy but not enough to hurt readability.

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

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

With a full output schema, the description does not need to document return values, yet it helpfully sketches the cardinality (one point per rate set) and unit convention. Combined with the schema, annotations and the stated 31-day constraint, an agent has what it needs to invoke this 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 coverage is 100%, so the schema already fully documents currency, from, to and language, and the description merely echoes the 31-day bound. Its one genuine addition is that each rate is the price in GEL of `quantity` units, which clarifies output interpretation more than input parameters, keeping this at the 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 and resource: official exchange rates for one currency over a bounded period, attributed to the National Bank of Georgia. It distinguishes itself implicitly from current-rate siblings via the historical/period framing, but never names rates_get_official_rates or rates_get_commercial_rates, so differentiation is inferred 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?

"Use it for the movement of a currency over a week or a month" gives concrete usage context, which is better than nothing. However, there are no exclusions or alternatives named, so an agent must guess whether this or rates_get_official_rates / rates_get_commercial_rates is the right call.

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?

The annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds the limits that matter when calling: at most 1000 cells are selected, an unpublished figure comes back as null, and the table title names the unit. The 1000-cell cap and null semantics are the kind of detail only the description provides.

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 short sentences cover purpose, limits, and edge cases, and the main purpose comes first. The closing 'Data from Geostat' and 'The title of the table names the unit' are low-value short notes, but they are still compact.

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 the description need not explain the response shape, and it correctly spends its detail on the selection limit, null semantics, and defaults. The main remaining gap is sibling routing: nothing in the text points to stats_get_table for dimension codes, though the schema does.

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

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

Schema coverage is 100%, so code, language, selection, values, and last are all documented, and the description mostly repeats the 'dimension omitted takes every value' rule already in the schema. The null-for-unpublished detail adds a little meaning about returned figures, but nothing about the values/last mutual exclusion 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 states a concrete verb and resource ('Returns the figures of one table of Geostat') and scopes the result ('value codes, or the last values, for each dimension'). That distinguishes it clearly from stats_get_table (metadata) and stats_search_tables (discovery) without needing either schema opened.

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 tells the agent implicitly that a selection is optional, because a dimension with no selection takes every value. It never states when to use this rather than stats_get_table or stats_search_tables, and that routing only appears as a hint in the schema ('from stats_search_tables'). The agent can infer the usage, but the description does not say it.

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 and open-world, so the safety profile is covered. The description adds genuinely new context: the unit (percent), the exact definition of each of the four measures, the data provenance (Geostat CPI), and the default-to-latest-month 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?

Three sentences, zero filler: output and unit first, dimensionality second, default and provenance last. Each sentence carries information the caller needs.

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, and it still covers units, measure definitions, dimensionality and defaults. Nothing required for a correct zero-required-parameter call is missing.

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

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

Schema coverage is 100% and every parameter, including the full enumerations for group, region and language, is documented in the schema. The description only restates the month/region/group axes and the newest-month default, adding no format or constraint detail beyond the schema, so 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 — 'Returns the inflation of Georgia for one month, in percent' — and enumerates the four measures (annual, monthly, 12-month average, core), so it cannot be confused with the generic stats_get_table / stats_get_cells 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?

Gives clear operating context: the dimensions available (whole country, city, price group), the default of the newest published month, and the Geostat CPI source. It does not name an alternative tool or state when a caller should prefer stats_get_table instead, so it stops short of explicit routing.

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 and non-destructive, so safety is covered. The description adds genuine behavioral detail beyond that: time dimension values run oldest to newest, and there is no unit field because the title names the unit — a real caveat that prevents misinterpretation of returned dimensions.

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?

Four short sentences, front-loaded with the return content and followed by the ordering rule and the unit caveat. The trailing 'Data from Geostat.' is redundant with the title and the repeated source mention, a small waste in an otherwise tight definition.

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 structure need not be restated, and the description instead supplies the non-obvious semantics an agent needs: dimension ordering and the absence of a unit field. Little is missing for a two-parameter read tool; only the language parameter goes unaddressed in prose.

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%, including the code format example and the ka/en language options, so the schema carries the parameter burden. The description adds no parameter-level meaning and never mentions the language parameter at all, leaving it at the 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?

Names a specific verb and resource: returns the title and dimensions of one Geostat table, with the code and text of each value. It also explicitly positions itself relative to stats_get_cells ('Read it before...'), so an agent can tell the two apart 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?

Gives explicit sequencing guidance: call this before stats_get_cells. That is a clear usage condition tied to a named sibling. It stops short of stating when not to use it or how it relates to stats_search_tables for obtaining the code, so it is not a full when/when-not map.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely new behavior: AND-matching across every word, the covered fields, the returned fields, and newest-first ordering. That is useful context but not deep behavioral disclosure (e.g. no mention of partial-match or stemming 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?

Three tight sentences, front-loaded with the core purpose, then return shape, then the next-step call. Every sentence carries distinct information and there is no filler.

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

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

For a three-parameter read tool with full schema coverage, annotations, and an output schema, the description covers purpose, matching semantics, return fields, ordering, and the follow-up call. Nothing an agent needs to invoke it correctly is missing; restating the return fields is harmless redundancy rather than a gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns a bump by clarifying the 'every word' conjunctive semantics and the searched fields (title or folder), which the schema's 'words to find' phrasing does not state. The limit and language parameters are left entirely to the schema.

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 ('Finds the tables of Geostat') plus the matching scope ('whose title or folder holds every word of a text') with concrete examples. It also names the sibling it hands off to (stats_get_table), so the agent can distinguish it from stats_get_table and stats_get_cells without opening a schema.

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

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

Explicitly says 'Then call stats_get_table with a code', giving a clear follow-up workflow that ties search to retrieval. It lacks explicit when-not-to-use guidance or a mention of when to prefer stats_get_inflation or stats_get_cells, so it stops short of full alternative routing.

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 the safety profile is covered. The description adds the useful behavioral detail that results are grouped by direction with headsign and stop order, but says nothing about error behavior for unknown routes or how kind disambiguation affects the result.

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 with no filler; the return structure is stated first and the qualifier second. Minor cost: 'TTC' is unexplained, though the title clarifies the Tbilisi context.

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 a full output schema, complete parameter descriptions, and read-only annotations, the description only needs to state scope and return shape — which it does. Missing only edge-case behavior (unknown route, ambiguous route number across kinds), which is a small gap for a simple lookup.

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 route number/id, kind, and language are already documented in the schema. The description mentions no parameters at all, adding no meaning beyond the structured fields — 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 ('Returns a route of the TTC') and specifies the payload shape: each direction with its headsign and ordered stops. That clearly separates it from search/list siblings like transit_search_routes, though it never names an alternative explicitly.

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 when-to-use or when-not guidance and no mention of alternatives such as transit_search_routes or transit_get_timetable. The only usage signal is the implied 'fetch details for a known route' framing carried by the name and the required route parameter.

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 safety profile (read-only, idempotent, open-world, non-destructive), so the bar is lower. The description still adds real value: it discloses that results are limited to the current week and that times of 24:00 or later belong to the next calendar date, which prevents a common misreading of returned data.

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 tightly written sentences with the core behavior front-loaded and the 24:00 edge case appended as a clarifying note. Nothing is redundant and nothing needs trimming.

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, annotations covering safety, and full schema description coverage, the description only needs to carry behavior and scoping, which it largely does. The one remaining gap is routing relative to transit_list_arrivals (real-time) and transit_get_route (direction lookup), which an agent would have to work out from sibling names alone.

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 six parameters including date range, kind, language, and direction. The description repeats the current-week constraint and the single-direction scope but contributes no syntax or format detail beyond the schema, making the baseline 3 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 verb and resource — planned departure times for one direction of a route at one stop — plus a scoping constraint (current week). The word 'planned' implicitly contrasts with transit_list_arrivals, but the sibling is never named, so the distinction relies on 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?

Usage is implied rather than stated: the current-week restriction and the fact that a single direction is returned suggest when this tool fits, but there is no explicit when-to-use or when-not guidance relative to transit_list_arrivals or transit_plan_trip. The 'direction required when the route has two directions' rule lives in the schema rather than the description's guidance.

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?

The annotations already establish a safe, idempotent, open-world read, so the bar is lower. The description nonetheless adds genuinely useful context beyond them: the 'live' flag semantics (true when the TTC actually tracks the vehicle, otherwise the time derives from the timetable) and the shape of each arrival entry.

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 compact sentences with the core action first and the route-filter caveat last; nothing is padded. Minor cost: 'the TTC' and 'as_of' are used without definition, which forces the reader to infer the operator and the reference timestamp.

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 and rich annotations are supplied, so return values and safety profile need not be re-explained. The description covers the one non-obvious behavior (live vs timetable-derived times) and is adequate for a 4-parameter read tool; only the sibling differentiation and locale context are thin.

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

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

Schema coverage is 100%, so the schema already documents stop (id vs code), limit (1-30, default 10), route, and language. The description restates the route-filter behavior already present in the schema and introduces 'as_of' as an unexplained reference point that is not an input parameter, adding a small amount of confusion rather than 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?

The description uses a specific verb and resource ('Lists the next vehicles of the TTC at a stop') and enumerates the returned fields (route number, kind, headsign, minutes, expected instant). It never names or distinguishes itself from the closely related siblings transit_get_timetable and transit_plan_trip, so an agent must infer the boundary from the name alone.

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

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

Usage is only implied: 'next vehicles' signals real-time arrival lookups, and the route clause explains behavior when a route is supplied. There is no explicit statement of when to prefer this over transit_get_timetable (scheduled departures) or transit_plan_trip, and no prerequisites or exclusions are given.

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, non-destructive and openWorld, so the safety profile is covered. The description adds real behavioral detail beyond that: results are ordered nearest-first and carry a distance in metres, and the coverage is limited to TTC stops in Tbilisi. It does not mention behavior at radius boundaries or empty results, but the output schema covers return shape.

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, both load-bearing: the first defines the operation, scope and result format, and the second supplies the prerequisite for getting coordinates. Nothing is redundant and the core behavior is front-loaded.

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, full annotation coverage and a fully documented parameter schema, the description only needs to establish scope and the input-acquisition path, both of which it does. The geographic restriction to Tbilisi and the TTC operator scope are stated so an agent will not expect coverage elsewhere.

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%, with every parameter including kind values, limit range and default, language codes, and radius range and default documented in the schema itself. The description only reinforces the distance concept via 'within a distance' and the metres unit; it adds no syntax or semantics the schema lacks. 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?

The description gives a specific verb and resource ('Lists the stops of the TTC'), plus the spatial scope (within a distance of a point in Tbilisi) and result ordering (nearest first). It is clear what the tool produces, but it never distinguishes itself from the sibling transit_search_stops, which an agent could easily confuse with a proximity listing.

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 states the context of use and names transit_search_places as the way to obtain the required coordinates, which is a genuine workflow hint for an agent that only has a place name. It stops short of explicit exclusions, saying nothing about when to prefer transit_search_stops (name-based lookup) or transit_get_route instead.

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, openWorld, and non-destructive, so safety is covered. The description adds the useful cap of 'up to 3 itineraries' and the leg structure, but since an output schema exists this is largely restating what structured data provides; no auth, rate-limit, or failure behavior is described.

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 purpose then return shape, then the prerequisite pointer — no wasted clauses. Minor wording friction ('of the TTC in Tbilisi') but nothing that obscures the call.

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 an 8-parameter tool with an output schema and annotations, the description covers the input form (coordinates), the geocoding step, and the shape and cap of results. What remains thin — how timing/preference affect results — is handled by the schema, so an agent could call this 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 100%, so every parameter including timing, preference, kinds, and language is already documented with defaults and allowed values. The description only adds the constraint that points are coordinates (refining 'from'/'to') and adds nothing on timing/preference semantics. 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?

States a specific verb and resource ('Plans a trip by public transport') with scope ('TTC in Tbilisi between two points, given as coordinates'). An agent can tell this is a routing/itinerary tool rather than a stop or timetable lookup, though it never names the route-level siblings (transit_get_route, transit_search_routes) it differs from.

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

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

Gives a concrete prerequisite that selects a sibling: 'Use transit_search_places to get coordinates,' which tells the agent this tool cannot take addresses or names. It lacks any explicit when-not-to-use guidance versus the other transit tools, 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.

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds useful provenance (OpenStreetMap via TTC) and confirms coordinates are returned, but says nothing about matching behavior (fuzzy vs exact), result ordering, or coverage limits beyond Tbilisi.

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 core action and scope, with the data source and downstream consumers appended compactly. No wasted wording.

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 and rich annotations, the description needn't explain return values, and it covers purpose, geographic scope and data source. Only matching semantics and empty-result behavior are left unaddressed, which is a minor gap for a simple search 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 description coverage is 100%, so query, limit and language are fully documented in the schema. The description adds no syntax or format guidance beyond restating that the query is text-based, 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 (finds) and resource (places in Tbilisi: addresses, streets, buildings) plus the search mode (by text) and return content (coordinates). This clearly separates it from transit_search_stops, which handles stops rather than places.

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 names downstream consumers (transit_plan_trip, transit_list_nearby_stops), which implies usage context, but it never states when to prefer this over transit_search_stops or what happens when a query matches nothing. Usage is implied rather than prescribed.

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, openWorld and non-destructive, so the safety profile is covered. The description adds only the empty-query behavior and the available kinds; it says nothing about result ordering, pagination past the limit, or what happens with an unrecognized query.

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

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

Three short sentences, front-loaded with the core action and the fallback behavior. The 'Kinds:' enumeration largely repeats the schema's kind description, which is the only mild redundancy.

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

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

For a simple four-param search tool with an output schema and full annotation coverage, the description supplies what's needed to call it correctly. The main omission is routing guidance relative to sibling transit tools, which is a minor gap.

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

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

Schema coverage is 100%, so all four parameters are already documented in structured form. The description reinforces the query semantics ('by number or by name', empty = all) but adds no format detail such as case sensitivity or partial-match rules 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?

States a specific verb and resource ('Finds the routes of the TTC') plus the two lookup modes (by number or by name), which distinguishes it from transit_get_route in practice. It doesn't explicitly name that sibling, so the differentiation is implied 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 clause 'With no query, lists every route' gives one useful usage condition — the browse-all case. There is no guidance on when to use this versus transit_get_route (fetch one route's detail) or transit_search_stops, so the agent must infer the boundary from tool names.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value beyond that by scoping the operator (Tbilisi Transport Company), the stop taxonomy, and the bilingual Georgian/English matching behavior, which an agent could not infer from the annotations alone.

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, each earning its place: the first defines what is searched and how, the second tells the agent what to do with the result. Scope is front-loaded and there is no filler.

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

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

The tool is a simple read-only search with a full input schema and an output schema, so return-value detail is unnecessary. The description covers scope, matching inputs, and downstream usage, leaving nothing an agent needs in order 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 100%, so kind, limit, query and language are all documented in the schema with defaults and ranges. The description only echoes the query semantics ('by name or stop code, in Georgian or English') and does not add matching behavior such as substring vs prefix search, so 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?

The description names a specific verb and resource (finds stops of the Tbilisi Transport Company), enumerates the covered stop kinds (bus, metro, cable car), and states the lookup keys (name or stop code, Georgian or English). This distinguishes it clearly from transit_list_nearby_stops, which is a proximity lookup rather than a text 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?

The second sentence gives concrete downstream guidance: take the returned stop id into transit_list_arrivals or transit_get_timetable, which is exactly the chaining an agent needs. It stops short of an explicit exclusion (e.g., 'use transit_list_nearby_stops instead when you only have coordinates'), so it is strong context rather than full when/when-not routing.

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