CDR Explorer allows access to the Australian Consumer Data Right Product Data from Banks and Non-Bank Lenders
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 15 of 15 tools scored. Lowest: 3.5/5.
Several tools have overlapping purposes, most notably get_product_constraints and get_product_constraints_by_type which have nearly identical descriptions. The plural variants and by_type/by_event suffixes create additional ambiguity, though the descriptions for features and fees do clarify their filtering intent.
Most tools follow a 'get_product_/get_products_' pattern, but there is inconsistency between singular and plural forms for the same resource. The suffixes '_by_type' and '_by_event' are used inconsistently (e.g., no plural counterpart for by_event), and the 'hello' tool breaks the naming entirely.
At 15 tools, the set is within a reasonable range for a CDR explorer, though it leans toward the higher end. Many tools are variants of the same core functionality (singular vs. plural, type/event filters), which adds some redundancy but remains manageable.
The toolset covers the essential CDR product aspects: data holders, categories, constraints, eligibility, features, and fees. However, there is no tool to retrieve a product's basic details (e.g., name, description, brand) directly, requiring agents to piece this together from component queries, which is a notable gap.
get_data_holders_by_categoryAInspectReturns 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?
No annotations are provided, so the description carries the full burden. It only states the basic return behavior and gives examples; it does not disclose whether the operation is read-only, any auth requirements, or response format. The verb 'Returns' hints at a read operation, but lacks detail.
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, well-structured sentence that includes useful examples without unnecessary words. It is front-loaded and efficient.
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 parameter and no output schema. The description covers the purpose and examples, but does not define what a 'data holder' is or mention pagination, limits, or return structure, leaving some gaps for an 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?
The schema description for 'category' is generic, but the tool description adds concrete examples of valid category values, which helps the agent understand what to pass. This goes beyond the schema's basic description, enhancing semantic clarity.
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 data holders filtered by product category, with specific examples of valid categories. This distinguishes it from sibling tools that focus on product details rather than data holders.
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 for getting data holders by category through the examples, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. Context is clear enough, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_categoriesAInspectReturns 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only restates the function's action without adding details about ordering, pagination, authentication, or return format, providing minimal insight into the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any filler or redundant information. It is extremely efficient 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?
The tool is simple with no parameters and no output schema, so the description is minimally sufficient, but it lacks any context about how product categories relate to sibling tools or what the structure of the returned list might be. This leaves some ambiguity for an agent deciding whether to call this 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?
The input schema has zero parameters, and the description does not need to compensate for missing parameter documentation. Per the guidelines, a baseline of 4 applies when no parameters exist, and the description appropriately makes no parameter claims.
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 a clear resource ('a list of available product categories'), which clearly identifies what the tool does. It also distinguishes itself from sibling tools, which are about constraints, features, fees, and eligibility rather than categories.
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 the sibling tools, nor does it mention any context such as prerequisites or relationships to other data. It merely states what it returns without indicating how it fits into a broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_constraintsAInspectReturns 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it 'Returns' constraints and explains the domain concept, but it does not mention operational traits like read-only nature, authentication requirements, rate limits, pagination, error behavior, or data source scope beyond 'as defined by CDR Banking standards'.
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 purpose, and every sentence contributes meaning. It avoids fluff and provides essential context without being verbose.
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?
Considering there is no output schema or annotations, the description does a solid job by explaining what constraints are (with examples) and the prerequisite for the dataHolderBrandId. However, it does not describe the response shape (e.g., array of objects) or behavior for invalid IDs, leaving a minor gap for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value: it confirms productId identifies the product and dataHolderBrandId is obtained from GetDataHoldersByCategory, but the schema already explains these parameters. No additional syntax, format, or value 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 clearly states the action ('Returns') and the resource ('constraints that apply to a specific banking product'), distinguishing it from plural variants like get_products_constraints. It also specifies the key identifiers (Product ID, Data Holder Brand ID) and gives concrete examples of constraint types, leaving no ambiguity about the tool's 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?
The description provides a clear prerequisite by instructing to use GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID. However, it does not explicitly contrast this tool with sibling tools such as get_product_constraints_by_type or provide conditions for when to use one over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_constraints_by_typeAInspectReturns 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?
No annotations are provided, so the description must carry the transparency burden. It mentions the nature of constraints (e.g., MIN_LVR, MAX_BALANCE) and the prerequisite, but does not disclose behaviors like empty results, error handling, pagination, or read-only status.
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, front-loaded with purpose, and adds a necessary prerequisite in a separate sentence. No wasted words or redundant detail given the complexity.
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?
Without output schema or annotations, the description should explain return structure and potential edge cases. It lists constraint types and mentions CDR standards, but does not specify the response format or behavior for missing/invalid IDs, leaving gaps.
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 already describes all parameters (100% coverage), so baseline is 3. The description adds value by explaining the meaning of constraint types (e.g., loan-to-value ratio, balance limits) and linking dataHolderBrandId to GetDataHoldersByCategory, enhancing beyond 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 by Product ID, adhering to CDR standards. It distinguishes from sibling tools by focusing on constraint types, though not explicitly naming alternatives.
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 context: use it for constraints of a specific product, and explicitly instructs to call GetDataHoldersByCategory first for a valid Data Holder Brand ID. Does not explicitly mention when not to use alternatives like get_product_constraints, but the prerequisite and focus imply the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_eligibilityAInspectReturns 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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the response follows the CDR BankingProductEligibilityV2 standard, which gives some context about the output format. However, it does not disclose potential errors, authentication requirements, or other behavioral traits, leaving the agent to infer 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 concise, with two sentences that front-load the main purpose and then provide the prerequisite. There is no redundant information, and 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 simple read-only tool with two parameters and no output schema, the description is mostly complete. It explains the purpose, references the standard, and provides a usage prerequisite. However, it does not describe the return value structure or handle edge cases, which would be useful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with a coverage of 100%, and the descriptions for dataHolderBrandId and productId are clear. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate. Note that the productId schema description mentions 'features' instead of 'eligibility', which is a minor inconsistency but not part of the tool description itself.
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, using the verb 'Returns' and specifying the resource as 'eligibility of a specific banking product'. It also distinguishes it from sibling tools like get_product_features and get_product_constraints by focusing specifically on eligibility and referencing the CDR standard.
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 explicit guidance that GetDataHoldersByCategory should be called first to obtain a valid Data Holder Brand ID, which is a clear prerequisite. However, it does not explicitly mention when to avoid using this tool or compare it with alternatives, so it falls 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.
get_product_featuresAInspectReturns 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?
With no annotations, the description does a solid job of explaining behavior: it references the CDR Banking standard, lists example feature codes, and notes a prerequisite. It does not mention error handling or return format, but for a simple read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four purposeful sentences with no wasted words. The list of feature examples is somewhat long but each item is relevant and helps illustrate the domain.
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 tool with no output schema, the description covers purpose, usage, examples, and a prerequisite. It doesn't explicitly separate from get_product_features_by_type, but overall 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?
The schema already provides full coverage for both parameters. The description adds value by explaining productId as the product identifier and pointing to GetDataHoldersByCategory for dataHolderBrandId, giving extra guidance 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?
Clearly states it returns features and benefits for a specific banking product, with a specific verb and resource. It also distinguishes itself from sibling tools by recommending GetProductConstraints for eligibility and usage limits.
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 describes when to use this tool ('for product capabilities') versus GetProductConstraints, and instructs calling GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID. This gives clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_features_by_typeAInspectFilter 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that this is a read-only operation, any authentication requirements, or what the response contains (e.g., a list of features). It only explains the conceptual nature of features, not the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but every part serves a purpose: it defines the operation, gives examples of feature types, and provides usage alternatives and prerequisites. It is somewhat long but well-structured and not bloated.
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 absence of an output schema, the description should ideally explain what results are returned (e.g., a list of features). It covers the CDR context, examples, and alternatives, but lacks explicit return value details and does not address the existence of a similar plural tool (get_products_features_by_type), so completeness is moderate.
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 each parameter having a description. The description adds extra context by providing examples of feature types (OFFSET, REDRAW, etc.) and notes that dataHolderBrandId is returned by GetDataHoldersByCategory, which complements the schema but does not significantly alter the underlying semantics.
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 action ('Filter Product by a feature type') and identifies the specific resource (banking product features per CDR standards). It distinguishes itself from GetProductConstraints by noting it is for product capabilities, but does not explicitly differentiate from the similar sibling get_product_features (which retrieves all features).
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 provides usage guidance: 'Use this tool for product capabilities; use GetProductConstraints for eligibility and usage limits' and directs the user to call GetDataHoldersByCategory first for a valid Data Holder Brand ID. This clearly indicates when to use this tool and what to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_feesAInspectReturns 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?
With no annotations, the description carries the full burden. It discloses that the tool is a read operation ('Returns'), references the CDR Banking standards for expected structure, and mentions the prerequisite that a valid Data Holder Brand ID must come from another tool. This is adequate behavioral 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?
The description is two sentences, front-loaded with the primary action, and provides a relevant usage note without any wasted words.
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 simple 2-parameter nature and lack of output schema, the description is fairly complete. It specifies the input requirements (Product ID, Data Holder Brand ID), references the CDR standard for expected output, and gives a prerequisite call. It does not mention pagination or error cases, but these are less critical for a straightforward getter.
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 description does not need to repeat parameter details. It does add a slight reinforcement that dataHolderBrandId should come from GetDataHoldersByCategory, but this is already present in the schema description, so the description adds no new parameter semantics.
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 fees for a specific banking product, using a specific verb ('Returns') and resource ('fees of a specific banking product'). It also distinguishes from siblings like get_product_fees_by_event by explicitly limiting to a single product and referencing the CDR standard.
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.' This provides context for when to use the tool, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_fees_by_eventAInspectFilter 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?
No annotations are provided, so the description must carry full disclosure burden. It fails to mention auth requirements, return format, pagination, or error behavior. The feeEvent vs feeType naming discrepancy also misleads about the actual parameter. Minimal behavioral disclosure beyond the basic 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?
The description is compact (two sentences) and front-loads the purpose. However, the imprecise 'Filter Product' phrasing and the feeEvent/feeType mixup undermine clarity slightly. It would be cleaner with just the usage guidance.
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 three required parameters and no output schema, the description provides some usage context but lacks information about the response shape or pagination. It covers prerequisites and sibling differentiation, but leaves the agent uncertain about return values and edge 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?
Schema description coverage is 100%, so baseline is 3. The description adds a useful hint about dataHolderBrandId being obtained from GetDataHoldersByCategory, but otherwise does not explain parameters beyond the schema. The feeEvent terminology conflicts with the actual feeType parameter, adding confusion rather than value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool filters product fees by a fee event for a specific product and data holder. It distinguishes itself from sibling tools by explicitly naming GetProductConstraints for eligibility/usage limits. However, it refers to 'feeEvent' while the schema parameter is 'feeType', creating minor 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 clear when-to-use guidance: 'Use this tool for product fees; use GetProductConstraints for eligibility and usage limits.' It also instructs to call GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID, covering prerequisites and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_products_constraintsAInspectReturns 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?
No annotations are present, so the description carries the full burden. It discloses that results are grouped by Product ID and enumerates example constraint types (MIN_LVR, MAX_LVR, balances, credit limits, deposit). While it doesn't explicitly state it's read-only, the verb 'Returns' implies a safe query, and the grouping behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured in two sentences: first the core purpose with grouping and examples, then the usage alternatives. It is dense but every clause adds information—no filler or repetition. It earns its length through concrete examples and explicit guidance.
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 compensates by explaining the output grouping and giving concrete examples of constraints. It also covers prerequisites (Data Holder ID) and alternatives (singular tool), making it fully self-contained for an agent to choose and invoke 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%, with both parameters fully documented in the schema. The description adds value by clarifying that productIds is an array for comparing multiple products and that dataHolderBrandId needs to come from GetDataHoldersByCategory. It also provides domain context (CDR Banking standards) that enriches the schema 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 verb 'Returns' and the resource 'constraints for multiple banking products', then distinguishes it from the singular GetProductConstraints by name. It specifies the grouping by Product ID, making the purpose immediately clear and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('ideal for comparing eligibility and usage limits across products'), and gives direct alternatives: 'Use GetProductConstraints for a single product, and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.' This provides clear context and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_products_eligibilityAInspectReturns 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?
With no annotations provided, the description carries the burden. It implies a read operation via 'Returns' and references the CDR standard, but does not disclose error handling, rate limits, or whether any side effects occur. The standard reference adds some context, but the description is thin on behavioral details.
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 purpose and followed by usage guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description provides strong guidance on purpose, usage, and prerequisites. Referencing the CDR standard helps infer the response shape, though explicit return format details are absent, which would have made it fully 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 description coverage is 100%, so the baseline is 3. The description adds a hint about using GetDataHoldersByCategory to obtain the brand ID, which is useful, but it does not deepen understanding of productIds beyond what the schema already says.
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 eligibility for multiple banking products, identifies the input as an array of Product IDs, and specifies it applies to a single Data Holder. It also distinguishes from the singular GetProductEligibility, making the 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?
Explicit guidance is provided: use GetProductEligibility for a single product and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID. This clearly explains when to use this tool and what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_products_featuresAInspectReturns 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?
With no annotations, the description must bear the burden of disclosing behavior. It does mention that results are grouped by Product ID and that the data follows CDR Banking standards, but it does not cover authentication requirements, error handling, rate limits, or data freshness. This makes it minimally adequate rather than fully transparent.
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-loads the core function, and every sentence adds value: purpose, grouping/use case, and alternatives. 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 tool with only two well-documented parameters and no output schema, the description gives enough context about return values (features grouped by product ID) and the standards followed. It doesn't detail the exact output JSON schema, but that is defined by the cited CDR standard, so this is reasonably 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?
Although schema coverage is 100%, the description adds meaningful context: it notes the product IDs are used for comparison across products, and that dataHolderBrandId must come from GetDataHoldersByCategory. This goes beyond the schema's generic 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 it returns features and benefits of multiple banking products identified by product IDs. It uses the specific verb 'Returns' and names the resource, and distinguishes from sibling tools like get_product_features which targets a single product.
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 'Use GetProductFeatures for a single product, and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID'—providing both when-to-use and when-not-to-use guidance, plus a prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_products_features_by_typeAInspectReturn 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?
With no annotations, the description carries full burden. It explains that results are grouped by Product ID and ideal for comparison, but lacks details about return structure, pagination, or error handling. It is adequate but leaves gaps about exact output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states purpose, second adds grouping behavior and usage context, third provides alternatives/prerequisite. No wasted words, front-loaded with the most important 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 moderate complexity and no output schema, the description covers key aspects: what it returns (grouped by product ID), how to use it (prerequisite and alternatives), and its ideal use case. Missing explicit return field details, but sufficient for a list/retrieval 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 baseline is 3. The description echoes the schema's parameter roles (products array, featureType, Data Holder Brand ID) but adds little beyond what the schema already provides. No extra syntactic or formatting detail.
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 ('Return'), the resource ('Products by a feature type of multiple products'), and the scope ('offered by a single Data Holder'). It also explicitly distinguishes from siblings by referencing GetProductFeatures for single product and GetDataHoldersByCategory for prerequisite, making its role unique.
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?
Explicit guidance is provided: 'Use GetProductFeatures for a single product, and GetDataHoldersByCategory first to obtain a valid Data Holder Brand ID.' This states when to use the tool, its alternative, and the prerequisite step, which is excellent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_products_feesAInspectReturns 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?
With no annotations, the description carries the burden of behavioral disclosure. It states the tool 'returns fees' and references the CDR standard, but does not disclose details like authentication requirements, error behavior, or irreversible actions. While it is a read operation by implication, there is no explicit statement of side effects or prerequisites beyond the ID source.
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, direct, and front-loaded with the main purpose. Every sentence earns its place, providing necessary scope and usage guidance without wasted words.
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 moderate complexity (two params, array param, no output schema), the description adequately covers the relationship with sibling tools, the data source for the brand ID, and the underlying standard. It does not detail the return structure, but referencing BankingProductFeeV2 partially compensates. Overall, an agent can select and invoke this tool correctly with the provided 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 coverage is 100% with descriptions for both parameters. The description adds context that dataHolderBrandId comes from GetDataHoldersByCategory and that productIds is an array, but this already appears in the schema. The schema's productIds description mentions 'features' which is inconsistent with fees, but the tool description clarifies the fee context, providing some value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns fees for multiple banking products, distinguishing it from the sibling get_product_fees which is for a single product. It specifies the verb 'returns' and the resource (fees by product IDs), making the 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?
It explicitly directs users to use GetProductFees for a single product and to call GetDataHoldersByCategory first to obtain a valid dataHolderBrandId. This provides clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
helloAInspectReturns a hello message
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the output is a hello message, which is sufficient for such a trivial tool, but it doesn't elaborate on any other behavior, such as whether the message varies.
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 filler words, perfectly concise.
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 trivial nature, the description is fully complete. There is no output schema, but the return value of a hello message is self-explanatory.
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 no parameters, so the input schema is empty. The baseline score is 4 because there is no parameter documentation needed.
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 a hello message, using a specific verb and resource. It is immediately distinguishable from sibling tools that retrieve product data, so there is no 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?
No guidance is provided for when to use this tool versus alternatives. The description doesn't mention any use case, prerequisites, or exclusions, so the agent must infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
