Skip to main content
Glama
zkp2p

Peer Cash MCP

Official
by zkp2p
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Prepare a cash-out

peer_cash_prepare

Prepare unsigned Base USDC approval and deposit transactions, presenting a plan for explicit host-side signing without handling private keys.

Instructions

Prepare unsigned Base USDC approval and createDeposit transactions. The MCP server never accepts a private key or submits a transaction. Show the plan and obtain explicit approval before host-side signing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesBase USDC amount in 6-decimal base units
receiveYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.2
    • changedInput schema / properties / receive / anyOf
      Previous value: -[
-  {
-    "anyOf": [
-      {
-        "additionalProperties": false,
-        "properties": {
-          "currency": {
-            "minLength": 3,
-            "type": "string"
-          },
-          "payee": {
-            "anyOf": [
-              {
-                "minLength": 1,
-                "type": "string"
-              },
-              {
-                "additionalProperties": {},
-                "type": "object"
-              }
-            ]
-          },
-          "platform": {
-            "minLength": 1,
-            "type": "string"
-          }
-        },
-        "required": [
-          "platform",
-          "currency",
-          "payee"
-        ],
-        "type": "object"
-      },
-      {
-        "additionalProperties": false,
-        "properties": {
-          "currencies": {
-            "items": {
-              "minLength": 3,
-              "type": "string"
-            },
-            "minItems": 1,
-            "type": "array"
-          },
-          "payee": {
-            "$ref": "#/properties/receive/anyOf/0/anyOf/0/properties/payee"
-          },
-          "platform": {
-            "minLength": 1,
-            "type": "string"
-          }
-        },
-        "required": [
-          "platform",
-          "currencies",
-          "payee"
-        ],
-        "type": "object"
-      }
-    ]
-  },
-  {
-    "items": {
-      "$ref": "#/properties/receive/anyOf/0"
-    },
-    "minItems": 1,
-    "type": "array"
-  }
-]New value: +[
+  {
+    "anyOf": [
+      {
+        "additionalProperties": false,
+        "properties": {
+          "currency": {
+            "minLength": 3,
+            "type": "string"
+          },
+          "payee": {
+            "anyOf": [
+              {
+                "minLength": 1,
+                "type": "string"
+              },
+              {
+                "additionalProperties": true,
+                "properties": {
+                  "offchainId": {
+                    "minLength": 1,
+                    "type": "string"
+                  }
+                },
+                "required": [
+                  "offchainId"
+                ],
+                "type": "object"
+              }
+            ]
+          },
+          "platform": {
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "platform",
+          "currency",
+          "payee"
+        ],
+        "type": "object"
+      },
+      {
+        "additionalProperties": false,
+        "properties": {
+          "currencies": {
+            "items": {
+              "minLength": 3,
+              "type": "string"
+            },
+            "minItems": 1,
+            "type": "array"
+          },
+          "payee": {
+            "$ref": "#/properties/receive/anyOf/0/anyOf/0/properties/payee"
+          },
+          "platform": {
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "platform",
+          "currencies",
+          "payee"
+        ],
+        "type": "object"
+      }
+    ]
+  },
+  {
+    "items": {
+      "$ref": "#/properties/receive/anyOf/0"
+    },
+    "minItems": 1,
+    "type": "array"
+  }
+]
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

The description discloses critical behavioral traits: 'never accepts a private key or submits a transaction' and 'obtain explicit approval before host-side signing'. These are not in annotations (which only have false hints). This adds significant safety-relevant context beyond the schema.

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 concise sentences, immediately stating the tool's purpose and critical safety behavior. No fluff, front-loaded.

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?

For a tool with no output schema, it mentions it prepares unsigned transactions and requires approval before signing, which covers the key usage context. It doesn't describe the return value or possible errors, but those are not strictly necessary given the action-oriented description. Slightly more could be said about the receive parameter structure, but the schema covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has a description for amount but not for receive. The description does not explain the parameters at all. Since schema coverage is only 50% (low), the description should compensate. It fails to clarify what 'receive' means or how it relates to the transaction. Thus the agent may struggle to populate the receive object correctly.

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?

Description explicitly states it prepares two specific transaction types (Base USDC approval and createDeposit), clearly distinguishing from sibling tools like prepare_withdraw or prepare_top_up. The verb 'prepare' plus resource 'cash-out' is specific and unambiguous.

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

Usage Guidelines4/5

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

The description says 'Show the plan and obtain explicit approval before host-side signing,' which indicates the tool's usage context. However, it doesn't explicitly contrast with sibling tools or state when not to use it. Still, the purpose is clear enough for an agent to choose it for cash-out preparation.

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