Rozbij Bank - Polish bank offers

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds the 19% Belka tax rule and return value components, providing useful behavioral context beyond annotations. No contradictions.

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

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

A single sentence that front-loads the purpose and then lists the outputs. No waste, perfectly structured for quick agent scanning.

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 calculation tool with full schema coverage and annotations, the description fully covers what the agent needs: inputs, tax rule, and outputs. No output schema exists, but the description compensates by listing return values.

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% — every parameter has a description. The description adds context (Polish tax) but doesn't detail parameter syntax beyond what the schema already provides. 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 uses a specific verb ('Calculate') and resource ('deposit/savings interest'), and clearly distinguishes from siblings (which are search/get tools). It also lists the outputs, making purpose 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?

The description clearly implies when to use (when interest with Polish tax is needed) and is contextually distinct from sibling search tools. It doesn't explicitly mention alternatives or exclusions, but the sibling names make the calculation role obvious.

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 indicate this is safe, read-only, and idempotent. The description adds that it returns bank titles intended as filter values, which is useful context beyond the annotations. However, it does not describe output structure or pagination.

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, no waste. The first sentence identifies the purpose, the second gives usage guidance, and the third clarifies matching behavior.

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

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

Given no parameters and no output schema, the description covers the tool's purpose and output usage completely. It also references sibling tools, giving contextual completeness.

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

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

The tool has zero parameters, so there is nothing to explain. The description adds no parameter details because none exist, which 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 clearly states the tool gets a list of all banks, using a specific verb and resource. It differentiates itself from sibling search tools by positioning itself as the source of bank names for filters.

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 tells agents to use the returned bank titles as bankName filter in specific sibling tools, and explains substring matching behavior. This gives clear direction on when to call this tool before searches.

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 description need not restate them. It adds content scope (banking tips, promotion guides, financial education) but no additional behavioral traits like pagination, limits, or authentication. With annotations covering the safety profile, a neutral 3 is appropriate.

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

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

The description is two sentences, front-loaded with the primary purpose ('Get published blog articles') followed by a concise list of content types. Every word earns its place, with no fluff or repetition.

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

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

For a zero-parameter, read-only tool with no output schema, the description adequately conveys that it returns blog articles and the topics covered. It does not specify the return format or article metadata, but given the simplicity of the tool and strong annotations, this does not hinder agent selection or invocation.

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

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

The tool has zero parameters, so there are no parameter semantics to describe. Per the baseline rule, 0 parameters earns a 4. The description does not need to compensate for any schema gaps since the schema is fully complete (empty object).

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

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

The description clearly states 'Get published blog articles from RozbijBank' with a specific verb and resource, distinguishing it from sibling tools like GetBanks or SearchDeposits. It also adds context on content categories (banking tips, promotion guides, financial education), making the purpose 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?

The description implies usage when blog articles are needed, and clearly differentiates the content focus from sibling tools. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, so the guidance remains implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds a critical behavioral trait beyond annotations: the tool returns expired promotions and requires checking the IsExpired flag. This is valuable context for correct invocation.

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: the first clearly states purpose and content, the second conveys a critical behavioral warning in all-caps 'IMPORTANT'. Every sentence earns its place, front-loaded with the core action.

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 GET-style tool with a single parameter and no output schema, the description covers the purpose and a key caveat. It mentions the IsExpired flag but does not detail the full return shape or behavior for invalid IDs. Still, it is complete enough for an agent to invoke correctly in most cases.

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?

There is only one parameter (promoId) with 100% schema coverage, including that it comes from SearchPromotions results. The description does not add extra parameter syntax or format information, so a baseline score of 3 is appropriate per the guidelines.

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 action ('Get detailed information about a specific bank promotion') and lists the content returned (step-by-step tasks, hidden fees, traps, expert recommendation). It clearly distinguishes this from sibling tools like SearchPromotions (which lists promotions) and GetReferralCode.

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 schema notes the promoId comes from SearchPromotions results, implying a workflow of search then get details. The description also warns to check IsExpired before recommending, an important usage guideline. However, it doesn't explicitly state 'use this when' or mention alternatives/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 already declare the tool read-only and idempotent, so the safety profile is covered. The description adds no extra behavioral details such as return format, caching, or error handling; it only restates the basic function.

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

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

The description is two concise sentences with the core purpose front-loaded. Every word adds value, and there is no redundant 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?

For a simple read-only tool with one fully documented parameter, the description is mostly adequate. It could mention what the response contains (the code) and any prerequisites like the bank being supported, but these are largely inferable from the tool name and description.

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

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

The input schema fully covers the single bankName parameter with a description and example, so the schema does the heavy lifting. The tool description does not add additional parameter semantics beyond identifying the bank as the target.

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

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

The description clearly states the tool's verb (Get) and resource (referral/invitation code for a specific bank), making its purpose obvious. However, it does not explicitly differentiate from sibling tools like GetBanks or GetPromotionDetails, so it misses the top score.

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

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

