obrotomierz open data

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the data is manually collected one bank at a time from bank websites, which signals a curated, potentially incomplete snapshot, and it states what each record contains.

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, zero filler, with the core scope and data provenance front-loaded and the parameter behavior stated last. Every clause 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?

There is no output schema, and the description compensates by describing both possible return shapes and the fields within a record. For a single optional-parameter read tool, nothing an agent needs to call 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 coverage is 100%, so the country code's ISO 3166-1 alpha-2 format is already documented. The description adds real semantic value by explaining how presence versus absence of the parameter changes the result shape (per-bank records vs per-country counts), which the schema 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 names a specific resource (cash bonuses for opening a personal current account) and a precise scope (the 27 EU countries), plus the fields returned (amount, deadline, source page). It is clearly distinguishable from the sibling tools, which cover Polish savings bonds and retail government bonds rather than EU current-account bonuses.

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 explicitly explains the two usage modes: supply a country code for a full bank-by-bank list, omit it for per-country counts. That is clear operational context, but no alternative tool or exclusion is named, and there is no guidance on when the aggregate mode is preferable over the detailed mode.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by enumerating the returned content, including the notable detail that interest rates are given for every interest period that has already started. It does not say what happens for an unknown or retired series code, which would have earned 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?

A single front-loaded sentence that states the resource, the keying parameter, examples, and the returned fields with no filler. Nothing could be removed without losing 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?

There is no output schema, so the description correctly compensates by listing what the response contains, and the single parameter is fully covered. The only gap is edge behavior for invalid or historical series codes, which an agent would want to know before calling.

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?

Only one parameter exists and the schema documents it at 100% coverage with its own example, so the schema carries the load. The description reinforces this with two concrete codes (EDO1136, COI1130), confirming the expected code format, but adds no syntax or lookup rules beyond that. 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+resource ('Details of one Polish retail treasury savings bond series by its code') and enumerates exactly which fields are returned (terms, margin, early redemption fee, per-period interest rate). The word 'one ... by its code' implicitly separates it from the sibling offer-listing tool, but that contrast is never made 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?

Usage is only implied: an agent infers it should call this when it already has a series code and needs the terms. There is no statement of when to prefer get_polish_savings_bonds_offer instead, nor any prerequisite or exclusion, so the agent must reason about routing on its own.

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 and openWorldHint=false; the description goes beyond them by naming the authoritative source (official Ministry of Finance issue letters) and enumerating exactly which figures come back (series code, term, first-period rate, inflation margin, early redemption fee). It does not discuss staleness/refresh cadence, which is the one notable gap for a 'currently on sale' snapshot.

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 well-formed sentence that front-loads the resource and scope before the enumeration of returned fields. The eight-token bond-code list is dense but informative rather than padding; nothing is redundant with the schema or annotations.

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 no output schema and no parameters, the description carries the return-value burden and does so by listing the five returned attributes and their provenance. An agent knows what it will receive; only freshness/caching behavior and the explicit sibling routing remain unstated.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the documented baseline for a parameterless schema is 4. The description correctly avoids inventing filter options that don't exist.

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 (Polish retail treasury savings bonds) and an explicit scope (those currently on sale), plus the exact family codes OTS/ROR/DOR/TOS/COI/EDO/ROS/ROD and the fields returned. It implicitly separates itself from get_polish_savings_bond_series via the 'currently on sale' qualifier, though it never names that sibling outright.

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 'currently on sale' framing implies when this tool applies versus a broader series lookup, but there is no explicit statement of when to prefer it over get_polish_savings_bond_series or get_retail_government_bonds_by_country. Usage must be inferred from the adjectives rather than read from a routing sentence.

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 and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: the no-argument call returns aggregate category counts rather than an error or empty list, and results carry an official source per country — a real disclosure about output 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 tight clauses with no filler, and the payout-structure enumeration is informative rather than noise. The lack of a leading verb slightly delays comprehension, but nothing is wasted.

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 no output schema available, the description does the necessary work of stating what comes back in both modes, including the per-country official source. An agent can call this correctly from the description alone; only the sibling-routing guidance 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 the schema already explains English/Polish names and ISO codes, so format is handled. The description adds what the schema does not: what omitting the parameter actually does, which is the single most consequential semantic fact about this optional parameter.

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

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

The description names the specific resource (retail government bond issuance and payout structures across 195 countries) with unusual precision, and the coverage of 'all 195 countries, with the official source' implicitly separates it from the Poland-specific siblings. It lacks an explicit verb ('Returns...' / 'Look up...') so the first read is descriptive rather than action-oriented, but the subject matter is unmistakable.

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 does define two operating modes — pass a country for that country's details, omit it for category counts and the inflation-plus-margin list — which is real usage guidance. However, it never addresses when to choose this tool over the Polish savings bond siblings, and no exclusions or prerequisites are stated.

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