Before tool execution
Check the action name, amount, merchant, and workflow step before the MCP tool performs side effects.
MCP spend guard
Gate MCP tool calls before they spend.
MCP is where agents ask tools to act. Featherlane AI is designed for that boundary: the agent proposes a checkout, payment, refund, booking, or account action, and the guard returns a effect before the tool runs.
Failure modes
Tool calls need action policy, not just prompt policy.
- A tool call can charge a card even if the final chat answer looks harmless.
- A browser or commerce tool may use a saved payment method from the user session.
- A retry can repeat the same checkout or refund.
- A monthly site cap does not explain why this specific transaction was safe.
Runtime check
MCP-native control points
Hold instead of guess
Route borderline actions to a person instead of letting the agent decide silently.
Rail-agnostic proof
Keep the policy trace above any single wallet, token, or checkout provider.
Audit proof
Built around the tool-call boundary
ok Action-level effects
ok Policy context for each proposed side effect
ok Audit records that explain why a transaction was allowed or blocked
ok A path from soft software gates to harder payment controls later
Questions
What teams ask before they wire it in.
Is the MCP server shipped?
The core Featherlane AI runtime and SDK path exist today. MCP-specific packaging should be implemented when a design partner pulls for it.
Why not only use a wallet cap?
Wallet caps limit spend, but they do not always explain the action, evidence, user intent, or policy reason behind a decision.
Ship the check
Put a effect between the agent and the action.
Bring a real checkout, refund, booking, or invoice flow. We will map the exact pre-action check and the audit record it should leave behind.