Skip to main content
Glama

See digital account transfers

list_digital_account_transfers
Read-only

Transfers made from the digital account. Read only.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the description's only behavioral claim, 'Read only', is pure repetition. Nothing is said about ordering, pagination, volume, or date scoping of the returned transfers, which is the kind of context annotations do not cover.

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

Conciseness4/5

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

Two short sentences with no filler, and the resource identification is front-loaded. It is not padded, though the second sentence is wasted on restating an annotation.

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

Completeness2/5

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

With no parameters and no output schema, the description is the only place that could explain what a 'transfer' is versus a bill payment or pix payment, and it does not. For a zero-argument tool sitting among several similar digital-account list endpoints, that omission leaves a real selection gap.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The absence of any filtering parameters is itself notable but not a description failure.

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

Purpose3/5

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

The description names the resource (transfers from the digital account) but uses a bare noun phrase with no verb, so the listing action is only inferred from the tool name. It also fails to distinguish this from the near-identical siblings list_digital_account_bill_payments and list_digital_account_pix_payments, which are also digital-account movement listings.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool rather than the bill-payments or pix-payments siblings, and no preconditions or exclusions are given. The agent is left to guess which of the three digital-account listing tools fits a given query.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources