Skip to main content
Glama
Sign In
payping-mcp

payping-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

PayPing: list transactions

payping_list_transactions
Read-onlyIdempotent

List PayPing payments newest first with amount (Toman), payer, description, isPaid, and payment code, plus total count for the filter. Use a payment code to get full details.

Instructions

List payments (newest first) with amount (Toman), payer, description, isPaid and payment code, plus the total count for the same filter. Use payping_get_payment with a code for full detail.

Input Schema

NameRequiredDescriptionDefault
kindNo'received' = payments to you, 'paid' = payments you made; omit for both.
limitNoItems to return, 1-50.
offsetNoSkip this many items (paging).
to_dateNoLast day to include (YYYY-MM-DD, UTC).
from_dateNoFirst day to include (YYYY-MM-DD, UTC).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.2.0
    • removedInput schema / properties / from_date / title
      Removed value: -"From Date"
    • removedInput schema / properties / kind / title
      Removed value: -"Kind"
    • changedInput schema / properties / limit / description
      Previous value: -"Items to return, 1-50 (PayPing's maximum is 50)."New value: +"Items to return, 1-50."
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / offset / title
      Removed value: -"Offset"
    • removedInput schema / properties / to_date / title
      Removed value: -"To Date"
    • removedInput schema / title
      Removed value: -"payping_list_transactionsArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "payping_list_transactionsDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: results are newest-first, amounts are denominated in Toman, and the response includes a total count for the same filter. It does not mention auth requirements, rate limits, or pagination behavior, but the added return-shape context is real value.

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?

Two sentences, both earning their place: the first front-loads what is returned and its ordering, the second handles sibling routing. No filler or repetition of schema content.

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?

With no output schema, the description carries the return-shape burden and does so by enumerating the fields and the total count, which is the key information for a list tool. It omits pagination semantics (limit/offset interaction, maximums) that an agent would want when iterating over large result sets, and mentions nothing about the newest-first ordering interacting with date filters.

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?

Schema description coverage is 100%, so the schema already explains kind (received/paid), limit range, offset paging, and the UTC YYYY-MM-DD date bounds. The description adds only the incidental "Toman" unit and "same filter" framing for the total count, so the baseline 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?

States a specific verb and resource ("List payments") and immediately defines the returned shape: amount in Toman, payer, description, isPaid, payment code, plus total count. It also distinguishes itself from the sibling payping_get_payment, which is the closest lookalike in the toolset.

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

Usage Guidelines4/5

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

Gives clear routing guidance: use this tool to enumerate payments, and switch to payping_get_payment with a code when full detail is needed. It does not state when-not to use it (e.g. versus payping_list_withdrawals or payping_get_sales_summary for aggregation), so it stops short of the full when/when-not/alternatives bar.

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

Deploy Server

Other Tools