ClawdPay MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HEADLESS | No | Whether to run the browser in headless mode (true/false). | true |
| PRIVACY_API_KEY | Yes | Your Privacy.com API key. | |
| PRIVACY_SANDBOX | No | Whether to use the Privacy.com sandbox environment (true/false). | true |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_virtual_cardC | Create a single-use virtual card via Privacy.com. Returns secure card details. |
| secure_auto_fillC | Intelligently finds and fills payment fields on the current page using robust heuristics. |
| get_funding_sourcesB | List available funding accounts connected to Privacy.com |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: create_virtual_card handles card creation, get_funding_sources lists funding accounts, and secure_auto_fill focuses on browser automation for payment fields. There is no overlap in functionality, making tool selection straightforward for an agent.
Two tools follow a consistent verb_noun pattern (create_virtual_card, get_funding_sources), while secure_auto_fill uses a different adjective_noun style. This minor deviation slightly reduces consistency, but the names remain readable and descriptive overall.
With only 3 tools, the server feels thin for a payment integration domain, which typically involves more operations like updating cards, managing transactions, or handling errors. While the tools cover basic needs, the scope seems limited compared to what might be expected.
The toolset has significant gaps for a payment integration server. It lacks essential operations such as updating or deleting virtual cards, viewing transaction history, managing card limits, or handling errors. This incomplete surface will likely cause agent failures in common payment workflows.