* Split the Cursor plugin into plugins/cursor-link with MCP-first skills Cursor reaches Link through the hosted MCP server at api.cursor.com/rest-mcp/stripe-link/mcp, but the plugin's skills were the CLI-oriented ones shared with Claude and Codex via a symlink to the repo root. They told Cursor users to npm install @stripe/link-cli and to register a second, local stdio MCP server, which conflicts with the hosted one. Give Cursor its own self-contained plugin directory with no shared files, and write its skills against the tools the hosted server actually exposes: get_userinfo, list_spend_requests, get_spend_request, list_payment_methods, list_shipping_addresses, sign_web_bot_auth, and report_agent_observation. That server exposes no spend-request writes, so the purchase skill covers finding and spending against a request the user already approved and stops when none exists. Transactions, balances, and sources are not reachable yet, so no financial-insights skill ships here; plugins/link still covers that for CLI-based clients. With a real .mcp.json in the new directory there is no longer a symlinked .mcp.json to dodge, so the .link-cursor-mcp.json override is gone. Co-authored-by: Cursor <cursoragent@cursor.com> * Route spend approvals through request_virtual_card The skills described approval as something the agent could not do, which is true of the Link MCP server but not of Cursor, where request_virtual_card raises an approval card for exactly this. Rewrite the purchase flow around that tool: its argument contract (cents including tax and shipping, a 7-word title, a 100 to 140 character context, line items summing exactly to the total), the turn ending on the call, the already-pending and denied outcomes, and the 5/15/30/60 second poll of get_spend_request before retrieving the card. Co-authored-by: Cursor <cursoragent@cursor.com> * Call the product Link, not Stripe Link Review feedback from @danhill-stripe on the marketplace description. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
2.1 KiB
Link plugin for Cursor
Connects Cursor to a Link wallet through Link's hosted MCP server, so an agent can complete purchases with one-time-use payment credentials that the user has approved.
Layout
plugins/cursor-link/
├── .cursor-plugin/plugin.json # Cursor manifest
├── .mcp.json # Hosted Link MCP server
├── assets/link.svg # Plugin logo
└── skills/
├── complete-link-purchase/ # Buying flow
└── check-link-wallet/ # Read-only wallet inspection
This directory is self-contained. It shares no files with plugins/link/,
which serves Claude and Codex and is built around the link-cli binary. The
two are intentionally separate: Cursor talks to a hosted MCP server and never
installs or invokes the CLI, so the guidance each client needs is different
enough that sharing skill text made both worse.
Transport
Cursor reaches Link through https://api.cursor.com/rest-mcp/stripe-link/mcp.
Authentication is handled by Cursor's MCP OAuth flow. Users do not install
anything, and the skills here never shell out.
Capability boundary
The hosted server exposes reads plus two non-spend writes:
get_userinfo, list_spend_requests, get_spend_request,
list_payment_methods, list_shipping_addresses, sign_web_bot_auth,
report_agent_observation.
No tool on that server writes to a spend request, by design rather than omission: approval details attach at creation time, so whatever creates a request defines what the user consents to, and that belongs to a human.
Spend approvals instead run through Cursor's own request_virtual_card tool,
which raises an approval card showing the amount, merchant, reason, and
itemized cart. The agent's turn ends there. Nothing is created unless the user
approves, and on approval they finish authorizing on Link's page and the agent
is resumed with the spend request id to poll. complete-link-purchase is
written around that handoff.
Transactions, balances, and funding sources are not yet reachable, so this
plugin ships no financial-insights skill. plugins/link/ still covers that
ground for CLI-based clients.