fix(vtex): add fast health response for k8s readiness probes

.claude/skills/decocms-mcp-deploy/SKILL.md

@@ -38,12 +38,12 @@ MCPs pointing to external servers (Cloudflare official, Grain, Apify, etc.). No
 
 ## Workflow Summary
 
-| Workflow | Trigger | What it does |
-|----------|---------|--------------|
-| `checks.yml` | push/PR | fmt, lint, typecheck changed MCPs |
-| `publish-registry.yml` | push to main, manual | Publish app.json MCPs to Mesh registry |
-| `deploy.yml` | push to main, manual | Build + `deco deploy` for CF Worker MCPs |
-| `publish-jsr.yml` | push to main (shared/ or openrouter/) | Publish packages to JSR |
+| Workflow               | Trigger                               | What it does                             |
+| ---------------------- | ------------------------------------- | ---------------------------------------- |
+| `checks.yml`           | push/PR                               | fmt, lint, typecheck changed MCPs        |
+| `publish-registry.yml` | push to main, manual                  | Publish app.json MCPs to Mesh registry   |
+| `deploy.yml`           | push to main, manual                  | Build + `deco deploy` for CF Worker MCPs |
+| `publish-jsr.yml`      | push to main (shared/ or openrouter/) | Publish packages to JSR                  |
 
 No `deploy-preview.yml` — preview deploys on PRs were removed.
 
@@ -54,6 +54,7 @@ No `deploy-preview.yml` — preview deploys on PRs were removed.
 ### `detect-changed-mcps.ts`
 
 Detects which MCPs have changed based on:
+
 1. MCPs in `deploy.json` with `watch` patterns matching changed files
 2. Registry-only MCPs (have `app.json` but NOT in `deploy.json`) — detected if any file in their dir changed
 
@@ -95,15 +96,18 @@ All have `wrangler.toml` in their directory.
 ## Adding a New MCP to the Pipeline
 
 ### Custom server (kubernetes-bun)
+
 1. Add to `deploy.json` with `platformName: kubernetes-bun`
 2. Add `app.json` — `publish-registry.yml` handles it automatically
 
 ### CF Worker MCP
+
 1. Add to `deploy.json` with `platformName: cloudflare-workers`
 2. Ensure `wrangler.toml` exists in the MCP dir
 3. Optionally add `app.json` for registry metadata
 
 ### Official server (app.json only)
+
 1. Just create `app.json` — no `deploy.json` entry needed
 2. `publish-registry.yml` auto-detects it as a registry-only MCP
 
@@ -131,8 +135,8 @@ mcps: "perplexity,slack-mcp"
 
 ## Secrets Required
 
-| Secret | Used by |
-|--------|---------|
-| `DECO_DEPLOY_TOKEN` | deploy.yml (deco deploy CLI) |
-| `PUBLISH_API_KEY` | publish-registry.yml |
+| Secret                    | Used by                                    |
+| ------------------------- | ------------------------------------------ |
+| `DECO_DEPLOY_TOKEN`       | deploy.yml (deco deploy CLI)               |
+| `PUBLISH_API_KEY`         | publish-registry.yml                       |
 | `OPENAI_API_KEY` + others | deploy.yml (env vars passed to CF Workers) |

.claude/skills/decocms-mcp-development/SKILL.md

