Loading ToolBench
Model Context Protocol server for PayPal payment operations, enabling creation, capture, and refunding of payments through PayPal's API
PayPal MCP has 4 tools with clear naming conventions (createPaypalOrder, capturePaypalOrder, refundPaypalCapture, getPaypalOrder) that follow verb-noun patterns. Descriptions are present but terse (23-60 chars), below the recommended 50-200 char range. Input schemas are properly typed with string types and basic descriptions. However, there are critical gaps: output schemas are entirely undocumented (tools return generic JSON without field documentation), error handling is minimal, and parameter descriptions lack actionable format guidance. The server handles credentials via environment injection (good), but lacks recovery guidance in error messages.
Captures (completes) a PayPal payment order
Creates a new PayPal payment order
Gets details of a PayPal order
Refunds a captured payment
Tool descriptions are too short (23-60 chars vs. recommended 50-200). LLMs cannot determine when to select these tools or understand side effects. E.g., 'Creates a new PayPal payment order' lacks WHEN to use it, WHAT prerequisites exist (API credentials configured?), and clarification that this orders but does not capture funds.
Output schemas are completely undocumented. Tools return {'success': boolean, 'data': any} or {'success': boolean, 'error': string}, but the agent has no specification of what fields 'data' contains. For createPaypalOrder, it should document that the response includes 'id', 'links', 'status'; for getPaypalOrder it should specify order structure. This forces LLMs to guess field names and causes failures downstream.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Error handling returns generic messages with no recovery guidance. E.g., 'Failed to get PayPal access token' or 'Failed to create PayPal payment: ...' tells the agent nothing about whether to retry, check configuration, or fail permanently. Per the recovery-guide pattern, errors should be classified as retryable vs. fatal and suggest next steps.
Parameter descriptions lack actionable format guidance. 'amount' is described as 'The payment amount (e.g. '10.00')' but does not specify required precision, min/max, or whether leading zeros are allowed. 'currency' defaults to USD but does not list valid ISO 4217 codes or whether custom codes are accepted. LLMs hallucinate values when constraints are vague.
No pagination support. If a getPaypalOrder response returns multiple related items (e.g., transactions, captures), there is no limit or offset parameter to prevent context window explosion. The pattern mandates pagination for list endpoints and result limits even for single lookups.
Irreversible operations (capturePaypalOrder, refundPaypalCapture) lack confirmation or dry-run support. An agent could accidentally capture an order or refund a payment. Per the confirmation-request pattern, these tools should require explicit approval or support a dry-run first.
No tool-level scope or permission declarations. Each tool should advertise what permissions it requires (e.g., 'paypal:order:write', 'paypal:order:read') so agents can be configured with least-privilege access. Currently, all environment credentials are monolithic.