Files
Jason f77d7451d4 Split the Cursor plugin into plugins/cursor-link with MCP-first skills (#276)
* 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>
2026-08-28 09:12:57 -04:00

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.