Skip to main content
Glama

Paypal List Disputes

paypal_list_disputes
Read-onlyIdempotent

List chargebacks and claims against your account. Returns dispute IDs, amounts, statuses, and reasons.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_sandboxNoUse sandbox environment (default: false)
_clientIdYesPayPal app Client ID
_clientSecretYesPayPal app Client Secret

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsNoArray of disputes
linksNo
total_itemsNoTotal number of disputes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "List of disputes and chargebacks",
      +  "properties": {
      +    "items": {
      +      "description": "Array of disputes",
      +      "items": {
      +        "properties": {
      +          "amount": {
      +            "properties": {
      +              "currency_code": {
      +                "description": "Currency code",
      +                "type": "string"
      +              },
      +              "value": {
      +                "description": "Disputed amount",
      +                "type": "string"
      +              }
      +            },
      +            "type": "object"
      +          },
      +          "create_time": {
      +            "description": "Dispute creation timestamp",
      +            "type": "string"
      +          },
      +          "dispute_id": {
      +            "description": "Dispute ID",
      +            "type": "string"
      +          },
      +          "reason": {
      +            "description": "Dispute reason code",
      +            "type": "string"
      +          },
      +          "reason_description": {
      +            "description": "Human readable dispute reason",
      +            "type": "string"
      +          },
      +          "status": {
      +            "description": "Dispute status (e.g., OPEN, RESOLVED, WAITING_FOR_BUYER_RESPONSE, WAITING_FOR_SELLER_RESPONSE)",
      +            "type": "string"
      +          },
      +          "transaction_id": {
      +            "description": "Related transaction ID",
      +            "type": "string"
      +          },
      +          "update_time": {
      +            "description": "Dispute last update timestamp",
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "links": {
      +      "items": {
      +        "properties": {
      +          "href": {
      +            "type": "string"
      +          },
      +          "rel": {
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "total_items": {
      +      "description": "Total number of disputes",
      +      "type": "number"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "_clientId": "your-paypal-client-id",
      +    "_clientSecret": "your-paypal-client-secret"
      +  }
      +]
  3. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, so the description adds minimal behavioral context beyond listing return fields. No contradictions, but the description does not deepen transparency.

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 succinct sentences with the main action front-loaded. No filler, every sentence adds value.

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 rich annotations and complete schema, the description is adequate. It clarifies the output fields. However, it omits potential pagination or filtering details, but given the tool's simplicity and the presence of an output schema, it is reasonably 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?

Schema coverage is 100%, and all parameters are documented in the schema. The description adds no extra meaning about parameters beyond what the schema provides, warranting the baseline score of 3.

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 clearly states the verb 'List' and the resource 'chargebacks and claims against your account.' It also specifies the returned fields (IDs, amounts, statuses, reasons), distinguishing it from sibling tools like paypal_list_invoices or paypal_list_transactions.

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 provides no guidance on when to use this tool versus others (e.g., paypal_list_invoices). It does not mention prerequisites, alternatives, or scenarios, which would be helpful given the numerous sibling tools.

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.