Skip to main content
Glama
Sign In

Paypal

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Paypal List Transactions

paypal_list_transactions
Read-onlyIdempotent

Find PayPal transactions within a date range. Returns amount, status, payer info, and transaction IDs. Use to audit payments or track cash flow.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "end_date": "2024-12-31T23:59:59Z",
      "_clientId": "your-paypal-client-id",
      "start_date": "2024-01-01T00:00:00Z",
      "_clientSecret": "your-paypal-client-secret"
    },
    "name": "paypal_list_transactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
_sandboxNoUse sandbox environment (default: false)
end_dateYesEnd date in ISO 8601 format (e.g., 2024-12-31T23:59:59Z)
_clientIdYesPayPal app Client ID
start_dateYesStart date in ISO 8601 format (e.g., 2024-01-01T00:00:00Z)
_clientSecretYesPayPal app Client Secret

Output Schema

NameRequiredDescriptionDefault
pageNoCurrent page number
total_itemsNoTotal number of transactions
total_pagesNoTotal number of pages
transaction_detailsNoArray of transactions

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "description": "List of PayPal transactions within a date range",
+  "properties": {
+    "page": {
+      "description": "Current page number",
+      "type": "number"
+    },
+    "total_items": {
+      "description": "Total number of transactions",
+      "type": "number"
+    },
+    "total_pages": {
+      "description": "Total number of pages",
+      "type": "number"
+    },
+    "transaction_details": {
+      "description": "Array of transactions",
+      "items": {
+        "properties": {
+          "payer_email": {
+            "description": "Payer email address",
+            "type": "string"
+          },
+          "payer_name": {
+            "properties": {
+              "given_name": {
+                "description": "First name",
+                "type": "string"
+              },
+              "surname": {
+                "description": "Last name",
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "transaction_amount": {
+            "properties": {
+              "currency_code": {
+                "description": "Currency code (e.g., USD)",
+                "type": "string"
+              },
+              "value": {
+                "description": "Transaction amount",
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "transaction_date": {
+            "description": "Transaction date in ISO 8601 format",
+            "type": "string"
+          },
+          "transaction_id": {
+            "description": "Unique transaction ID",
+            "type": "string"
+          },
+          "transaction_status": {
+            "description": "Transaction status (e.g., S, D, F)",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "_clientId": "your-paypal-client-id",
+    "_clientSecret": "your-paypal-client-secret",
+    "end_date": "2024-12-31T23:59:59Z",
+    "start_date": "2024-01-01T00:00:00Z"
+  },
+  {
+    "_clientId": "your-paypal-client-id",
+    "_clientSecret": "your-paypal-client-secret",
+    "_sandbox": true,
+    "end_date": "2024-09-30T23:59:59Z",
+    "start_date": "2024-09-01T00:00:00Z"
+  }
+]
  3. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds minimal extra context beyond stating return fields, so it is adequate but does not significantly enhance transparency beyond annotations.

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?

The description is concise with three short sentences, front-loaded with purpose, and contains no fluff. Slightly more structure could improve readability, but it is efficient overall.

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

Completeness3/5

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

Given the tool has 5 parameters and an output schema exists, the description adequately covers return fields and use case. However, it omits potential details like pagination, limits, or time zone handling, making it acceptable but not robust.

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 documents all parameters. The description alludes to date range but adds no meaningful semantics beyond what is in the schema, meeting the baseline.

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

Purpose4/5

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

The description clearly states 'Find PayPal transactions within a date range' with a specific verb and resource, and mentions return fields. However, it does not explicitly differentiate from sibling tools like paypal_get_invoice or paypal_list_invoices.

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?

It provides a use case context ('audit payments or track cash flow') but offers no guidance on when not to use this tool or how it compares to alternative PayPal list tools among siblings.

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

All Paypal 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