@skyramp/mcp 0.0.60-rc.2 → 0.0.60-rc.5

package/build/prompts/test-recommendation/recommendationSections.js

@@ -85,37 +85,25 @@ export function buildGenerationRules(isUIOnlyPR) {
 relationships in the code. If the pre-drafted scenarios don't match the real data model,
 replace them with accurate ones.
 
-**Priority ordering by PR type:**
-${isUIOnlyPR ? `This is a **UI-only PR**. The most valuable tests are UI and E2E tests.
-
-If Playwright traces exist for the changed pages, prioritize UI/E2E tests in the top 4.
-If no traces exist, UI/E2E tests are still the highest-value recommendations — rank them
-in the top 7 with scenario steps and trace recording instructions. The testbot will not
-generate tests without traces, so all 7 become additionalRecommendations.
-
-1. **UI tests** — per changed component/page
-2. **E2E tests** — per user flow spanning frontend to backend
-3. **Integration tests** — only when the changed UI calls backend APIs
-` : `1. **Multi-resource integration tests** — one per cross-resource workflow (2-3 max).
-2. **Fuzz tests** — per POST/PUT endpoint with complex request bodies. Tests boundary values,
-   type coercion, missing/extra fields, and edge cases the schema allows.
-3. **Contract tests** — per endpoint with new/changed response schemas. Validates the response
-   structure matches expectations (field types, required fields, nested objects).
-4. **E2E tests** — per distinct user flow if the API serves a frontend or client
-5. **CRUD lifecycle integration tests** — only for resources with new/changed endpoints
-   where multi-resource tests don't already cover them.
-`}When no Playwright trace exists, still recommend the test with instructions for recording
-a trace using \`skyramp_start_trace_collection\` with \`playwright: true\`.
-
-**Mixed PRs with frontend changes:** Include at least 1 E2E or UI test in the top 7,
-ranked by value regardless of trace availability. If traces exist, place it in the top 4.
-If no traces, it can still rank highly — the testbot will handle trace-dependent generation.
-
-**Before finalizing:** Check that the top 4 aren't filled with CRUD tests for unchanged
-resources when PR-relevant tests exist lower in the ranking. Swap if needed.
-
+**Available test types:**
+- **Integration** — multi-endpoint workflows that chain data across resources
+- **Fuzz** — boundary/invalid input testing for POST/PUT endpoints
+- **Contract** — response schema validation for new/changed endpoints
+- **E2E** — user journeys spanning frontend to backend (needs Playwright traces)
+- **UI** — frontend component interaction flows (needs Playwright traces)
+${isUIOnlyPR ? `
+This is a **UI-only PR** — no backend changes. UI and E2E tests are most relevant.
+Without Playwright traces, recommend them with trace recording instructions
+(\`skyramp_start_trace_collection\` with \`playwright: true\`).
+` : `
+When no Playwright trace exists, still recommend E2E/UI tests with instructions for
+recording a trace using \`skyramp_start_trace_collection\` with \`playwright: true\`.
+`}
 **No duplicate coverage.** If an existing test already covers an endpoint + test type,
-recommend a multi-resource workflow that includes that endpoint alongside others instead.`;
+recommend a different test that adds new coverage.
+
+Choose the test types and distribution that maximize coverage for this specific PR.
+No smoke tests.`;
 }
 export function buildToolWorkflows(authHeaderValue) {
     return `## How to Generate Tests — Tool Workflows
@@ -124,11 +112,14 @@ export function buildToolWorkflows(authHeaderValue) {
 
 **For multi-endpoint workflows (integration tests) — Scenario → Integration pipeline:**
 1. Call \`skyramp_scenario_test_generation\` once per step: \`scenarioName\`, \`destination\`,
-   \`baseURL\`, \`method\`, \`path\`, \`requestBody\`, \`authHeader: "${authHeaderValue}"\`.
+   \`baseURL\`, \`method\`, \`path\`, \`requestBody\`, \`responseBody\`, \`authHeader: "${authHeaderValue}"\`.
    \`statusCode\` is optional — defaults: POST→201, DELETE→204, GET/PUT/PATCH→200. Only override for non-standard codes.
    **OpenAPI spec is NOT required.** \`apiSchema\` is OPTIONAL — omit it if no spec exists.
    \`requestBody\` should use realistic field values from source code schemas (Zod, Pydantic, DTOs).
-   Inspect the source code to determine the correct request body shape — avoid sending \`{}\`.
+   \`responseBody\` should match the actual API response shape from source code (including all fields
+   returned by the controller — e.g., \`id\`, \`ownerId\`, \`createdAt\`, included relations like \`collection\`, \`tags\`).
+   Wrap in \`{"response": ...}\` if the API uses an envelope pattern. If omitted, a synthetic response is generated.
+   Inspect the source code to determine the correct request AND response body shapes — avoid sending \`{}\`.
    Use unique names with timestamp suffix to avoid conflicts on re-runs.
    For GET/PUT/DELETE with path IDs, use a placeholder — chaining resolves the real ID.
 2. Produces a \`scenario_<name>.json\` in the same \`outputDir\` as the test files (not \`.skyramp/\`).
@@ -162,32 +153,14 @@ Use it actively:
 - **Single-endpoint tests**: pass both \`endpointURL\` AND \`apiSchema\` for schema-aware generation.
 \n`
         : "";
-    const distribution = isUIOnlyPR
-        ? `- Prioritize UI tests (≥3), then E2E tests (≥2), then integration only if UI calls APIs. 0% smoke.`
-        : hasFrontendChanges
-            ? `- Mix: integration (2-3), E2E (1-2), UI (1-2), fuzz or contract (1). 0% smoke.`
-            : `- Mix: integration (2-3, multi-resource first), fuzz (1-2), contract (1-2), E2E (1 if user-facing flows exist). 0% smoke.`;
     return `## Coverage Checklist
 ${specNote}
-${isUIOnlyPR ? `**UI-only PR** — This PR has no backend changes. Focus on UI and E2E tests.
-
-With Playwright traces: prioritize UI tests (one per changed component) and E2E tests
-(one per page-level user flow). Integration tests are relevant only if the UI calls APIs.
-
-Without traces: recommend UI/E2E tests with scenario steps and trace recording instructions
-(\`skyramp_start_trace_collection\` with \`playwright: true\`). The testbot will skip generation
-entirely for frontend-only PRs without traces — all recommendations become additional
-recommendations in the report. Skip fuzz, contract, and smoke tests.
-` : `For each endpoint, recommend the most valuable test types — aim for variety:
-1. **Integration** — multi-resource workflows (not just single-resource CRUD)
-2. **Fuzz** — POST/PUT endpoints with request bodies (validates edge cases, type safety)
-3. **Contract** — endpoints with new/changed response schemas (validates structure)
-4. **E2E** — user flows spanning frontend to backend${hasFrontendChanges ? " (include at least 1 for this PR)" : ""}
-5. **UI** — changed frontend components${hasFrontendChanges ? " (include at least 1)" : ""}
-6. No smoke tests.
-Do NOT recommend 7 integration tests — diversify across test types.
+${isUIOnlyPR ? `**UI-only PR** — no backend changes.
+Without Playwright traces, the testbot skips generation entirely — all recommendations
+become additionalRecommendations in the report.
+` : `**Available test types:** integration, fuzz, contract, E2E, UI. No smoke tests.
+Choose based on what adds the most value for this PR's changes.
 `}
-
 ## For Each Recommendation Include:
 1. Test type  2. Priority (high/medium/low)  3. Target endpoint/scenario
 4. What it validates (business logic, not just "tests the endpoint")
@@ -203,20 +176,12 @@ Recommend the test anyway — never mark it "blocked":
 ## Select the Top ${topN}
 Consider all possible tests (endpoints \u00d7 interaction types + scenarios), then select the
 top ${topN} most valuable. Include \`totalConsidered\` count in your output. The top 4 will
-be generated; recommendations #5-${topN} will appear in the report but won't be generated,
+be generated; recommendations #5\u2013${topN} go to additionalRecommendations in the report,
 so ensure the top 4 are the highest-impact tests.
 
-**Before outputting, verify:**
-${isUIOnlyPR ? `- If traces exist, at least 2 of the top 4 should be UI/E2E tests.
-- Without traces, all 7 become additionalRecommendations (no generation). Rank UI/E2E highest.
-- Avoid CRUD tests for unchanged resources the UI doesn't call.` : `- If the PR includes frontend changes, include at least 1 E2E/UI test in the top 4.
-- CRUD tests for unchanged resources should not displace PR-relevant tests in the top 4.`}
 - Each integration scenario's step sequence should be logically valid — preconditions
   met by prior steps.
 
-Preferred ordering: ${isUIOnlyPR ? "UI \u2192 E2E \u2192 integration (if UI calls APIs)." : "integration \u2192 fuzz \u2192 contract \u2192 E2E \u2192 UI."}
-${distribution}
-
 Each recommendation should include enough detail for direct tool invocation.
 Reference draftedScenarios by name and interactions by description.
 Use "high"/"medium"/"low" for priority — no numeric scores.

package/build/prompts/test-recommendation/test-recommendation-prompt.js

@@ -26,10 +26,8 @@ export function buildRecommendationPrompt(analysis, analysisScope = "full_repo",
     const modePreamble = isDiffScope
         ? `You are in **PR mode**. Maximize test coverage for the branch changes.
 Focus on tests that validate the changed fields, endpoints, and their interactions.
-**CRITICAL**: Recommend MULTIPLE integration tests — at minimum one multi-resource workflow
-AND one CRUD lifecycle.
-${isUIOnlyPR ? `\n**UI-only PR.** Prioritize UI tests and E2E. Skip fuzz/contract.`
-            : hasFrontendChanges ? `\n**Mixed PR (frontend + API).** Integration > E2E > UI > fuzz/contract.`
+${isUIOnlyPR ? `\n**UI-only PR** — no backend changes. UI and E2E tests are most relevant.`
+            : hasFrontendChanges ? `\n**Mixed PR** — both frontend and backend changes detected.`
                 : ``}
 Output should be concise and immediately actionable.`
         : `You are in **Repo mode**. Comprehensive test strategy across all endpoints.`;
@@ -44,6 +42,10 @@ Output should be concise and immediately actionable.`
         : /session|cookie|nextauth/i.test(authMethod) ? "Cookie"
             : /api[_-]?key/i.test(authMethod) ? "X-API-Key"
                 : "Authorization";
+    const sourcePriority = `
+## Source Priority
+When information conflicts, prefer: **Traces** (actual behavior) > **Code** (implemented behavior) > **Spec/Docs** (documented behavior).
+`;
     const repoContext = `
 Repository: ${analysis.metadata.repositoryName}
 Framework: ${analysis.projectClassification.primaryFramework} (${analysis.projectClassification.primaryLanguage})
@@ -122,7 +124,7 @@ ${detailBlocks}
             })
                 .join("\n\n");
             scenarioSection = `
-## Drafted Scenarios — EACH = MANDATORY Integration Test
+## Drafted Scenarios
 **Base URL:** \`${baseUrl}\` | **Auth:** \`${authHeaderValue}\`
 
 Only use scenarios where resources are ACTUALLY related in the codebase. Replace any
@@ -172,6 +174,8 @@ Scope: ${scopeNote}
 
 ${buildTestQualityCriteria()}
 
+${sourcePriority}
+
 ${buildPrioritizationDimensions()}
 
 ${buildTestExamples()}

package/build/prompts/testbot/testbot-prompts.js

@@ -20,15 +20,21 @@ Read the diff at \`${diffFile}\`. Skip Task 1 if all changed files are non-appli
 
 1. Call \`skyramp_analyze_repository\` with \`repositoryPath\`: "${repositoryPath}", \`analysisScope\`: "current_branch_diff"${baseBranch ? `\n   , \`baseBranch\`: "${baseBranch}"` : ''}
 2. Call \`skyramp_recommend_tests\` with the returned \`sessionId\`.
-   It returns 7 ranked recommendations. Generate the top 4, report the remaining 3
-   as \`additionalRecommendations\`.
-
-3. **Generate** at most 4 tests from the top 4 recommendations. Stop after 4.
+   It returns 10 ranked recommendations. Walk through them in rank order and generate
+   up to 4 tests. Any recommendation you skip or cannot generate goes to
+   \`additionalRecommendations\`.
+
+3. **Generate** up to 4 tests by walking the ranked list top-to-bottom:
+   - If a recommendation can be generated, generate it and count it.
+   - If it cannot (e.g. E2E/UI without traces), move it to \`additionalRecommendations\`
+     and continue to the next recommendation.
+   - Stop once you have 4 generated tests OR exhaust all 10 recommendations.
+   - All remaining (ungenerated) recommendations go to \`additionalRecommendations\`.
    Keep a list of every file the CLI creates (test files AND scenario JSON files).
 
    **Frontend-only PRs** (no backend/API changes): only generate tests if relevant
    Playwright traces exist. If no traces are available, skip generation entirely and
-   move all 7 recommendations to \`additionalRecommendations\` with scenario steps and
+   move all 10 recommendations to \`additionalRecommendations\` with scenario steps and
    trace recording instructions. Do not generate integration tests for unchanged backend
    APIs just to fill the quota — those tests don't validate the PR's changes.
 

package/build/services/ScenarioGenerationService.js

@@ -7,7 +7,6 @@ export class ScenarioGenerationService {
             logger.info("Parsing scenario into API requests", {
                 scenarioName: params.scenarioName,
             });
-            // Generate a single trace request from the scenario
             const traceRequest = this.generateTraceRequestFromInput(params);
             if (!traceRequest) {
                 return {
@@ -20,12 +19,10 @@ export class ScenarioGenerationService {
                     isError: true,
                 };
             }
-            // Handle file writing
             const scenarioName = params.scenarioName.replace(/ /g, "-").toLowerCase();
             const fileName = `scenario_${scenarioName}.json`;
             const filePath = path.join(params.outputDir, fileName);
             try {
-                // Check if file exists to determine if we should append or create new
                 let existingRequests = [];
                 if (fs.existsSync(filePath)) {
                     try {
@@ -35,14 +32,11 @@ export class ScenarioGenerationService {
                             existingRequests = [];
                         }
                     }
-                    catch (parseError) {
-                        // If file exists but can't be parsed, start fresh
+                    catch {
                         existingRequests = [];
                     }
                 }
-                // Add the new request to the array
                 existingRequests.push(traceRequest);
-                // Write the updated array to the file
                 fs.writeFileSync(filePath, JSON.stringify(existingRequests, null, 2), "utf8");
                 logger.info("Trace request added to file", {
                     filePath,
@@ -107,7 +101,6 @@ ${JSON.stringify(traceRequest, null, 2)}
         let destination = params.destination;
         let scheme = "https";
         let port = 443;
-        // Derive scheme, host, and port from baseURL when available
         if (params.baseURL) {
             try {
                 const parsed = new URL(params.baseURL);
@@ -127,45 +120,28 @@ ${JSON.stringify(traceRequest, null, 2)}
         }
         const timestamp = new Date().toISOString();
         const method = params.method;
-        const path = params.path;
         const statusCode = params.statusCode;
         const requestBody = params.requestBody ||
             (method === "GET" || method === "DELETE" ? "" : "{}");
-        let responseBody = params.responseBody;
-        if (!responseBody) {
-            if (method === "DELETE") {
-                responseBody = "";
-            }
-            else if (method === "POST" && requestBody && requestBody !== "{}") {
-                responseBody = this.synthesizePostResponse(requestBody);
-            }
-            else {
-                responseBody = "{}";
-            }
-        }
-        const source = "192.168.65.1:39998";
-        // Build auth header from param or default to Bearer
+        const responseHeaders = params.responseHeaders
+            || { "Content-Type": ["application/json"] };
+        const isJsonResponse = (responseHeaders["Content-Type"] || [])
+            .some(v => v.includes("application/json"));
+        const responseBody = params.responseBody || (isJsonResponse ? "{}" : "");
         const authHeaderName = params.authHeader || "Authorization";
         const requestHeaders = {
             "Content-Type": ["application/json"],
+            [authHeaderName]: [params.authToken ?? ""],
         };
-        if (authHeaderName === "Cookie") {
-            requestHeaders["Cookie"] = ["session-token=demo-token"];
-        }
-        else {
-            requestHeaders[authHeaderName] = ["Bearer demo-token"];
-        }
         return {
-            Source: source,
+            Source: "192.168.65.1:39998",
             Destination: destination,
             RequestBody: requestBody,
             ResponseBody: responseBody,
             RequestHeaders: requestHeaders,
-            ResponseHeaders: {
-                "Content-Type": ["application/json"],
-            },
+            ResponseHeaders: responseHeaders,
             Method: method,
-            Path: path,
+            Path: params.path,
             QueryParams: {},
             StatusCode: statusCode,
             Port: port,
@@ -173,26 +149,4 @@ ${JSON.stringify(traceRequest, null, 2)}
             Scheme: scheme,
         };
     }
-    /**
-     * Generate a synthetic POST response body that echoes the request body
-     * wrapped in a "response" envelope with an auto-incrementing "id".
-     * This gives the CLI response data to chain from (e.g., response.id).
-     */
-    synthesizePostResponse(requestBody) {
-        try {
-            const parsed = JSON.parse(requestBody);
-            const id = Date.now() % 100000;
-            if (Array.isArray(parsed)) {
-                const withIds = parsed.map((item, idx) => ({
-                    id: id + idx,
-                    ...item,
-                }));
-                return JSON.stringify({ response: withIds });
-            }
-            return JSON.stringify({ response: { id, ...parsed } });
-        }
-        catch {
-            return "{}";
-        }
-    }
 }

package/build/tools/generate-tests/generateIntegrationRestTool.js

@@ -39,46 +39,12 @@ export class IntegrationTestService extends TestGenerationService {
     async generateTest(params) {
         const result = await super.generateTest(params);
         if (!result.isError && params.scenarioFile) {
-            const chainingInstructions = `
-
-⏭️ **CRITICAL NEXT STEP — Verify & Fix Chaining in Generated Test**
-
-The generated integration test uses \`chainingKey: "response.id"\` for all steps, but
-multi-resource workflows often need **different chaining per step**. You MUST:
-
-1. **Read the generated test file** in \`${params.outputDir}\`
-2. **Identify each API call** in the test (POST, GET, PUT, DELETE)
-3. **Verify chaining is correct** for each step:
-   - After each POST, the response ID must be extracted into a **uniquely named variable**
-     (e.g., \`product_id\`, \`order_id\`, \`review_id\` — NOT all named \`id\`)
-   - GET/PUT/DELETE calls that reference a resource must use the **correct** variable in their path
-     (e.g., \`/products/{product_id}\` uses the product's ID, not the order's ID)
-   - POST calls that create a child resource must include the **parent's ID** in the request body
-     or path (e.g., \`POST /orders\` body should include \`product_id\` from the products POST response)
-4. **Fix ONLY chaining** (path params AND request body ID references) — nothing else:
-   - Replace hardcoded path IDs (like \`/products/1\`) with the dynamic variable from the POST response
-   - Replace hardcoded IDs in request bodies (like \`"product_id": 1\`) with the dynamic variable
-     (use \`data_override\`/\`dataOverride\` or direct variable substitution)
-   - Rename duplicate variable names so each resource has its own ID variable
-   - For Python: use \`skyramp.get_response_value(response_N, "id")\` to extract and f-strings for paths
-   - For TypeScript: use \`getResponseValue(response, "response.id")\` or the appropriate accessor
-   ⚠️ **Preserve everything else exactly as generated** — do not add, remove, or modify
-   auth headers, cookies, tokens, env vars, imports, assertions, or non-chaining request body fields.
-   The CLI output for auth/headers is intentional.
-
-**Example fix for a products → orders workflow:**
-\`\`\`
-# Step 1: POST /products → extract product_id
-# Step 2: POST /orders with product_id in body → extract order_id  
-# Step 3: GET /orders/{order_id} → uses order_id (NOT product_id)
-# Step 4: DELETE /products/{product_id} → uses product_id (NOT order_id)
-\`\`\``;
             const existingText = result.content[0] && "text" in result.content[0] ? result.content[0].text : "";
             return {
                 content: [
                     {
                         type: "text",
-                        text: existingText + chainingInstructions,
+                        text: existingText,
                     },
                 ],
                 isError: false,

package/build/tools/generate-tests/generateScenarioRestTool.js

@@ -24,7 +24,7 @@ const scenarioTestSchema = {
         .describe("HTTP method (GET, POST, PUT, DELETE, etc.) parsed by AI from the scenario"),
     path: z
         .string()
-        .describe("API path (e.g., /api/v1/products, /api/v1/orders/{product_id}) parsed by AI from the scenario"),
+        .describe("API path parsed by AI from the scenario. CRITICAL: For requests that reference an ID created by a prior step (e.g. GET/PUT/DELETE after a POST), use the ACTUAL ID value from the prior step's responseBody in the path, NOT a template variable. Example: use '/api/v1/products/70885' instead of '/api/v1/products/{product_id}'. The CLI detects chaining by matching concrete values across requests."),
     // AI-parsed parameters (optional)
     requestBody: z
         .string()
@@ -43,6 +43,14 @@ const scenarioTestSchema = {
         .optional()
         .default("Authorization")
         .describe("Name of the HTTP header to use for authorization. Use 'Cookie' for cookie-based auth (e.g., NextAuth), 'Authorization' for Bearer tokens, 'X-API-Key' for API keys. Defaults to 'Authorization'."),
+    authToken: z
+        .string()
+        .optional()
+        .describe("Auth token value to include in the request header. If omitted, the header value is left empty (the CLI injects the real token at runtime)."),
+    responseHeaders: z
+        .record(z.array(z.string()))
+        .optional()
+        .describe('Response headers as a JSON object (e.g., {"Content-Type": ["application/json"]}). Defaults to Content-Type: application/json.'),
 };
 const TOOL_NAME = "skyramp_scenario_test_generation";
 export function registerScenarioTestTool(server) {
@@ -70,7 +78,7 @@ Returns a single TraceRequest object with:
 **AI Responsibilities:**
 The AI should parse the natural language scenario and provide:
 - HTTP method (POST, GET, PUT, DELETE)
-- API path (e.g., /api/v1/products, /api/v1/products/{product_id})
+- API path with CONCRETE ID values, not templates (e.g., /api/v1/products/70885, NOT /api/v1/products/{product_id})
 - Request body (JSON string, if applicable)
 - Response body (JSON string, if applicable)
 - Status code (optional, defaults based on method)

package/build/tools/test-recommendation/analyzeRepositoryTool.js

@@ -310,6 +310,7 @@ Output: Detailed RepositoryAnalysis JSON object with all repository characterist
                                     response: {
                                         statusCode: entry.statusCode,
                                         description: `Observed in trace (${traceResult.format})`,
+                                        ...(entry.responseBody ? { body: entry.responseBody } : {}),
                                     },
                                 });
                             }
@@ -333,6 +334,7 @@ Output: Detailed RepositoryAnalysis JSON object with all repository characterist
                         description: `${e.method} ${e.path} \u2192 ${e.statusCode}`,
                         interactionType: e.statusCode < 400 ? "success" : "error",
                         requestBody: e.requestBody,
+                        responseBody: e.responseBody,
                         expectedStatusCode: e.statusCode,
                     })),
                     chainingKeys: [],

