Skip to main content
Glama
Sign In

McpStamp Deposits

by io.github.theluckystrike
OverviewDiscussionsAdmin

List deposits

deposit_list
Read-onlyIdempotent

List deposits newest first: DEP number, client, kind, date, reference and what was received, applied, refunded and still held, with the same four totalled per currency. Filter by client, status, kind, date.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "deposit_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoYYYY-MM-DD, latest received date
fromNoYYYY-MM-DD, earliest received date
kindNoDefault "all"
clientNoOnly deposits for this client id, exact name, or a name containing this text
statusNoDefault "all". held means some of the money is still held

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds useful behavioral details: the ordering (newest first) and the output structure (fields and totals per currency). It doesn't add side-effect warnings, but none are needed given the annotations. It does go beyond annotations by specifying the 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.

Conciseness5/5

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

The entire description is one dense, information-rich sentence. It front-loads the core action ('List deposits newest first') and then packs in the output fields and filtering options without any filler. Every clause earns its place, and the structure is efficient and readable.

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

Completeness4/5

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

The description covers the essential return values (fields and currency totals) and the ordering, which is sufficient for a read-only list tool. It does not mention pagination, result limits, or whether all matching deposits are returned, but given the absence of an output schema and the simple nature of the tool, this is a minor gap. The annotations cover safety, so the overall context is nearly complete.

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

Parameters3/5

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

The schema has 100% coverage, with each parameter having a descriptive comment (e.g., 'YYYY-MM-DD, latest received date' for 'to' and a detailed note for 'client'). The description merely mentions 'Filter by client, status, kind, date' without adding any new semantics or examples. Since the schema already documents all parameters, the description adds no extra value here, so the baseline of 3 applies.

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

Purpose5/5

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

The description uses a specific verb 'List' with the resource 'deposits' and immediately specifies the output fields (DEP number, client, kind, date, reference, and the four amounts) plus the ordering ('newest first'). This clearly distinguishes it from sibling tools like deposit_balance (which likely gives balances) or deposit_statement_text (which likely produces a statement), so an agent can tell them apart.

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

Usage Guidelines3/5

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

The description states the filtering options (client, status, kind, date) which implies when to use it for listing deposits, but it does not explicitly mention when not to use it or point to alternatives. It does not say 'use deposit_balance for totals' or 'use deposit_statement_text for a formatted statement', leaving the agent to infer the use case from the tool's name and description alone.

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

All McpStamp Deposits toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources