Inside the Meow MCP Server: A Technical Tour of the Tools Your Agent Calls
The marketing answer to "what does the Meow MCP server do" is "it lets an agent open and run a business bank account." The technical answer is a documented tool surface, an OAuth 2.1 handshake, a capability grammar enforced at the API gateway, and a set of request and response shapes the agent client reads at runtime.
This post is the technical answer. It walks the tool surface tool by tool, shows the discovery flow, explains the permissioning grammar, and ends with the CLI command that connects everything in one shell line. The request and response shapes shown below are representative; the live source of truth is the skills file at meow.com/skills.md.
How the Agent Discovers the Server
Discovery runs through the /.well-known/agent.json convention. Meow publishes its discovery file at meow.com/.well-known/agent.json. The file conforms to the IETF RFC 8615 well-known URI convention and the Model Context Protocol discovery shape.
When an MCP-compatible client like Claude, ChatGPT, Cursor, or Gemini connects to a new domain, it checks the well-known path first. The Meow discovery file returns the MCP server URL (mcp.meow.com), the protocol version, the supported authentication methods, the tool surface URL (meow.com/skills.md), and contact information for the agent program. No manual configuration is required in the client's settings file. Discovery completes in a single GET request.
A bank that does not publish a /.well-known/agent.json file is invisible to half the agent stack. The compliant agent client will not find the server, will not surface the tools, and will not offer the workflows to the user. The CFO checklist post argues this point at the procurement level; the engineering point is even simpler. Without the discovery file, the bank is not callable.
The Authentication Model
Authentication uses OAuth 2.1 with PKCE. The first connection from a new agent triggers an OAuth handshake against the Meow account, with the agent's redirect URI registered as part of the client identity. The account holder approves the connection in a browser window or in the Meow dashboard, the OAuth server returns a scoped bearer token, and the token is stored by the agent client.
Tokens are short-lived. The default lifetime is 24 hours, with automatic rotation on a soft-rotate window so the agent never receives a 401 mid-workflow. Hardware-bound tokens via WebAuthn are an option for customers who want to eliminate token replay risk.
Scoped tokens default to two capabilities: read (lets the agent see account balances, transaction history, and card status) and request-to-spend (lets the agent prepare a payment that the human approves before execution). Binary toggles for the higher-authority capabilities (wire dispatch, ACH execution, card issuance, payment initiation) are configurable per account by the account holder. The default for all four is off. Turning a toggle on is a single click in the dashboard or a single tool call from the agent with the account holder's approval routed through SMS.
Token revocation is a single click and propagates within seconds. Any human on the account can fire it. There is no "wait for the next rotation" or "open a ticket" flow.
The Tool Surface
Five tools cover the operating surface for a Meow business banking customer. The names below are the placeholders captured in the content plan; the live identifiers at meow.com/skills.md are the source of truth and may differ.
form_entity. Forms a US legal entity (LLC, C Corp, LLP, or LP) in any US state.
open_account. Opens a business bank account through Meow against an existing entity.
issue_card. Issues a virtual or physical corporate card with spend controls.
create_invoice. Generates and dispatches an invoice to a customer.
pay. Sends an outbound payment across ACH, domestic and international wires, or USDC on Ethereum, Base, Solana, or Arbitrum (USDT on Ethereum is supported on the same tool).
Each tool ships with a documented request shape, response shape, required capability scope, and enforcement layer. The next five sections walk through each tool individually.
form_entity
The form_entity tool walks a founder through forming a US legal entity in a single tool call.

The entity_type field accepts LLC, C Corp, LLP, and LP. The state field accepts any US state's two-letter code. The beneficial_owner_verification_id comes from a Plaid Identity Verification session run before the form_entity call. PII never enters the agent client's context.
Required capability scope is form_entity. The scope is gated at the API gateway and cannot be composed at request time. An agent holding only read cannot escalate to form_entity by clever prompting; the server returns a 403 before the payment engine sees the request.
The post on forming an LLC in Claude walks the founder-facing version of this tool call end to end, with a real-time-stamped transcript and the exact prompts a Claude session generates.
open_account
The open_account tool opens a business bank account through Meow against an existing entity. The shape is simpler than form_entity because most of the data lives on the entity record already.

The operating_profile field hints at the partner-bank compliance review. Standard profiles (saas, services, ecommerce) route through the fast path. Atypical profiles (crypto_native, regulated_securities) route through a deeper review with longer turnaround. The agent surfaces the review status; the account holder does not need to babysit.
Required capability scope is open_account. The default capability_toggles on the returned account match the safe defaults: card issuance on, everything else off. The account holder turns the other toggles on explicitly.
issue_card
The issue_card tool issues a virtual or physical corporate card with spend controls.

The monthly_cap_cents field is the per-card spend cap. The mcc_restrictions field accepts an array of merchant category codes; the card declines any charge outside the allowed MCCs at the network level. The label field is for the account holder's reference and shows up in the audit log.
Required capability scope is issue_card. The default per-card cap is the lesser of the customer-set per-agent cap and the customer-set issuance ceiling. An agent cannot issue a card with a cap higher than the per-agent ceiling regardless of the prompt.
The card number returns in the response and is also added to the account holder's Apple Wallet or Google Wallet if the customer has wallet provisioning enabled.
create_invoice
The create_invoice tool generates an invoice and dispatches it to a customer.

Required capability scope is create_invoice. The invoice ships from the account's configured sender identity with the company's branding applied. Recurring invoice schedules are supported through a separate set of parameters on the same tool.
pay
The pay tool is the outbound payment surface. It covers ACH, domestic wires, international wires, and USDC on Ethereum, Base, Solana, and Arbitrum (USDT on Ethereum is supported on the same tool).

The rail field accepts ach, wire, usdc, and usdt. The chain field is required when the rail is usdc or usdt and accepts ethereum, base, solana, or arbitrum for USDC, and ethereum for USDT. Other chains are not currently supported; the server returns a 422 with the supported chain list if the request specifies an unsupported chain.
Required capability scope is payment_initiation. Because payment_initiation defaults to off, the response above shows status pending_approval and approval_required true. The account holder approves through SMS within the customer-set window (default 60 minutes); the payment executes on approval. The approval can also route through Slack, email, or in-app if the customer has configured those channels.
For payments above the customer-set dual-approval threshold (typical default $50,000 and above), two approvals are required and the response field approval_required returns "dual".
The Permissioning Grammar
The permissioning grammar is the technical underpinning of the safety story. Five components.
- Capability scopes. Each tool requires a specific capability scope on the agent's token: read, request_payment, issue_card, create_invoice, form_entity, payment_initiation. The scopes are versioned and cannot be composed at request time. An agent holding only read cannot construct a payment_initiation call.
- Caps and bounds. Per-card monthly caps, per-payment caps, per-day ramp ceilings, dual-approval thresholds, and per-agent ceilings across the full surface are all configurable per customer. Caps are enforced at the API gateway before the payment engine sees the request. The cap is structural rather than behavioral.
- Approval routing. Each capability that defaults to off has an approval routing rule. The default is SMS to the account holder's verified phone number. Slack, email, in-app, and dual-approval routes are configurable per capability and per amount band.
- Audit log. Every action lands in an append-only audit log with Ed25519 signatures over SHA-256 hashes of prior entries, batched into one-minute Merkle roots. The log captures the agent identity, the prompt, the data the agent acted on, and the outcome alongside the equivalent fields for human actions. The only distinguishing field between agent and human actions is the agent identity itself.
- Revocation. Token revocation is a single click in the Meow dashboard or a single tool call from any human on the account. Revocation propagates within seconds and is independent of token rotation.
The permissions model post on the Meow blog walks each component in depth; this post is the developer-facing summary.
Connecting Your Agent
The CLI command for connecting Claude is one line.
claude mcp add --transport http meow https://mcp.meow.com/cli
Confirm with claude /mcp. The OAuth flow runs through your email; the token lands in Claude's MCP store; the tool surface becomes available in the next conversation.
For Cursor, add the following to ~/.cursor/mcp.json:
{"mcpServers": {"meow": {"url": "https://mcp.meow.com/cli"}}}
For ChatGPT and Gemini, the connection runs through the respective client's MCP server configuration flow. Each client's flow is documented in its own docs.
Once connected, the tools are real banking primitives. Meow Technologies operates the agent-facing tool surface and the operational tooling. Banking services on the Meow account are provided by Grasshopper Bank, N.A., Member FDIC. Customer deposits are eligible for FDIC insurance through the partner bank under standard limits.
Frequently Asked Questions
What is Meow's MCP server? Meow's MCP server at mcp.meow.com is a Model Context Protocol endpoint that exposes Meow's business banking tool surface to AI agents on Claude, ChatGPT, Cursor, and Gemini. The agent can form entities, open accounts, issue cards, create invoices, and execute payments through documented tools with OAuth-scoped permissions.
How does an agent discover Meow's MCP server? Through the agent-discovery file at meow.com/.well-known/agent.json, which conforms to the IETF RFC 8615 /.well-known URI convention. Compliant agent clients (Claude, ChatGPT, Cursor, Gemini) check the file automatically; no manual configuration is needed.
What tools does Meow expose to AI agents? form_entity, open_account, issue_card, create_invoice, and pay. The pay tool covers ACH, domestic and international wires, and USDC on Ethereum, Base, Solana, and Arbitrum, plus USDT on Ethereum. The full tool list and request and response shapes are documented at meow.com/skills.md.
What is the authentication model for Meow's MCP server? OAuth 2.1 with PKCE. Scoped tokens default to read and request-to-spend; binary toggles for ACH, wire, card issuance, and payment initiation are configurable by the account holder. Tokens are short-lived with automatic rotation.
Can an AI agent execute payments without human approval? By default, no. Agents can prepare and request payments but cannot execute spend unilaterally without the account holder explicitly enabling the corresponding capability toggle. Approval workflows for wire, ACH, and check are configurable per transaction type.
What is the permissioning grammar for Meow's MCP tools? Each tool is gated by a capability scope on the agent's token. Capability scopes include read, request_payment, issue_card, create_invoice, form_entity, and payment_initiation. Caps and bounds are enforced server-side at the API gateway before the tool execution reaches the payment engine.
Where is the full Meow MCP documentation? The tool surface is documented at meow.com/skills.md. Each tool entry includes the request shape, the response shape, the required scope, and the enforcement layer. The meow.com/llms.txt file provides additional machine-readable context for agent clients.
Build With It
If you are building agentic workflows that touch business banking, the Meow MCP server gives you the bank-side primitives without you having to negotiate with a bank's API team for a quarter. Open Claude, paste the connect command, the tool surface lands in your next conversation. Build the workflow on top.
claude mcp add --transport http meow https://mcp.meow.com/cli
The skills file at meow.com/skills.md is the source of truth for the live tool shapes. Read it once before you ship anything against the production endpoint.