Skip to main content
Glama

ebay_get_payout

Read-only

Retrieve a single eBay seller payout by payout ID to view its amount, status, payout instrument, and transaction count. Use payout IDs from payout list results or Seller Hub.

Instructions

Get one seller payout by payoutId from the eBay Finances API, including amount, status, payout instrument, and transaction count. Find IDs with ebay_get_payouts. Requires the sell.finances scope. eBay requires Digital Signatures on Finances API calls for EU/UK sellers, which this server does not add.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
payoutIdYesPayout ID from ebay_get_payouts or Seller Hub. A split-payout payoutReference returns 404.
marketplaceIdNoOverrides the X-EBAY-C-MARKETPLACE-ID header, e.g. EBAY_US, EBAY_GB or EBAY_DE. Defaults to EBAY_MARKETPLACE_ID; eBay assumes EBAY_US when the header is absent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.18.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only provide readOnlyHint=true. The description goes beyond that by disclosing three behavioral constraints the annotations cannot: the authorization scope, the EU/UK Digital Signature limitation (a hard blocker this server cannot satisfy), and the fact that the schema-referenced split payouts return 404. This is high-value context aligning with read-only behavior.

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?

Three tightly packed sentences: (1) what it returns, (2) how to find the ID, (3) prerequisites. Front-loaded with the action and result, zero filler.

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

Completeness5/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 enumerates the returned fields, and it covers the critical authorization and regional signature caveats. Complete for a single-resource getter.

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% and the schema already documents payoutId format patterns and marketplaceId defaults/enums. The description adds no syntax or format details beyond the schema, 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 ('Get'), resource ('one seller payout by payoutId'), API ('eBay Finances API') and enumerates returned fields (amount, status, instrument, transaction count). Clearly distinguishable from ebay_get_payouts (list) by the singular scope.

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

Usage Guidelines5/5

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

Explicitly tells the agent how to obtain the required ID ('Find IDs with ebay_get_payouts'), names the required OAuth scope (sell.finances), and warns about the Digital Signature requirement for EU/UK sellers that this server does not fulfill. This is exactly the when-to-use / when-not context an agent needs.

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