A full guided MCP run on a brownfield repo takes ~6–7 minutes — not because the tool is slow, but because most of the work is comprehend: finding webhook handlers that already exist and failure paths that only hit stdout today.
This post captures that shape without turning into another MCP setup tutorial.
The ask
add slack notifications for failed payments — plug into existing stripe + resend webhook handlers
The repo already had Stripe checkout, Clerk JWT verification, and Resend receipt webhooks from earlier sessions. Slack is the fourth layer.
What brownfield changes
Greenfield tutorials add a route. Brownfield work attaches side effects to lines that already exist:
| Event | Typical brownfield gap |
|---|---|
payment_intent.payment_failed | logged only — alert target |
email.bounced / email.complained | logged + TODO |
| receipt send raises | swallowed so Stripe does not retry |
The agent should not invent /slack-webhook when the correct move is additive handler code.
What FetchSandbox routed to
There is no Slack spec in the catalog, so guide() routed to Stripe upstream: prove the event your alert depends on, not the Slack POST itself.
Discovery that mattered: US customers, auto-capture, and declined card failure coverage. Without the failures tab, you only prove happy path.
Honest limit from the run
The curated accept_payment workflow passed, but payment_intent.payment_failed did not materialize in sandbox. Real decline proof still needs:
stripe listen --forward-to localhost:8000/webhook
# card 4000000000000002
or stripe trigger payment_intent.payment_failed.
What the agent got right
- No new endpoint — side effects only at existing handler lines.
- Third target surfaced — receipt-send swallow, not only the two webhooks named in the prompt.
- Routing limitation named — upstream Stripe proof; Slack downstream on you.
- Idempotency applied to alerts — Stripe retries on 5xx; dedupe with
pi.id. - Resend proof deferred — one workflow per delegation.