The description implies the tool is for fetching a referral code to use when opening a bank account, but it provides no explicit guidance on when to choose this tool over alternatives. The context is present but not clearly framed as a selection criterion.

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 disclose read-only, idempotent, and non-destructive behavior. The description adds timezone context (Europe/Warsaw), which is valuable beyond annotations. It does not cover return format, but for a zero-parameter tool this is acceptable.

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

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

The description is a single sentence followed by a usage example. It is front-loaded with the core purpose and contains no redundant 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?

Given the trivial complexity (no parameters, no output schema, no side effects), the description is fully adequate. It states the outcome, timezone, and a typical use case. It could specify the date format, but this is not critical for the tool's operation.

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

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

The tool has zero parameters, so baseline is 4. The description adds semantic meaning by clarifying that 'today' is defined in Warsaw timezone, which is relevant to the result.

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 'Returns' and resource 'today's date' with timezone specification, clearly distinguishing it from sibling tools that handle banks, deposits, promotions, etc.

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

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

The description explicitly states when to use this tool ('Use this when you need to know the current date') with an example (checking promotion deadlines). It does not list alternatives, but no competing date tool exists among siblings, so the guidance is adequate.

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, so the safety profile is covered. The description adds that results are sorted by score and are relevant for entrepreneurs/companies, but does not disclose additional behavioral traits such as pagination, rate limits, or the exact meaning of 'compare' beyond the schema.

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

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

Two sentences, front-loaded with the core purpose and a clear default usage instruction. No wasted words; every sentence adds value.

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 straightforward search tool with full schema coverage and read-only annotations, the description adequately covers purpose and default behavior. It does not describe the output format, but no output schema exists and the schema explains the parameters well, so the tool is usable without further context.

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 detailed parameter descriptions, including defaults and aliases. The description does not add any parameter semantics beyond the schema, 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 uses a specific verb ('Search and compare') with a clear resource ('business bank accounts in Poland'), and explicitly distinguishes from sibling tools like SearchPersonalAccounts by scoping to entrepreneurs and companies. It conveys both the action and the target audience without ambiguity.

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

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

The description provides a clear usage context: call with no filters to get all business accounts sorted by score. While it doesn't explicitly mention when not to use it or name alternatives like SearchPersonalAccounts, the sibling tool list makes the distinction obvious, and the instruction about no filters is actionable.

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 as read-only, idempotent, and non-destructive. The description adds context about the output fields and default sorting behavior, which is useful. It does not contradict annotations.

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

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

The description is two sentences, front-loads the purpose, and provides a high-level usage tip without unnecessary detail. Every sentence adds value.

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

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

Given the tool's straightforward read-only search nature, the description covers the essential aspects: what it searches, what it returns, and how to retrieve all results. The schema handles parameter details, and sibling tool names clarify the domain. The absence of an output schema is mitigated by the description listing key output fields.

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

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

The schema provides 100% coverage for all six parameters with detailed descriptions. The description adds a practical hint about the no-filters call and the relationship between sort options and output fields, enhancing the schema's baseline information.

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

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

The description clearly states the tool's function: to search and compare credit cards in Poland. It specifies return values such as fees, RRSO, grace period, rewards, and moneyback, which distinguishes it from sibling search tools for other financial products.

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

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

The description gives clear context for when to use the tool (when searching/comparing credit cards) and explicitly mentions that calling with no filters returns all cards sorted by score. However, it does not explicitly discuss alternatives or when not to use it, though sibling tool names suggest the distinction.

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 convey the read-only, idempotent, non-destructive nature. The description adds useful behavioral context by detailing what is returned (currencies, fees, exchange spread, convenience features) and the default sorting by score when no filters are applied. No contradiction with annotations.

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

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

Two concise sentences: the first communicates purpose and output content, the second clarifies default behavior. No redundancy or fluff, and the most important information 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?

For a read-only search tool with a fully self-describing schema and clear annotations, the description sufficiently covers purpose, output fields, and default behavior. It does not need to explain return structure in depth since it already mentions key output attributes.

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% with detailed descriptions and defaults for all 7 parameters. The description adds minimal extra meaning beyond the schema—the no-filters behavior is essentially implied by the defaults. Thus it does not elevate above 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?

The description clearly states it 'Search[es] and compare[s] foreign currency accounts' in Poland, using a specific verb and resource. It distinguishes itself from sibling account-search tools by focusing on currency accounts, not personal, savings, or business accounts.

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 provides clear context on when to use the tool (searching/comparing currency accounts) and even explains the default no-filters behavior. However, it does not explicitly mention alternatives or situations where sibling tools would be more appropriate, so it lacks explicit 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 already declare read-only and idempotent, so the safety profile is covered. The description adds useful behavioral context: the default sort order, the ability to get all deposits with no filters, and troubleshooting advice for empty period results. This goes beyond the annotations without contradicting them.

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

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

The description is three sentences, front-loaded with the core purpose, followed by practical usage notes. Every sentence contributes meaningful information without fluff or repetition.

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

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