package/build/tools/test-recommendation/recommendTestsTool.js

@@ -62,12 +62,11 @@ For each recommended test, you'll get:
 - For integration/E2E: references to draftedScenarios by scenarioName
 - Which Skyramp tool to call for generation
 
-**CRITICAL RULES**:
-- THE PRIORITY SHOULD ONLY BE DEFINED AS HIGH, MEDIUM, OR LOW NOTHING ELSE.
-- DO NOT SHOW ANY PRIORITY BREAKDOWN IN THE OUTPUT.
-- DON'T MARK ANY TEST BLOCKED EVEN IF REQUIRED ARTIFACTS ARE MISSING.
-- Reference specific interactions by description when recommending smoke/contract/fuzz tests.
-- Reference specific draftedScenarios by scenarioName when recommending integration/E2E tests.
+**Output guidelines:**
+- Use "high", "medium", or "low" for priority.
+- Never mark a test as blocked — recommend it with instructions for missing artifacts.
+- Reference specific interactions by description for contract/fuzz tests.
+- Reference draftedScenarios by scenarioName for integration/E2E tests.
 
 ** This tool is currently in Early Preview stage. Please verify the results. **`,
         inputSchema: recommendTestsSchema,
@@ -144,7 +143,7 @@ For each recommended test, you'll get:
             }
             const scope = analysisScope || "full_repo";
             const sessionId = params.sessionId;
-            const effectiveTopN = params.topN ?? (scope === "current_branch_diff" ? 7 : 10);
+            const effectiveTopN = params.topN ?? 10;
             // Fetch PR context when prNumber is provided and in diff scope
             let prContext = stateData.prContext;
             if (!prContext && params.prNumber && scope === "current_branch_diff") {

package/build/types/RepositoryAnalysis.js

@@ -64,6 +64,7 @@ export const scenarioStepSchema = z.object({
     description: z.string(),
     interactionType: z.enum(["success", "error", "edge-case"]),
     requestBody: z.record(z.any()).optional(),
+    responseBody: z.record(z.any()).optional(),
     expectedStatusCode: z.number(),
     expectedResponseFields: z.array(z.string()).optional(),
     chainsFrom: z

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyramp/mcp",
-  "version": "0.0.60-rc.2",
+  "version": "0.0.60-rc.5",
   "main": "build/index.js",
   "type": "module",
   "bin": {