DEV Community

Edison Flores
Edison Flores

Posted on

Replies to ecosystem feedback: i18n, sandboxing, install paths, and the ACP layer

#mcp #ai #devops #i18n

This is a public reply to feedback on the MarketNow ecosystem posts (i18n, sandboxing, install observability, and protocol design). The dev.to API does not support comment replies via API, so I am posting this as an article.

1. Reply to @pakvothe (Franco Ortiz) on "5 idiomas" (i1n MCP server)

Gracias Franco! Tu observación es correcta — los TRANSLATIONS a mano escalan mal cuando el producto cambia seguido. Cada string nuevo son 5 ediciones y algo siempre queda atrás.

Miré i1n.ai y me parece excelente. El hecho de que tenga su propio MCP server y esté en el registry oficial de Anthropic es la validación que buscaba. Para MarketNow, el caso de uso sería:

  1. Strings en JSON por idioma (ya lo tenemos así)
  2. i1n push --translate completa los 5 idiomas con IA
  3. Check en CI avisa cuando un idioma queda atrás

Voy a probarlo. Si funciona bien con 8,845 skills (que tienen descripciones multilingües), te aviso. Ese es un buen stress test.

¿Tienes un tier gratis para OSS projects? Nuestro marketplace es 100% free (los sellers pagan por prioridad, los usuarios instalan gratis). Happy to give i1n visibility in our docs if it works.

2. Reply to @alexshev on "MarketNow 2.0" (recovery choices)

Great point. The exposed health surface is a start, but the next useful signal is whether the agent can turn those states into a recovery choice: retry later, switch endpoint, ask for credentials, or stop with a useful reason.

Currently the /api/health endpoint returns:

{"ok": true, "v": "4.0.0", "t": 1786149913479}
Enter fullscreen mode Exit fullscreen mode

This is too minimal. What you are describing is a structured failure taxonomy — the agent needs to know not just "is it up" but "what should I do if it is down". We already have a failure-taxonomy.json file (15 categories) at https://marketnow.site/failure-taxonomy.json, but it is not yet wired into the health endpoint.

The plan:

  • /api/health returns {status, version, last_deploy, degraded_services[], recommended_action}
  • If a downstream service (GitHub, Stripe, Vercel) is degraded, recommended_action tells the agent: "retry in 60s", "use cached data", "switch to direct_purchase mode", etc.
  • The agent's decision tree reads recommended_action and acts accordingly

This is the right next step. Thanks for pushing on it.

3. Reply to @alexshev on "MarketNow 2.0" (observable install path)

You are right that downloads are a vanity metric. The stronger signal is: can users connect, run a first workflow, and know what failed?

We added a /api/agent-ping endpoint that returns the install path for any skill:

{
  "skill_id": "mn-gen-00003",
  "install_command": "npx -y marketnow-mcp",
  "first_workflow_steps": [...],
  "common_failure_modes": [...]
}
Enter fullscreen mode Exit fullscreen mode

But we do not yet track whether users actually complete the install. That is the missing piece. The plan is to add an opt-in telemetry endpoint that agents can call to report install success/failure, so we can see where the funnel breaks.

Privacy-preserving: no PII, just {skill_id, success: bool, error_class: string, agent_type: string}. Opt-in via MARKETNOW_TELEMETRY=1 env var.

4. Reply to @23cse_132_ritikagaur on "5 idiomas" (localStorage context)

Thanks! The localStorage context is lean — no react-i18next dependency, just a 20-line React context that reads/writes localStorage.lang and re-renders on change. For a marketplace with 8,845 skills, keeping the i18n layer small matters for bundle size.

Your visual cheatsheets at rtam.tech look great — followed. If you ever want to make an MCP security cheatsheet, happy to feature it in our docs.

5. Reply to @custralis on "How to sandbox" (full hardening)

You are 100% right. --network none alone is not enough. The full hardening we use in the L2.5 gVisor sandbox:

docker run --rm   --runtime=runsc   --network none   --read-only   --cap-drop ALL   --security-opt no-new-privileges   --memory 256m   --cpus 0.5   --pids-limit 64   --tmpfs /tmp:rw,size=64m   --user 65534:65534   mcp-audit-target
Enter fullscreen mode Exit fullscreen mode

The --read-only rootfs + tmpfs /tmp prevents persistent writes. The --cap-drop ALL + no-new-privileges prevents privilege escalation. The --pids-limit 64 prevents fork bombs. The --user 65534:65534 (nobody) means even if the container escapes gVisor, it has no privileges.

For servers that need outbound calls, your suggestion of a pinned egress proxy (host allowlist) is exactly right. We have an egress-allowlist.json at https://marketnow.site/egress-allowlist.json that lists the domains MCP servers are allowed to contact during sandbox testing. Anything not on the list gets blocked.

The gVisor layer (runsc) is the key differentiator — it intercepts syscalls in userspace, so the MCP server never touches the host kernel. Even if gVisor has a bug, the attacker is still in a --read-only --cap-drop ALL --network none container with no privileges.

6. Reply to @wrencalloway on "Responding to feedback" and "L3"

Thanks for the kind words and the thoughtful feedback across multiple posts. Your point about tool-description-poisoning (different descriptions for scanner vs real client) is the most important gap in the current stack, and we are building L3.5 (tool catalog diff) to address it. Will tag you when the design doc is up.

7. Reply to @mayank609 on "L3" thread (runtime enforcement agreement)

Completely agree with your distinction between continuous re-certification and runtime enforcement. The architecture is converging on exactly this split:

  • L3 = periodic re-attestation (re-plays the sandbox weekly, detects drift)
  • L4 = runtime enforcement (eBPF at the kernel boundary, blocks in real-time)
  • L3.5 (planned) = tool catalog diff (catches per-client description poisoning)

Thanks for the shoutout on Failproof AI. Would love to compare notes on your runtime enforcement design — are you hooking at the MCP client, the agent framework, or the kernel?

The marketplace is at https://marketnow.site. The trust ledger (57 ATCs + 2 receipts) is publicly auditable at https://marketnow.site/api/atc. The security methodology is at https://marketnow.site/security.

Cross-posted as a public reply because the dev.to API does not support comment creation via API key.

Top comments (0)