@@ -22,6 +22,7 @@ Working directory: `/Users/jonasjesus/conductor/workspaces/mcps/san-antonio` (or
 ### Type 1: Official Server (app.json only)
 
 The MCP runs on an external server (Cloudflare, Grain, GitHub, etc.). We only provide:
+
 - `app.json` — connection URL, auth, metadata
 - `README.md` — optional
 
@@ -32,6 +33,7 @@ No `package.json`, no `deploy.json` entry, no workspace entry in root `package.j
 ### Type 2: Custom Server (deco HTTP)
 
 We build and host the server. Files:
+
 ```
 <mcp-name>/
   app.json          # registry metadata + connection URL
@@ -67,7 +69,9 @@ const runtime = withRuntime<Env>({
   tools: (env: Env) => tools.map((createTool) => createTool(env)),
 });
 
-if (runtime.fetch) { serve(runtime.fetch); }
+if (runtime.fetch) {
+  serve(runtime.fetch);
+}
 ```
 
 ### `shared/deco.gen.ts`
@@ -205,12 +209,12 @@ When an official HTTP server exists (e.g., `https://api.example.com/mcp`):
 
 ## Key Packages
 
-| Package | Purpose |
-|---------|---------|
-| `@decocms/runtime` | `withRuntime`, `createPrivateTool` |
-| `@decocms/mcps-shared` | `serve` utility |
-| `zod` | Input schema validation |
-| `undici` | Proxy-aware fetch, SSE streaming |
+| Package                | Purpose                            |
+| ---------------------- | ---------------------------------- |
+| `@decocms/runtime`     | `withRuntime`, `createPrivateTool` |
+| `@decocms/mcps-shared` | `serve` utility                    |
+| `zod`                  | Input schema validation            |
+| `undici`               | Proxy-aware fetch, SSE streaming   |
 
 ## Common Patterns
 

.github/workflows/README.md

@@ -9,6 +9,7 @@ This directory contains the centralized deployment workflows for all MCPs in the
 **Trigger**: Push to `main` branch
 
 **What it does**:
+
 1. Detects which MCP directories have changed
 2. Builds and deploys only the changed MCPs to production
 3. Uses the `deco deploy` command for each changed MCP
@@ -20,6 +21,7 @@ This directory contains the centralized deployment workflows for all MCPs in the
 **Trigger**: Pull requests to `main` branch
 
 **What it does**:
+
 1. Detects which MCP directories have changed in the PR
 2. Builds and deploys preview versions (without promoting)
 3. Comments on the PR with preview URLs for each deployed MCP
@@ -45,11 +47,13 @@ Both workflows use **automatic MCP discovery** powered by a TypeScript script (`
 ## Adding a New MCP
 
 **No configuration needed!** Just create a new directory with a `package.json` and the workflows will automatically:
+
 - Detect it as an MCP
 - Monitor it for changes
 - Deploy it when changes occur
 
 Example:
+
 ```bash
 mkdir my-new-mcp
 cd my-new-mcp
@@ -73,13 +77,15 @@ Both workflows use GitHub Actions matrix strategy to deploy multiple MCPs in par
 ## Failure Handling
 
 The workflows use `fail-fast: false` in their matrix strategy, which means:
+
 - If one MCP fails to deploy, others will continue
 - You'll get individual success/failure notifications for each MCP
 - The overall workflow will be marked as failed if any MCP fails
 
 ## Deployment Script
 
 Both workflows use the TypeScript deployment script located at `scripts/deploy.ts`. This script:
+
 - Changes to the MCP directory
 - Installs dependencies with Bun
 - Runs the build script
@@ -89,4 +95,3 @@ Both workflows use the TypeScript deployment script located at `scripts/deploy.t
 ## Artifacts
 
 The preview deployment workflow creates temporary artifacts containing deployment information (MCP name and preview URL) which are used to construct the PR comment. These artifacts are automatically cleaned up after 1 day.
-

.github/workflows/SECRETS.md

@@ -5,35 +5,42 @@ This document lists all secrets required to deploy MCPs via GitHub Actions.
 ## Required Secrets
 
 ### `DECO_DEPLOY_TOKEN`
+
 - **Used by**: All MCPs
 - **Description**: Authentication token for Deco CLI
 - **How to obtain**: Generated via Deco CLI or dashboard
 
 ## Optional Secrets (per MCP)
 
 ### MCP: `sora`
+
 - **`OPENAI_API_KEY`**: OpenAI API key for Sora model
   - Obtain at: https://platform.openai.com/api-keys
 
 ### MCP: `veo`
+
 - **`GOOGLE_GENAI_API_KEY`**: Google Generative AI API key for Veo model
   - Obtain at: https://aistudio.google.com/app/apikey
   - ⚠️ **Important**: The code expects `GOOGLE_GENAI_API_KEY`, not `VEO_TOKEN`
 
 ### MCP: `nanobanana`
+
 - **`NANOBANANA_API_KEY`**: API key for Nanobanana service (OpenRouter)
   - Obtain at: https://openrouter.ai/keys
 
 ### MCP: `openrouter`
+
 - **`OPENROUTER_API_KEY`**: API key used by OpenRouter MCP
   - Obtain at: https://openrouter.ai/keys
 
 ### MCP: `pinecone`
+
 - **`PINECONE_TOKEN`**: Pinecone API token
   - Obtain at: https://app.pinecone.io/
 - **`PINECONE_INDEX`**: Pinecone index name (if required)
 
 ### MCP: `meta-ads`
+
 - **`META_ACCESS_TOKEN`**: Facebook Access Token for Meta Ads API
   - Obtain at: https://developers.facebook.com/tools/explorer/
   - Select your app and generate token with required permissions:
@@ -64,12 +71,13 @@ When you need to add support for a new secret:
 
 2. **Update the deploy script** (`scripts/deploy.ts`):
    - Add the variable name to the `envVarsToPass` array (around line 139)
+
    ```typescript
    const envVarsToPass = [
      "OPENAI_API_KEY",
      "GOOGLE_GENAI_API_KEY",
      "NANOBANANA_API_KEY",
-     "YOUR_NEW_SECRET",  // <- Add here
+     "YOUR_NEW_SECRET", // <- Add here
      // ...
    ];
    ```
@@ -81,14 +89,15 @@ When you need to add support for a new secret:
    env:
      DECO_DEPLOY_TOKEN: ${{ secrets.DECO_DEPLOY_TOKEN }}
      OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
-     YOUR_NEW_SECRET: ${{ secrets.YOUR_NEW_SECRET }}  # <- Add here
+     YOUR_NEW_SECRET: ${{ secrets.YOUR_NEW_SECRET }} # <- Add here
    ```
 
 ⚠️ **Note**: Yes, you still need to edit the workflows, but now it's simpler and centralized. Just add one line in the `env:` section.
 
 ## ⚠️ Attention: Rename VEO_TOKEN Secret
 
 If you have a secret called `VEO_TOKEN`, you need to:
+
 1. Create a new secret called `GOOGLE_GENAI_API_KEY` with the same value as `VEO_TOKEN`
 2. Delete the `VEO_TOKEN` secret (or keep it if you prefer)
 

.github/workflows/deploy.yml

@@ -7,7 +7,7 @@ on:
         description: 'MCPs to deploy (comma-separated, e.g. "discord-read,slack-mcp"). Leave empty to detect from changes.'
         required: false
         type: string
-        default: ''
+        default: ""
   push:
     branches:
       - main

.github/workflows/publish-registry.yml

@@ -7,9 +7,9 @@ on:
         description: 'MCPs to publish (comma-separated, e.g. "discord-read,slack-mcp"). Leave empty to detect from changes.'
         required: false
         type: string
-        default: ''
+        default: ""
       dry_run:
-        description: 'Dry run (preview payloads without publishing)'
+        description: "Dry run (preview payloads without publishing)"
         required: false
         type: boolean
         default: false

README.md

@@ -1,4 +1,4 @@
-# mcps 
+# mcps
 
 First-party MCPs maintained by the decocms team.
 

airtable/package.json

@@ -1,8 +1,8 @@
 {
   "name": "@decocms/airtable",
   "version": "1.0.0",
-  "description": "Airtable MCP for database operations",
   "private": true,
+  "description": "Airtable MCP for database operations",
   "type": "module",
   "scripts": {
     "dev": "bun run --hot server/main.ts",

amplitude/README.md

@@ -5,11 +5,13 @@
 **Amplitude MCP** is a Model Context Protocol (MCP) server that connects AI assistants to Amplitude's product analytics platform for querying events, charts, cohorts, and user insights.
 
 ### Purpose
+
 - Query Amplitude analytics data including event trends, funnels, and retention metrics
 - Access chart and dashboard data to surface product insights from AI tools
 - Explore user cohorts and behavioral segments programmatically
 
 ### Key Features
+
 - 📈 Query event data, trends, and conversion funnels
 - 🔁 Retrieve retention and engagement metrics
 - 👥 Access and manage user cohorts and segments

apify/README.md

@@ -1,4 +1,4 @@
-# Apify MCP 
+# Apify MCP
 
 ## Project Description
 
@@ -7,6 +7,7 @@
 ### Purpose
 
 This MCP server allows client applications to:
+
 - List available Apify actors
 - Get details about specific actors
 - Run actors synchronously or asynchronously
@@ -34,24 +35,29 @@ Get your Apify API token at: https://console.apify.com/account/integrations
 ## Available Tools
 
 ### `list_actors`
+
 List all actors accessible to the user.
 
 ### `get_actor`
+
 Get details of a specific actor by ID or name.
 
 ### `list_actor_runs`
+
 List runs of a specific actor with filtering options.
 
 ### `get_actor_run`
+
 Get details of a specific actor run, optionally including dataset items.
 
 ### `run_actor_sync`
+
 Run an actor synchronously and return dataset items when complete.
 
 ### `run_actor_async`
+
 Run an actor asynchronously and return immediately with run ID.
 
 ## License
 
 MIT
-

apify/app.json

@@ -18,4 +18,3 @@
     "mesh_description": "The Apify MCP provides comprehensive integration with the Apify platform, enabling AI agents to run web scraping actors, manage automation tasks, and extract data from websites. This MCP allows listing available actors, getting actor details, running actors synchronously or asynchronously, and retrieving run results with dataset items. Perfect for building intelligent automation workflows, data collection pipelines, and web monitoring solutions. Authentication is done via Apify API token passed in the Authorization header."
   }
 }
-