mp-test-setup

mp-test-setup

This skill is the only place test users get created. It exists because the testing model is a frequent source of confusion.

---

The current testing model — read first

• There is no separate sandbox. Tests run against the production API using the credentials of a test user.
• Credential prefixes — two valid formats, both actively issued:
  • APP_USR-: Orders API, Checkout Pro, Point, QR Code, and test user credentials
  • TEST-: Checkout API / Payments API, Checkout Bricks, Subscriptions
  • Never tell a developer to change their prefix. get_credentials returns the correct format automatically.
• Never ask if a credential is "sandbox" by its prefix — the prefix alone does not distinguish test from production.
• A test user has its own balance (loaded via this skill) and behaves like any real account.
• For automated test credentials without creating a test user: in the Developer Dashboard, Tus integraciones → Datos de integración → Credenciales → click "Prueba" (Brazilian Portuguese: Suas integrações → Dados de integração → Credenciais → "Teste").

---

Step 0 — Verify MCP is actually authenticated

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__application_list is callable AND returns at least one application. 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, call application_list directly — do NOT call complete_authentication first (it hangs when the callback was already consumed). Never ask the user to paste the callback URL — it contains a sensitive OAuth code.

---

Step 1 — Resolve site_id before asking

The MCP does not currently return a site_id (its application_list only returns AppID/AppName/AppDescription, and the OAuth access token that would let us call /users/me is not exposed to the plugin client). Resolve in this order:

1. Use the country the agent already passed as country= — the agent already resolved it (persisted state or wizard).
2. Read .mp-integrate-progress.md at the project root — if a previous run persisted a country, reuse it.
3. Last resort: ask via AskUserQuestion (picker, never a numbered text block). Persist the answer to .mp-integrate-progress.md.

Do not grep the repo for currency_id/site_id literals or locale strings — they're unreliable on a clean repo and waste tokens.

Step 2 — Create a test user

Call mcp__plugin_mercadopago_mcp__create_test_user with:

Param	Required	Values
site_id	yes	MLA (Argentina), MLB (Brazil), MLM (Mexico), MLC (Chile), MCO (Colombia), MPE (Peru), MLU (Uruguay)
description	yes	Free text identifying the user (e.g., "buyer for checkout-pro tests")
profile	yes	seller or buyer — pick the role you need to simulate
amount	optional	Initial balance in the country's currency

The tool returns the user id, email, password, and APP_USR- credentials. Show them to the developer with a reminder: these are not committable secrets — load them from .env only.

If the developer needs both sides of a transaction (typical for marketplace, subscriptions, P2P), create one seller and one buyer.

---

Step 3 — Load funds (when needed)

Call mcp__plugin_mercadopago_mcp__add_money_test_user with:

Param	Required
test_user_id	yes — the id returned by create_test_user
amount	yes — number in the user's currency

Country-specific limits apply. If the call fails with a limit error, ask for a smaller amount and retry once.

---

Step 4 — Test cards

For card testing, do not invent card numbers. Query MCP search_documentation with "test cards {country}" (e.g., "test cards argentina") — the official set changes per country and per acquirer.

---

Step 5 — Hand the credentials to the developer

Output template:

## Test user created

**Country**: {country}
**Profile**: {seller | buyer}
**User id**: {id}
**Email**: {email}
**Initial balance**: {amount} {currency}

### Credentials (load from `.env`, never commit)

MP_ACCESS_TOKEN=APP_USR-... MP_PUBLIC_KEY=APP_USR-...

### Next steps
- Smoke test with `mp-webhooks` → `simulate_webhook`.
- Run `mp-review` to validate the integration once a payment goes through.
- For card payments, query MCP for current test cards: `search_documentation("test cards {country}")`.

---

Gotchas

• Test user credentials look identical to production credentials. If a .env file leaks, both buyer and seller balances are exposed.
• The test user's email/password are valid logins on mercadopago.com.{tld} — the developer can sign in to inspect movements.
• A test user belongs to the country specified by site_id; trying to use Argentine test credentials against the Brazilian site fails silently with a not_found payment.
• Adding money has per-country daily limits. If you hit them, create a fresh test user instead of bumping limits.

---

What this skill does NOT do

• It does not issue real production credentials. Those come from the Developer Dashboard.
• It does not validate webhooks (use mp-webhooks) or scaffold integration code (use mp-integrate).