Claude（またはMCP互換エージェント）にBase上のノンカストディアルUSDCウォレットを持たせましょう。すべての支払いに人間による承認プロセスが組み込まれています。
@grip-foundation/grip-mcp は、Model Context Protocol サーバーであり、MCP対応クライアント（Claude Desktop、Claude Code、Continueなど）に対して4つのツールを提供します。
ツール | 機能 | 承認者 |
| エージェントのスマートアカウントアドレスと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へのリンクが返されます。
環境変数 | デフォルト | 機能 |
| （自動生成） | エージェントの署名用秘密鍵を上書きします。複数のマシン間でウォレットを復元する際に便利です。 |
|
| 自動生成された鍵の保存先です。 |
|
| 1回の支払いあたりの最大USDC額です。 |
|
| UTCの1日あたりの全支払い合計最大USDC額です。 |
ノンカストディアル。 Grip Foundationは、あなたの秘密鍵、USDC、支払い記録を一切保持しません。すべてあなたのマシン上で動作します。
マネージド・ペイマスター、登録不要。 ガス代は、Gripのホスト型プロキシを経由してPimlicoペイマスターによりUSDCで支払われます。Pimlicoアカウントは不要です。
人間による承認はモデルではなくプロトコルで強制されます。 grip_create_payment はステージングのみを行います。grip_settle_payment は別のツール呼び出しです。ほとんどのMCPクライアント（Claude Desktopを含む）は、ツール呼び出しを実行する前に人間による確認を求めるため、これが二重のゲートとなります。
上限はサーバー側で強制されます。 モデルが1回あたりの上限や1日あたりの上限を超える支払いを試みても、サーバーはステージングを拒否します。
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) です。新しいウォレットからの最初の支払いは、アカウントをデプロイし、USDC償還のためにペイマスターを承認する一度限りのブートストラップUserOpを実行します。それ以降のUserOpはUSDCで支払われます。
最初の支払いで再試行が必要になる場合があります。 @grip-labs/sdk@0.4 では、ブートストラップUserOp（デプロイ + ペイマスター承認）と実際の送金UserOpが2つの別々の操作として送信されます。ブートストラップがPimlicoバンドラーで確定した後、viemの内部 getFactoryArgs() がパブリックRPCから古い getCode を読み取ってしまうという小さな競合ウィンドウが存在します。その結果、viemが2番目のUserOpに initCode を含めてしまい、バンドラーが AA10 sender already constructed エラーで拒否します。
最初の支払いがこのエラーで失敗した場合は、エージェントに再試行を依頼してください。オンチェーンの状態が反映されているため、再試行は成功します。同じウォレットからの以降の支払いはクリーンです（ブートストラップはウォレットごとに最大1回しか実行されません）。
@grip-labs/sdk@0.5 では、ブートストラップと最初の送金を executeBatch を使用して単一のスポンサー付きUserOpに統合する修正が行われており、競合を根本的に排除し、最初の支払いのガス代を約30%削減します。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.
