CDR Explorer allows access to the Australian Consumer Data Right Product Data from Banks and Non-Bank Lenders. https://cdrexplorer.com.au/api/mcp for the anonymous endpoint.
Scored across 18 tools
Several tools have unclear boundaries, especially get_product_constraints vs get_product_constraints_by_type, whose descriptions are nearly identical. The singular/plural product tools and by_type/by_event variants add further ambiguity, while hello is the only clearly distinct tool.
Most tools follow a consistent get_<resource>_<attribute> snake_case pattern, with predictable plural and by_type/by_event suffixes. The hello tool breaks the pattern, but this is a minor deviation from an otherwise coherent naming scheme.
At 18 tools, the set is on the heavier side and includes several variants that could potentially be consolidated via parameters. Some tools like hello do not clearly earn their place in the collection.
The server covers many product attribute areas such as features, fees, eligibility, constraints, and rates, but there is no way to list or search for products to obtain a Product ID. This is a significant gap that will block agents from proceeding through common workflows.
Returns data holders filtered by product category (e.g. TRANS_AND_SAVINGS_ACCOUNTS, RESIDENTIAL_MORTGAGES, CRED_AND_CHRG_CARDS)
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The product category to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only and idempotent, so the safety profile is covered. The description adds no further behavioral details such as pagination, ordering, or response shape, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that communicates the action, resource, filter, and examples without unnecessary details. Every word earns its place.
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 single-parameter read-only query with no output schema, the description and schema are adequate. It could mention the shape of the returned data holder list, but this is a minor gap given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is documented. The description adds value by giving concrete example category values (e.g., TRANS_AND_SAVINGS_ACCOUNTS), which is especially helpful since no enum is defined.
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 ('Returns data holders') with a clear filter dimension ('product category') and provides concrete example values. This distinguishes it from sibling get_data_holders_by_industry, which filters by a different dimension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the category filter and the sibling name get_data_holders_by_industry, but there is no explicit statement of when to use this tool versus alternatives. It does not name any alternative or exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all CDR-registered data holders (banks and institutions) for a given industry. Returns names, brand IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | Industry to filter by. Allowed values: banking, energy, telco, non-bank-lending. Leave empty to return all industries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds output details (returns names, brand IDs) and contextual info (CDR-registered), providing value beyond the annotations. No contradictions; the description aligns with the read-only nature.
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 with zero filler. The purpose is front-loaded, and the output specification is included efficiently. Every word contributes.
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 simple with one optional parameter and no output schema. The description tells the agent what it does and what it returns, which is sufficient for correct invocation. No critical missing information.
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 covers the single parameter 'industry' with 100% description coverage, including allowed values and default behavior. The tool description adds no additional meaning 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 clearly states the verb 'Find' and the resource 'CDR-registered data holders', with a filter by industry. It also specifies the returned data (names, brand IDs). However, it does not explicitly distinguish from the sibling tool get_data_holders_by_category, which operates on category rather than industry, so differentiation is implied but not 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?
The description implies usage when filtering by industry, but it does not state when to use this tool versus alternatives like get_data_holders_by_category. There is no explicit when/when-not guidance or mention of alternate tools, leaving the agent to infer based on the parameter name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a list of available product categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint and idempotentHint, so the safety profile is covered. The description adds only that the result is a 'list' and that it contains 'available' categories, which is mild extra context but no deeper behavior such as ordering, pagination, or potential errors.
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 contains exactly the necessary information and no filler. Every word contributes to the meaning.
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 listing tool, the sentence is nearly complete. It could mention what a category looks like or that no pagination/filtering exists, but the low complexity and strong annotations make the absence non-critical.
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 are zero parameters and schema description coverage is 100%, so the empty input schema is fully self-documenting. The description need not compensate for parameter ambiguity, meeting the baseline for a parameter-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and object: it 'Returns a list of available product categories.' The resource is specific enough to distinguish from siblings like constraints, fees, or rates, but it does not explicitly mark itself off against any sibling, so it stops just short of full 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?
The intended use is implied: call this when you need the list of available product categories. There is no explicit guidance about when not to use it or which sibling alternative to prefer, though for a zero-parameter list tool the use case is fairly evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the constraints that apply to a specific banking product (identified by Product ID) offered by a Data Holder, as defined by the CDR Banking standards. Constraints describe eligibility and usage limits such as minimum/maximum loan-to-value ratio (MIN_LVR, MAX_LVR), minimum/maximum balance, minimum/maximum credit limit, and minimum deposit. Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The unique identifier of the product whose constraints should be retrieved | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds domain context and a prerequisite, but does not describe return format, error behavior, or other operational traits beyond that.
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 efficient sentences: the main purpose, the meaning of constraints with useful examples, and the prerequisite sequence. No wasted words, and the important invocation context 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 simple read-only two-parameter tool, it covers the required parameters and the prerequisite call. The lack of an output schema is partially mitigated by describing constraint types, but it could be more complete about whether all constraint types are returned or how the response is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description mostly repeats that productId identifies the product and dataHolderBrandId must come from GetDataHoldersByCategory, adding little beyond 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?
The description clearly states the tool returns constraints for a specific banking product identified by Product ID, which is a specific verb and resource. It does not explicitly distinguish itself from the similar sibling get_product_constraints_by_type, relying mainly on the singular 'specific product' phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context by instructing the agent to call GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID. However, it does not mention when to prefer this tool over get_product_constraints_by_type or get_products_constraints, so alternatives are not explicitly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the constraints that apply to a specific banking product (identified by Product ID) offered by a Data Holder, as defined by the CDR Banking standards. Constraints describe eligibility and usage limits such as minimum/maximum loan-to-value ratio (MIN_LVR, MAX_LVR), minimum/maximum balance, minimum/maximum credit limit, and minimum deposit. Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The unique identifier of the product whose constraints should be retrieved | |
| constraintType | Yes | The CDR standard constraintType to filter by (e.g. MIN_BALANCE, MAX_BALANCE, MIN_LIMIT, MAX_LIMIT, MIN_LVR, MAX_LVR, OPENING_BALANCE, OTHER) | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is covered and there is no contradiction. The description adds useful semantic context about what constraints are and gives example types, but it does not describe response shape, empty behavior, or any additional behavioral traits.
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 with no filler: the first sentence states the purpose, the second gives useful constraint examples, and the third gives the key prerequisite. It is appropriately sized and 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 simple read-only tool with three required parameters and no output schema, the description covers what the tool returns, what the value means, and how to obtain the prerequisite ID. It is complete enough for an agent to call the tool correctly, though it could have been more explicit about the constraintType parameter.
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 baseline is 3. The description adds extra meaning by explaining how to obtain a valid Data Holder Brand ID and by illustrating constraint types such as MIN_LVR, MAX_LVR, MIN_BALANCE, and MAX_BALANCE, helping the agent choose appropriate enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: returns constraints for a specific banking product identified by Product ID, and it gives concrete constraint examples. It does not explicitly say the results are filtered by constraintType, so it does not differentiate itself from get_product_constraints in text, but the title makes the by-type behavior recoverable.
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 clear prerequisite: use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID. It does not contrast this tool with get_product_constraints or other siblings, but it provides enough context for an agent to know how to prepare the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the deposit rates for a banking product from a CDR data holder. Returns fixed, variable, bonus, introductory, and market-linked rates, including tiered rates and any applicability conditions. Use get_data_holders_by_category first to find a valid dataHolderBrandId. Leave depositRateType empty to return all deposit rates.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The unique identifier of the product whose features should be retrieved | |
| depositRateType | No | Filter by deposit rate type (e.g. FIXED, VARIABLE). Leave empty for all types. | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, and the description adds useful return behavior: it lists the rate categories returned, tiered rates, applicability conditions, and the default all-rates behavior when depositRateType is left empty. It omits FLOATING and BUNDLE_BONUS from the enumeration, though those are visible in the schema enum.
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 focused sentences front-load the tool's purpose, then give the prerequisite and default-filter behavior. No filler or redundant restatement of the tool name.
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, schema-rich tool, the description covers what is returned, the default filter behavior, and the prerequisite data holder lookup. It is not quite exhaustive because it does not mention the two omitted enum rate types or error/pagination behavior, but those are not critical for selecting and invoking this simple 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 all three parameters are already documented. The description mostly repeats the depositRateType empty-for-all behavior and the dataHolderBrandId prerequisite rather than adding new parameter semantics, leaving it at the baseline for high schema coverage.
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 ('Get'), resource ('deposit rates'), scope ('for a banking product from a CDR data holder'), and output content (rate types plus tiering/conditions). This clearly distinguishes it from sibling rate tools such as get_product_lending_rates.
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 an explicit prerequisite: call get_data_holders_by_category first to obtain a valid dataHolderBrandId, and explains how the depositRateType filter behaves. It does not explicitly contrast with alternative siblings like get_product_lending_rates, but the deposit-rate scope makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the eligibility of a specific banking product (identified by Product ID) offered by a Data Holder, as defined by the CDR Banking standards (BankingProductEligibilityV2). Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The unique identifier of the product whose features should be retrieved | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's safety profile is covered. The description adds useful context that the tool follows CDR standards and requires a valid Data Holder Brand ID obtained via GetDataHoldersByCategory. This goes beyond the annotations without contradicting them, though it doesn't disclose potential errors or rate limits.
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 with no filler. The first sentence states the purpose and standard, the second provides a key usage prerequisite. It is front-loaded with the core function and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and no output schema, the description covers the essential purpose and a crucial prerequisite. It does not mention the singular vs. plural distinction (get_products_eligibility), but the title and wording imply singleton use. Given the tool's simplicity, the description is sufficiently complete.
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 documented in the input schema. The description adds a small extra hint that the dataHolderBrandId comes from GetDataHoldersByCategory, but productId semantics are essentially the same as the schema. Given high schema coverage, the description adds marginal value, earning a 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?
The description clearly states the tool returns the eligibility of a specific banking product, identified by Product ID, and references the CDR Banking standards (BankingProductEligibilityV2). It distinguishes from sibling tools by focusing on eligibility rather than features, fees, or rates, and the title reinforces the 'Single' product scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.' However, it does not explicitly mention when to avoid this tool in favor of alternatives (e.g., get_products_eligibility for multiple products) or contrast with other singular product tools like get_product_features. Guidance on selection is partially implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the features and benefits of a specific banking product (identified by Product ID) offered by a Data Holder, as defined by the CDR Banking standards (BankingProductFeatureV4). Features describe product capabilities and benefits such as offset accounts (OFFSET), redraw facilities (REDRAW), loyalty programs (LOYALTY_PROGRAM), interest-free periods (INTEREST_FREE), additional cards (ADDITIONAL_CARDS), digital wallets (DIGITAL_WALLET) and cashback offers (CASHBACK_OFFER). Use this tool for product capabilities; use GetProductConstraints for eligibility and usage limits. Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The unique identifier of the product whose features should be retrieved | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds semantic context about CDR BankingProductFeatureV4 and example feature types, but does not disclose response format, pagination, or error behavior. It adds some useful context but no significant behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by useful feature examples and routing guidance. The feature example list is slightly long but helps set expectations about the value of the tool, so every sentence contributes meaningful 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 two-parameter read-only lookup tool, the description is fairly complete: it states the return subject, provides domain context, names the sibling tool for constraints, and gives a prerequisite. No output schema exists, but the description's opening sentence sufficiently conveys what is returned.
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 input schema already documents both productId and dataHolderBrandId. The description adds a reference to GetDataHoldersByCategory as the source of dataHolderBrandId, which slightly reinforces the prerequisite, but it does not materially extend the parameter semantics beyond 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?
The description clearly states it returns features and benefits for a specific banking product identified by Product ID, with concrete examples of feature types. It distinguishes from get_product_constraints (eligibility/usage limits), but does not explicitly differentiate among close siblings like get_product_features_by_type or get_products_features, though 'single product' and parameter context imply the distinction.
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 explicit guidance: 'Use this tool for product capabilities; use GetProductConstraints for eligibility and usage limits.' It also states a prerequisite workflow: 'Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.' This leaves little ambiguity about when and how to call the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter Product by a feature type (identified by featureType) of a specific banking product (identified by Product ID) offered by a Data Holder, as defined by the CDR Banking standards (BankingProductFeatureV4). Features describe product capabilities and benefits such as offset accounts (OFFSET), redraw facilities (REDRAW), loyalty programs (LOYALTY_PROGRAM), interest-free periods (INTEREST_FREE), additional cards (ADDITIONAL_CARDS), digital wallets (DIGITAL_WALLET) and cashback offers (CASHBACK_OFFER). Use this tool for product capabilities; use GetProductConstraints for eligibility and usage limits. Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID against an associated Category.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The unique identifier of the product whose features should be retrieved | |
| featureType | Yes | The CDR standard feature type to filter by (e.g. OFFSET, REDRAW, LOYALTY_PROGRAM, INTEREST_FREE, DIGITAL_WALLET, CASHBACK_OFFER) | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds scoping constraints and CDR-standard context, but does not disclose return format, pagination, or result behavior beyond the basic filtering operation.
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, each carrying distinct weight: operation/standards, feature-type examples, and usage routing/prerequisites. The list of feature-type examples is somewhat redundant with the schema enum, preventing a 5.
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-only tool the description covers the operation, standards, examples, sibling routing, and the prerequisite for dataHolderBrandId. The only gap is that with no output schema it does not describe the shape of the returned features, though the name and opening sentence make the return concept inferable.
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 productId, dataHolderBrandId, and the full featureType enum with descriptions. The description restates the enum examples and maps them to the domain, but adds little syntactic or format information beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific operation—'Filter Product by a feature type'—and names the exact scope: a specific banking product identified by Product ID and offered by a Data Holder. It also references the CDR standard and explicitly distinguishes this from GetProductConstraints, so an agent can separate product capabilities from constraints.
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 explicit routing: 'Use this tool for product capabilities; use GetProductConstraints for eligibility and usage limits.' It also gives a concrete prerequisite, directing the agent to GetDataHoldersByCategory to obtain a valid dataHolderBrandId, which fills the gap otherwise left to the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the fees of a specific banking product (identified by Product ID) offered by a Data Holder, as defined by the CDR Banking standards (BankingProductFeeV2). Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The unique identifier of the product whose features should be retrieved | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and idempotentHint annotations already disclose the safety profile, and the description's 'Returns' wording is consistent—no contradiction. It adds a useful reference to the CDR BankingProductFeeV2 standard, but otherwise does not describe pagination, error behavior, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states what the tool returns and its standard, and the second provides the key prerequisite. The most important identifying 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 simple read-only two-parameter retrieval tool, this is largely complete: it names the resource, the required identifiers, the governing standard, and the upstream dependency. The lack of an output schema makes a bit more return-format detail desirable, but the description is adequate for initial selection.
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 both parameters. The description clarifies that Product ID selects the product whose fees are returned and names the prerequisite for dataHolderBrandId, but much of that repeats what the schema already 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 clearly states a specific verb and resource: it returns fees for a single banking product identified by Product ID. It implicitly distinguishes from the plural sibling get_products_fees by emphasizing 'specific product,' but it does not explicitly differentiate itself from get_product_fees_by_event.
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 clear prerequisite: call GetDataHoldersByCategory first to obtain a valid dataHolderBrandId. However, it provides no exclusions or guidance about when a sibling tool such as get_product_fees_by_event or get_products_fees would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter Product by a fee event (identified by feeEvent) of a specific banking product (identified by Product ID) offered by a Data Holder. Use this tool for product fees; use GetProductConstraints for eligibility and usage limits. Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID against an associated Category.
| Name | Required | Description | Default |
|---|---|---|---|
| feeType | Yes | The CDR standard feeType (e.g. CASH_ADVANCE, DEPOSIT, DISHONOUR, ENQUIRY, EVENT, EXIT, FORGONE_OPPORTUNITY, PAYMENT, PERIODIC, PURCHASE, TRANSACTION, UPFRONT, VARIABLE, OTHER) | |
| productId | Yes | The unique identifier of the product whose features should be retrieved | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint and idempotentHint, lowering the burden. The description adds the filtering behavior and a data-holder prerequisite, but introduces the nonexistent term feeEvent and gives no indication of what the response contains; the mismatch with the schema's feeType undermines the added context.
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 reasonably short sentences with the core action up front; there is little fluff. The main weakness is not length but the incorrect feeEvent terminology and the decision to name GetProductConstraints as the sibling alternative instead of the more relevant get_product_fees.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the mandatory prerequisite and gives a coarse boundary against constraints tools. For a simple filtered read with full schema coverage this is mostly adequate, but the missing distinction from get_product_fees and the feeEvent/feeType inconsistency leave a real gap in the agent's ability to choose and call the tool 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 baseline is 3, but the description actively confuses parameter semantics by saying the fee event is identified by feeEvent when the schema parameter is feeType. It also describes productId as retrieving 'features' rather than fees, which is misleading despite the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action and object: filtering a banking product's fees by a fee event and product ID. However, it refers to a 'feeEvent' identifier while the actual schema parameter is 'feeType', and it does not differentiate this tool from the sibling get_product_fees, so precision is imperfect.
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 a helpful prerequisite (call GetDataHoldersByCategory first) and routes constraint/eligibility questions to GetProductConstraints. But it fails to contrast this fee-by-event tool with the closely related sibling get_product_fees, leaving the agent without an explicit when-not-to-use signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the lending rates of a specific banking product (identified by Product ID) offered by a Data Holder, as defined by the CDR Banking standards (BankingProductLendingRateV2). Use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes | The unique identifier of the product whose features should be retrieved | |
| loanPurpose | No | Filter by loan purpose (e.g. OWNER_OCCUPIED, INVESTMENT). Leave empty for all. | |
| repaymentType | No | Filter by repayment type. (e.g. INTEREST_ONLY, PRINCIPAL_AND_INTEREST). Leave empty for all. | |
| lendingRateType | No | Filter by lending rate type (e.g. FIXED, VARIABLE). Leave empty for all types. | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds context about CDR standard conformance and product scoping, but it does not disclose response shape, pagination, or error behavior. With annotations in place, this is adequate but not rich.
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 sentences with the core verb-resource pair front-loaded and a useful prerequisite in the second sentence. No filler, repetition, or irrelevant detail.
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?
Combined with the fully described schema and read-only annotations, the call pattern is complete: required parameters, optional filters, and prerequisite lookup are all covered. The main gap is the absence of an output schema and no explicit statement of the return shape, though referencing BankingProductLendingRateV2 partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters, including enums and defaults. The description adds some clarifying context for productId and dataHolderBrandId, but it offers no additional meaning for loanPurpose, repaymentType, or lendingRateType beyond what the schema provides.
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 names the resource precisely: 'lending rates of a specific banking product (identified by Product ID) offered by a Data Holder'. This clearly distinguishes it from sibling rate tools like get_product_deposit_rates, and the CDR standard reference reinforces the tool's exact purpose.
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 instructs the agent to call GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID, which is strong sequencing guidance. However, it does not explicitly state when not to use this tool or name alternative sibling tools, 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.
Returns the constraints that apply to multiple banking products (identified by an array of Product IDs) offered by a single Data Holder, as defined by the CDR Banking standards. Results are grouped by Product ID, making this tool ideal for comparing eligibility and usage limits across products such as minimum/maximum loan-to-value ratio (MIN_LVR, MAX_LVR), minimum/maximum balance, minimum/maximum credit limit, and minimum deposit. Use GetProductConstraints for a single product, and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productIds | Yes | An array of unique product identifiers whose constraints should be retrieved and compared | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only/idempotent behavior, and the description adds useful behavioral detail: results are grouped by Product ID and contain constraint types like MIN_LVR, MAX_LVR, and minimum deposit. This goes beyond what annotations alone provide.
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, each earning its place: the operation, the grouping benefit with concrete examples, and routing/prerequisite guidance. No filler 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 tool with no output schema, the description communicates the key return shape (grouped by Product ID), what constraints look like, and the required prerequisite. It could be slightly more explicit about return fields or error cases, but is likely sufficient for selection and 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?
Schema description coverage is 100%, and the schema already documents productIds and dataHolderBrandId clearly. The description adds product-comparison context and the source of dataHolderBrandId, but no new parameter syntax or format details.
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 constraints for multiple banking products by Product IDs, grouped by Product ID. It also differentiates from the singular get_product_constraints tool, so an agent can distinguish them.
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 tells the agent to use GetProductConstraints for a single product and to call GetDataHoldersByCategory first for a valid Data Holder Brand ID. This gives clear when-to-use, alternative, and prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the eligibility of multiple banking products (identified by an array of Product IDs) offered by a single Data Holder, as defined by the CDR Banking standards (BankingProductEligibilityV2). Use GetProductEligibility for a single product, and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productIds | Yes | An array of unique product identifiers whose features should be retrieved and compared | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description does not contradict those. The description adds scoping context such as 'multiple products' and 'single Data Holder,' but it does not disclose additional behavioral details like authentication, errors, or return shape. With annotations covering the safety profile, this is adequate but not rich.
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 with no filler. The main purpose is front-loaded, and the second sentence efficiently covers both the singular alternative and the prerequisite 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 a simple two-parameter, read-only CDR endpoint, the description is complete: it states what is returned, links to the standard, gives the precursor call, and names the sibling for the single-product case. No output schema exists, but the CDR standard reference anchors return semantics, and nothing required to invoke the tool 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?
Input schema description coverage is 100%, so the baseline is 3, and the description adds little parameter meaning beyond the schema. It paraphrases that productIds identifies products and that dataHolderBrandId comes from GetDataHoldersByCategory, but the schema already states both. No extra format, validation, or semantics are provided.
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 identifies the exact resource: eligibility for multiple banking products identified by an array of Product IDs for a single Data Holder. It also names the governing standard (BankingProductEligibilityV2), which distinguishes it from the sibling singular get_product_eligibility and other product endpoints.
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 GetProductEligibility for a single product, which clearly frames when this tool is the correct choice. It also states that GetDataHoldersByCategory should be called first to obtain a valid Data Holder Brand ID, giving a clear prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the features and benefits of multiple banking products (identified by an array of Product IDs) offered by a single Data Holder, as defined by the CDR Banking standards (BankingProductFeatureV4). Results are grouped by Product ID, making this tool ideal for comparing features across products (e.g. offset accounts, redraw facilities, loyalty programs, interest-free periods). Use GetProductFeatures for a single product, and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productIds | Yes | An array of unique product identifiers whose features should be retrieved and compared | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: results are grouped by Product ID and limited to a single Data Holder, setting accurate expectations about data scope and structure.
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 with no filler. Purpose is front-loaded, followed immediately by the primary use case, and then by routing to related tools. Every sentence earns its place.
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, two-parameter tool with no output schema, the description is self-sufficient. It covers what the tool returns, how results are organized, the intended use case, the prerequisite for obtaining a valid brand ID, and the sibling tool for single-product 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 description coverage is 100%, so the input schema fully documents both parameters. The description adds a small amount of context by noting the productIds array is for comparison and that dataHolderBrandId must come from GetDataHoldersByCategory, but it does not need to compensate for schema gaps.
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: it returns features and benefits of multiple banking products by Product IDs for a single Data Holder. It explicitly distinguishes itself from the singular sibling 'GetProductFeatures', making the tool's scope and purpose unambiguous.
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 explains when to use this tool: for comparing features across multiple products. It also names the alternative for a single product and instructs callers to use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Products by a feature type (identified by featureType) of multiple products (identified by an array of Product IDs) offered by a single Data Holder, as defined by the CDR Banking standards (BankingProductFeatureV4). Results are grouped by Product ID, making this tool ideal for comparing features across products (e.g. offset accounts, redraw facilities, loyalty programs, interest-free periods). Use GetProductFeatures for a single product, and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productIds | Yes | An array of unique product identifiers whose features should be retrieved and compared | |
| featureType | Yes | The CDR standard feature type to filter by (e.g. OFFSET, REDRAW, LOYALTY_PROGRAM, INTEREST_FREE, DIGITAL_WALLET, CASHBACK_OFFER) | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context about results being grouped by Product ID and the CDR standard used, but it does not describe error behavior, pagination, or what happens when a product ID is invalid. The annotations reduce but do not eliminate this gap.
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 with no filler. The core action and scope come first, followed by the grouping use case and the routing guidance. Every sentence earns its place.
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, idempotent list-style tool with a fully documented input schema, the description is complete enough to invoke correctly. It communicates what the tool returns conceptually, how results are grouped, when to use it, and what prerequisite call is needed.
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 has 100% description coverage and includes a full enum for featureType, so the schema already documents parameter meaning. The description reinforces the relationship between productIds, featureType, and dataHolderBrandId, but it does not add substantial new parameter semantics beyond that.
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 ('Return'), a specific resource ('Products by a feature type'), the inputs ('array of Product IDs'), and the scope ('single Data Holder'). It also distinguishes itself from the singular-product sibling by noting this is for comparing features across multiple 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 explicitly tells the agent when to use this tool ('comparing features across products') and points to the alternative ('Use GetProductFeatures for a single product'). It also provides the prerequisite workflow: call GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the fees of multiple banking products (identified by an array of Product IDs) offered by a single Data Holder, as defined by the CDR Banking standards (BankingProductFeeV2). Use GetProductFees for a single product, and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productIds | Yes | An array of unique product identifiers whose features should be retrieved and compared | |
| dataHolderBrandId | Yes | The unique brand identifier of the Data Holder, as returned by GetDataHoldersByCategory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint and idempotentHint. The description adds scope context (multiple products, single Data Holder, CDR BankingProductFeeV2) but does not disclose failure behavior, empty results, or response-shape details beyond the standard reference.
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 and scope, followed by direct routing to the relevant single-product and prerequisite tools. No filler or redundant restating 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?
For a two-parameter, read-only tool with no output schema, the description covers the return subject, the standard, the prerequisite for the brand ID, and the alternative for single-product queries. It could go further on invalid or duplicate productIds, but the core calling context is complete.
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?
Input schema provides 100% parameter descriptions, so the baseline applies. The description reinforces that productIds is an array and that dataHolderBrandId must come from GetDataHoldersByCategory, but adds little beyond the schema. The schema's productIds description says 'features' rather than 'fees', a minor inconsistency the tool description does not fully remedy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Returns the fees') and resource ('multiple banking products' identified by an array of Product IDs, scoped to a single Data Holder). The explicit contrast with GetProductFees for a single product distinguishes it from its closest sibling.
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?
Offers explicit when-to-use guidance: use GetProductFees for a single product, and call GetDataHoldersByCategory first to obtain a valid DataHolderBrandId. This clearly routes the agent away from this tool when the scope differs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a hello message
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds no additional behavioral context, but it also does not contradict the annotations. For this trivial tool, the annotations carry the behavioral disclosure burden and are sufficient.
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 with no wasted words. It is appropriately sized for a zero-parameter, read-only test tool and front-loads the core behavior immediately.
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 zero parameters, a read-only annotation, and low complexity, the description is largely complete. A minor gap is that it does not specify the format or content of the hello message, but for this trivial tool the omission is not significant.
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 are zero parameters, so the baseline is 4. Schema description coverage is 100% and there is nothing for the description to add beyond confirming the tool takes no input.
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: 'Returns a hello message'. It uses a specific verb and resource, and though it does not explicitly distinguish itself from siblings, the sibling tools are all data-retrieval operations, making this test/ping tool unambiguous.
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 no guidance on when to use this tool versus alternatives. There is no mention of testing connectivity, health checks, or any context that would help an agent decide when 'hello' is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_data_holders_by_industry1 field changedInput schema / properties / industry / enumRemoved value: -[
- "banking",
- "energy",
- "telco",
- "non-bank-lending",
- null
-]get_product_deposit_ratesget_data_holders_by_industryget_product_lending_rates3 fields changedInput schema / properties / lendingRateTypeAdded value: +{
+ "default": null,
+ "description": "Filter by lending rate type (e.g. FIXED, VARIABLE). Leave empty for all types.",
+ "enum": [
+ "BALANCE_TRANSFER",
+ "BUNDLE_DISCOUNT_FIXED",
+ "BUNDLE_DISCOUNT_VARIABLE",
+ "CASH_ADVANCE",
+ "DISCOUNT",
+ "FIXED",
+ "FLOATING",
+ "INTRODUCTORY",
+ "MARKET_LINKED",
+ "PENALTY",
+ "PURCHASE",
+ "VARIABLE",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+}Input schema / properties / loanPurposeAdded value: +{
+ "default": null,
+ "description": "Filter by loan purpose (e.g. OWNER_OCCUPIED, INVESTMENT). Leave empty for all.",
+ "enum": [
+ "INVESTMENT",
+ "OTHER",
+ "OWNER_OCCUPIED",
+ "UNCONSTRAINED",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+}Input schema / properties / repaymentTypeAdded value: +{
+ "default": null,
+ "description": "Filter by repayment type. (e.g. INTEREST_ONLY, PRINCIPAL_AND_INTEREST). Leave empty for all.",
+ "enum": [
+ "INTEREST_ONLY",
+ "OTHER",
+ "PRINCIPAL_AND_INTEREST",
+ "UNCONSTRAINED",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+}get_product_lending_ratesget_data_holders_by_categoryget_product_categoriesget_product_constraintsget_product_constraints_by_typeget_product_eligibilityget_product_featuresget_product_features_by_typeget_product_feesget_product_fees_by_eventget_products_constraintsget_products_eligibilityget_products_featuresget_products_features_by_typeget_products_feeshelloHong Kong Monetary Authority (HKMA) public open API MCP. Keyless.
Australian Bureau of Statistics (ABS) Data API MCP.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
APIs.guru MCP — keyless directory of 2,500+ public APIs and their OpenAPI specs.
Add one secure layer between your agents and this server.
