From mercadopago
Audits a Mercado Pago integration against the official quality checklist and a fixed cross-cutting security checklist via the Mercado Pago MCP.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mercadopago:mp-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill audits a Mercado Pago integration. It does not duplicate the official quality criteria — it pulls them live from the MCP and verifies each one against the codebase.
This skill audits a Mercado Pago integration. It does not duplicate the official quality criteria — it pulls them live from the MCP and verifies each one against the codebase.
ListMcpResourcesTool is unreliable for this MCP (always returns "No resources found"). The bootstrap tools authenticate / complete_authentication are always present and prove nothing.
Check whether mcp__plugin_mercadopago_mcp__quality_checklist is callable AND returns a real payload. If not, stop and tell the user:
Call
mcp__plugin_mercadopago_mcp__authenticate, show the URL as a clickable link, and say: "When you see Authentication Successful in the browser, come back and say anything." When the user responds, callapplication_listdirectly — do NOT callcomplete_authenticationfirst (it hangs when the callback was already consumed). Never ask the user to paste the callback URL — it contains a sensitive OAuth code.
The official checklist lives behind the MCP — there is no offline fallback.
Use Grep/Glob to find:
mercadopago (any SDK).MP_ACCESS_TOKEN or hardcoded APP_USR- / TEST- strings./v1/payments, /v1/checkout/preferences, /v1/orders, payment.create, preference.create, order.create, preapproval.create, disbursement.webhook, notification, ipn).Determine:
/v1/payments) vs Orders API (/v1/orders). Both can coexist.
Needs attention item in the Implementation Report recommending the migration, with the file:line where /v1/payments is called. Do not treat it as a Blocker (existing code still works), but flag it as forward-looking technical debt./v1/checkout/preferences as legacy.Call mcp__plugin_mercadopago_mcp__quality_checklist. The response defines:
For every item returned (do not summarize, do not skip):
Grep/Read for evidence of the item (a field, a header, a behavior).These items are not always part of quality_checklist but are mandatory for any production integration. Always evaluate them:
| # | Check | How to verify |
|---|---|---|
| 1 | Access token in process.env / equivalent — never hardcoded | Grep for APP_USR- / TEST- outside .env* and test fixtures |
| 2 | .env is in .gitignore, .env.example is not | Read .gitignore |
| 3 | Webhook handler validates x-signature (HMAC-SHA256) | See mp-webhooks skill — Grep for x-signature, x-request-id, createHmac |
| 4 | HTTPS enforced for back_url and notification_url | Grep for http:// in URL building |
| 5 | Payment status verified server-side after redirect | Look for a server-side fetch of /v1/payments/{id} or /v1/orders/{id} after back_url |
| 6 | Idempotency key sent on payment/order creation | Grep for X-Idempotency-Key or SDK equivalent |
| 7 | external_reference set on every preference/order | Grep for external_reference |
| 8 | Test user credentials not committed to production deploy | Confirm test credentials are loaded from a separate env file or vault |
| 9 | sandbox_init_point not used anywhere | Grep for sandbox_init_point — flag any match as a bug; Mercado Pago has no sandbox, the URL is invalid in all environments |
quality_evaluation (only when compatible)quality_evaluation requires a real payment_id (or in the future, order_id). Do not force it; suggest only when the integration produced one and the tool's required ID matches the API in use.
| Tool requires | Integration uses | Action |
|---|---|---|
payment_id | Payments API | Suggest: "Run quality_evaluation against a recent test payment ID for a deeper score." |
payment_id | Orders API only | Do not suggest — incompatible. |
order_id (future) | Orders API | Suggest with a recent test order ID. |
order_id (future) | Payments API only | Suggest migrating to Orders API; do not force. |
After Steps 1–4 are complete, always render an Implementation Report as the last block of the output. This is the deliverable the developer keeps — it summarizes what's done, what's pending, and what to do next. Do not skip it, do not summarize it in prose; render the structured block below verbatim.
The report is the source of truth for the developer's next session: it tells them exactly what was verified, what was flagged, and the next concrete action. Without it, the review feels open-ended and the developer doesn't know if they can ship.
## Mercado Pago Integration Review
**Scope**: {full | security | webhooks | checkout | qr | subscriptions | marketplace | quality}
**API detected**: {Payments API | Orders API | both}
**Products detected**: {list}
**Files analyzed**: {list}
### CRITICAL
- {issues that block production or expose credentials}
### WARNINGS
- {issues that may cause incidents but do not block release}
### PASS
- {items correctly implemented}
### Quality Standards (from MCP `quality_checklist`)
#### Required fields
| # | Field | Description | Status | Evidence |
|---|-------|-------------|--------|----------|
| 1 | … | … | Implemented / Missing / Partial | path:line |
#### Best practices
| # | Practice | Description | Status | Evidence |
|---|----------|-------------|--------|----------|
| 1 | … | … | Implemented / Missing / Partial | path:line |
### Security checklist (cross-cutting)
| # | Check | Status | Evidence |
|---|-------|--------|----------|
### Recommendations
- {actionable, ordered by impact}
**Summary**: X/Y required fields implemented, Z/W best practices adopted, S/9 security checks pass.
> Want a deeper score? Provide a recent test payment ID (or order ID) and I'll run `quality_evaluation`.
---
## Implementation Report
### Verified
- [x] {item that passed — e.g., "Webhook handler validates x-signature with HMAC-SHA256"}
- [x] {next passing item}
### Needs attention
- [ ] {actionable item with file:line — e.g., "Add idempotency key to POST /v1/orders at api/orders.js:42"}
- [ ] {next pending item}
- [ ] {if legacy `/v1/payments` is detected — e.g., "Migrate POST /v1/payments to the Orders API (POST /v1/orders) at api/payments.js:42. The Payments API is being deprecated."}
### Blockers (must fix before production)
- [ ] {critical item — e.g., "Hardcoded APP_USR- token in config/mp.js:8 — move to env"}
### Next steps
1. {The single most impactful action the developer should take next}
2. {Follow-up actions in priority order}
3. Re-run `/mp-review` after fixes to confirm the report.
### Resources used
- MCP: `quality_checklist` ({date/time of call})
- MCP: `quality_evaluation` (if it was run, with the payment_id/order_id used)
- Skill: `mp-review` v4.1.0
**Scores**: {X}/{Y} required, {Z}/{W} best practices, {S}/9 security. **Verdict**: {Ready for production | Needs fixes | Blocked}.
mp-integrate.quality_evaluation is read-only and only suggested.npx claudepluginhub anthropics/claude-plugins-official --plugin mercadopagoScaffolds a complete Mercado Pago payment integration by collecting country, product, and SDK details, querying the official MCP server for live docs, and producing a ready-to-paste code bundle.
Audits a deployed repo for production-readiness gaps: RLS, webhooks, secrets, Stripe idempotency, mobile UX, indexes, observability, and more. Run pre-deploy or before launch.
Validates MPP payment integrations against specs: HTTP 402 challenges, payment headers, Stripe/Tempo methods, OpenAPI discovery, security, and production readiness. For audits and launches.