With no output schema, the description should clarify what the returned data looks like. It only says 'returns interest rates by amount and period,' which is vague and somewhat inconsistent with the schema (no 'amount' parameter exists). It doesn't mention that results include bank names or deposit product specifics, which would be expected from the filterable fields. This leaves some ambiguity for the agent.

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 all six parameters fully documented (e.g., allowed values, defaults, examples). The tool description adds no additional parameter-level information, so the baseline score of 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 clearly states the tool searches and compares bank deposits (lokaty) in Poland, and specifies that it returns interest rates. This distinguishes it from sibling tools like SearchSavingsAccounts and GetBanks, which handle other account types or banks. The verb 'search and compare' is specific and matches the tool's name and behavior.

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

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

Provides clear usage context: call with no filters to get all deposits sorted by rate, and suggests fallback strategies for empty results (remove period filter or try adjacent periods). However, it does not explicitly mention when to use this tool over sibling alternatives (e.g., SearchSavingsAccounts), 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 readOnlyHint and idempotentHint, and the description adds meaningful behavioral context by detailing the output contents (fees, features, rewards, scores) and the default sort behavior. This goes beyond just restating the safe-read nature but does not address potential nuances like result size or error handling.

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

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

The description is two sentences, front-loaded with the core action and resource, and every clause adds value (scope, return details, default behavior). There is no redundancy or filler.

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

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

For a five-parameter tool with no output schema, the description sufficiently explains the tool's purpose, return content, and default invocation. The schema handles parameter-level details, and the description covers the high-level behavior. It could mention result ordering/pagination more explicitly, but overall it is complete enough for an agent to use 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%, with each parameter already documented in detail (e.g., 'sortBy' explains allowed values, 'bankName' explains substring matching). The description mentions default sorting but adds little beyond what the schema provides, so the baseline score of 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 uses a specific verb ('Search and compare') and clearly identifies the resource ('personal bank accounts in Poland'), distinguishing it from sibling tools like SearchBusinessAccounts and SearchDeposits. It also states what is returned (fees, features, rewards, scores), leaving no ambiguity about the tool's function.

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

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

The description provides clear usage context by explaining that calling with no filters returns all accounts sorted by score. It implies the tool is for comparative search but does not explicitly name alternative tools or specify when not to use it, which prevents a score of 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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: promotions are time-limited, located in Poland, and include tasks, rewards, and deadlines. No contradiction with annotations exists.

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

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

The description is exactly two sentences, front-loading the core purpose and differentiation. Every clause earns its place: the first defines the tool, the second handles alternatives and usage hints. No redundancy or filler.

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

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

Given the tool's moderate complexity (5 params, no required fields, complete schema) and strong annotations, the description covers the essentials: what it does, how it differs from siblings, and a usage pattern. A mention of return format would be nice, but with no output schema, it is not mandatory.

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

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

The input schema provides 100% coverage for all five parameters, thus the baseline of 3 applies. The description's comment 'Call with no filters to get all active promotions' adds a small usage nuance but does not significantly enhance the schema's parameter descriptions.

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

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

The description clearly states the tool searches time-limited bank promotions in Poland, specifying the resource (promotions) and scope (time-limited, tasks, rewards, deadlines). It also explicitly distinguishes from permanent product offers by naming sibling tools, making its purpose 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?

The description explicitly says to use Search*Accounts/SearchDeposits for permanent offers, providing a clear alternative. It also gives a practical usage pattern: 'Call with no filters to get all active promotions,' which guides when and how to use the tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds useful return-field info ('interest rates, fees, and conditions') and default sorting, but it misrepresents the output scope by saying 'all accounts' when the default limit caps results at 10. This contradicts the schema's limit parameter and is a meaningful behavioral disclosure failure.

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

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

The description is concise and front-loaded, with a clear first sentence and an actionable second sentence. However, the second sentence contains an inaccuracy about 'all accounts,' which makes the conciseness slightly less reliable.

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

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

Given the 6-parameter schema and no output schema, the description explains the return content and default sort but misses the limit parameter's effect on 'all accounts.' It also doesn't elaborate on how to combine filters or handle edge cases, so the context is incomplete for fully correct usage.

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%, with every parameter having a description, so baseline is 3. The description doesn't add parameter-specific meaning beyond what the schema provides; the comment about 'no filters' is generic and doesn't clarify parameter interplay.

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

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

The description clearly states the tool's purpose: 'Search and compare savings accounts (konta oszczędnościowe) in Poland. Returns interest rates, fees, and conditions.' It uses a specific verb+resource and distinguishes itself from siblings like SearchBusinessAccounts and SearchPersonalAccounts.

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

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

The description gives a concrete usage suggestion: 'Call with no filters to get all accounts sorted by interest rate.' However, this is misleading because the schema's default limit is 10, so 'all accounts' is inaccurate without increasing the limit. It doesn't mention alternatives or conditions for using other filters.

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