为 Claude（或任何兼容 MCP 的智能体）提供一个在 Base 上的非托管 USDC 钱包 —— 且每笔支付都需人工确认。
@grip-foundation/grip-mcp 是一个 Model Context Protocol 服务器，它向任何支持 MCP 的客户端（Claude Desktop、Claude Code、Continue 等）提供四个工具：
工具 | 功能 | 审批人 |
| 返回智能体的智能账户地址及 Base 上的 USDC 余额。 | — |
| 暂存一笔支付（链下）。返回一个审批令牌。 | — |
| 结算或拒绝一笔暂存的支付。批准后，在 Base 主网上执行真实的 USDC 转账。 | 人工，在对话中 |
| 列出当前会话中的近期支付记录。 | — |
智能体在没有你的情况下绝不会动用资金。流程为：智能体暂存 → 你在对话中确认 → 智能体结算。不存在程序化的自动批准。
Related MCP server: @arispay/payagent-mcp
npx（首次发布后）在 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows) 中：
{
"mcpServers": {
"grip": {
"command": "npx",
"args": ["-y", "@grip-foundation/grip-mcp"]
}
}
}git clone https://github.com/grip-foundation/grip-mcp.git
cd grip-mcp
pnpm install
pnpm run build然后将 Claude Desktop 指向构建后的文件：
{
"mcpServers": {
"grip": {
"command": "node",
"args": ["/absolute/path/to/grip-mcp/dist/server/index.js"]
}
}
}编辑配置后请重启 Claude Desktop。
服务器首次启动时，会生成一个新的 EOA 私钥并将其存储在 ~/.grip-mcp/agent-key（权限 0600）。此密钥控制智能账户。
在 Claude 中询问：
Show me my Grip wallet
Claude 将调用 grip_wallet 并回复你的智能账户地址、余额和限额。向该地址发送 Base 链上的 USDC 即可充值。
充值后，向 Claude 询问类似以下内容：
Send 5 USDC to 0xba14744FfD57FA7d03b20D4c8BeDAaC301E865d1
Claude 将：
调用 grip_create_payment 在链下暂存支付。
向你展示详情（金额、收款人、备注）并请求确认。
等待你的回复。
如果你说“approve” → 调用 grip_settle_payment(token, "approve") → 在 Base 上执行。
如果你说“no” → 调用 grip_settle_payment(token, "reject") → 不执行链上操作。
结算时会返回交易哈希和 Basescan 链接。
环境变量 | 默认值 | 功能 |
| (自动生成) | 覆盖智能体的签名私钥。用于在不同机器间恢复钱包。 |
|
| 自动生成密钥的存储路径。 |
|
| 单笔支付的最大 USDC 金额。 |
|
| 每日（UTC 时间）所有支付的最大 USDC 总额。 |
非托管。 Grip Foundation 不持有你的密钥、USDC 或任何支付记录。一切都在你的机器上运行。
托管支付中继（Paymaster），无需注册。 Gas 费通过路由至 Grip 托管代理的 Pimlico 支付中继以 USDC 支付。你无需拥有 Pimlico 账户。
人工确认由协议而非模型强制执行。 grip_create_payment 仅进行暂存。grip_settle_payment 是一个独立的工具调用。大多数 MCP 客户端（包括 Claude Desktop）在执行工具调用前都会提示人工确认 —— 这是第二层防护。
限额由服务器端强制执行。 即使模型尝试进行超过单笔或每日限额的支付，服务器也会拒绝暂存。
Claude Desktop
│ MCP (stdio)
▼
grip-mcp (this server)
│ @grip-labs/sdk
▼
Grip-managed paymaster proxy → Pimlico bundler → Base mainnet
▲
Coinbase Smart Wallet
(your smart account)该智能账户是 Base 上的 Coinbase Smart Wallet (ERC-4337)。新钱包的首次支付会运行一次性的引导 UserOp，用于部署账户并批准支付中继进行 USDC 报销；后续的 UserOp 则直接由 USDC 支付。
首次支付可能需要重试。 在 @grip-labs/sdk@0.4 中，引导 UserOp（部署 + 批准支付中继）和实际转账 UserOp 是作为两个独立操作提交的。存在一个小的竞争窗口，即 viem 的内部 getFactoryArgs() 在引导程序于 Pimlico 捆绑器结算后，从公共 RPC 读取到过时的 getCode —— 随后 viem 在第二个 UserOp 中包含了 initCode，导致捆绑器报错 AA10 sender already constructed。
如果你的首次支付因该错误失败，只需让智能体重试即可。重试会成功，因为此时链上状态已经同步。同一钱包的后续支付是正常的 —— 每个钱包最多只运行一次引导程序。
@grip-labs/sdk@0.5 即将发布修复程序，它通过 executeBatch 将引导程序 + 首次转账合并为一个受赞助的 UserOp，从根本上消除了竞争，并节省了约 30% 的首次支付 Gas 费。grip-mcp 将在 0.1.1 版本中采用该修复。
MIT
Grip Foundation · 为 AI 智能体提供开放身份 + 支付轨道。
Stages a payment from the agent's Grip wallet to a recipient. DOES NOT execute on-chain. Returns an approval_token. You MUST then show the payment details (amount, recipient, memo) to the human in plain language and ASK FOR EXPLICIT CONFIRMATION before calling grip_settle_payment. Never auto-approve. The human must say 'approve' (or equivalent) before settling. If they say 'no', call grip_settle_payment with decision='reject'.
| Name | Required | Description | Default |
|---|---|---|---|
| recipient | Yes | ||
| amount_usdc | Yes | ||
| memo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool does not execute on-chain, returns an approval_token, and requires a two-step human approval process. This adds significant context beyond annotations (which only indicate non-read-only and non-destructive). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and structured logically: action, caution, required follow-up steps. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the return value (approval_token) and the complete workflow (stage, confirm, settle/reject). It references sibling tools and provides enough context for a complex, multi-step tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'amount, recipient, memo' but does not elaborate on schema constraints like the Ethereum address pattern or USDC amount limits. With 0% schema description coverage, the description adds minimal value over the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool stages a payment without executing on-chain, distinguishing it from sibling tools like grip_settle_payment. It specifies the action ('create pending payment') and resource ('agent's Grip wallet to recipient').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to never auto-approve, to show payment details to the human, and to ask for explicit confirmation before calling grip_settle_payment. It also covers the rejection case ('If they say 'no', call grip_settle_payment with decision='reject'').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns recent payments (pending, settled, rejected, failed) staged or executed in this MCP session. Read-only. Useful when the human asks 'what have I paid today' or 'what's pending'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds 'Read-only' (consistent) and specifies session-scoped payments, which is not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and resource, second gives usage examples. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one optional parameter, rich annotations, no output schema), the description covers purpose, scope, and use cases adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the limit parameter, and the description does not mention the parameter or add meaning beyond the schema's min/max constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and the resource 'payments', specifying they are 'staged or executed in this MCP session', which distinguishes it from sibling tools like grip_create_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with examples like 'what have I paid today' or 'what's pending', but does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes the on-chain transfer for a previously-staged payment, or marks it as rejected. ONLY call this after the human has explicitly confirmed (or declined) the payment in plain language. If the human has not confirmed, do not call this tool. On approve, this performs a real USDC transfer on Base mainnet via the Pimlico paymaster — it is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| approval_token | Yes | ||
| decision | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds critical context: 'performs a real USDC transfer on Base mainnet via Pimlico paymaster — it is irreversible'. This fully discloses the irreversible and destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The first sentence covers the primary action, and subsequent sentences add critical usage guidance and behavioral context. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive and irreversible nature, the description provides essential context (on-chain transfer, paymaster). However, the lack of parameter detail for 'approval_token' means the agent may lack complete information to use the tool correctly. Minor gap prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not adequately explain the 'approval_token' parameter (e.g., format, source). It only mentions 'decision' with enum values, leaving a significant gap for the agent to understand how to obtain or use the approval_token.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes an on-chain transfer or marks a payment as rejected, with specific verb 'executes' and resource 'previously-staged payment'. It distinguishes from siblings like grip_create_payment and grip_list_payments by focusing on settlement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to call only after human confirmation, with a clear prohibition ('do not call this tool') if not confirmed. This provides excellent guidance on when to use vs. not use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns this agent's Grip Pay wallet address (Base mainnet smart account) and current USDC balance. Use this when the human asks about the wallet, where to fund it, how much USDC the agent has, or before suggesting any payment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds behavioral context by detailing the returned data (wallet address and USDC balance), which is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. The key purpose is front-loaded, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the simplicity of the tool, the description covers the essential aspects: what it returns and when to use it. It could be slightly improved by mentioning the format of the output, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the description does not need to add parameter information. The baseline score of 4 is appropriate given 100% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the agent's wallet address and USDC balance. It uses a specific verb ('Returns') and resource ('wallet info'), and the purpose is distinct from sibling tools which deal with payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists scenarios when to use the tool: when the human asks about the wallet, where to fund it, how much USDC the agent has, or before suggesting any payment. This provides clear guidance without needing to mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0grip_create_paymentgrip_list_paymentsgrip_settle_paymentgrip_walletScored across 4 tools
Each tool has a clear, distinct purpose: creating staged payments, listing payments, settling/rejecting, and checking wallet info. No overlap or ambiguity.
All tools start with 'grip_' and most follow a verb_noun pattern (create_payment, list_payments, settle_payment). The exception is 'grip_wallet', which is a noun phrase, but the inconsistency is minor given the small set.
Four tools is well-scoped for a payment/wallet MCP server. It covers staging, settling, listing, and wallet info without being too few or excessive.
The tool surface covers the core payment workflow: create, settle/reject, list, and wallet info. A potential minor gap is lack of explicit cancellation for staged payments, but the reject option in settle effectively handles that.
Give AI agents a wallet with a spending limit. Non-custodial USDC on Base, server-enforced limits.
Monetization and execution gateway for autonomous AI agents on Base Mainnet
Crypto wallet for AI agents: balances, payments, swaps and trading with owner controls.
Marketplace for AI agents: hire, sell, get paid in USDC on Base. Identity, jobs, reputation.
