@skyramp/mcp 0.4.3 → 0.4.4-rc.2

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

@@ -115,7 +115,7 @@ Generate an integration test from a scenario file or a live endpoint trace.
 **Output filename:** When \`scenarioFile\` is provided and user did not specify a name, derive it: strip path and 'scenario_' prefix, replace hyphens/non-alphanum with underscores, append '_integration_test' + language extension. Example: 'scenario_orders-patch.json' → 'orders_patch_integration_test.py'. Never use the default 'integration_test.py' when scenarioFile is set — it collides.
 
 **IMPORTANT:** If \`apiSchema\` is provided in direct mode, pass the path/URL as-is — do NOT read the file contents. The backend processes it.`,
-        inputSchema: integrationTestSchema,
+        inputSchema: z.object(integrationTestSchema),
     }, async (params) => {
         if (params.scenarioFile && (params.apiSchema || params.endpointURL)) {
             return {

package/build/tools/generate-tests/generateLoadRestTool.d.ts

@@ -1,7 +1,6 @@
-import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { McpServer, CallToolResult } from "@modelcontextprotocol/server";
 import { TestType } from "../../types/TestTypes.js";
 import { TestGenerationService, BaseTestParams } from "../../services/TestGenerationService.js";
-import { CallToolResult } from "@modelcontextprotocol/sdk/types.js";
 export { loadTestSchema, numericString } from "./loadTestSchema.js";
 export declare class LoadTestService extends TestGenerationService {
     protected getTestType(): TestType;

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

@@ -1,3 +1,4 @@
+import { z } from "zod";
 import { TestType } from "../../types/TestTypes.js";
 import { TestGenerationService, } from "../../services/TestGenerationService.js";
 import { AnalyticsService } from "../../services/AnalyticsService.js";
@@ -41,7 +42,7 @@ Load tests evaluate your application's performance, scalability, and stability u
 
 **CRITICAL - When using trace parameter:**
 If \`trace\` parameter is provided (path to a trace file), DO NOT pass \`apiSchema\` or \`endpointURL\` parameters. The trace file already contains all necessary endpoint and schema information. Passing both will cause test generation to fail.`,
-        inputSchema: loadTestSchema,
+        inputSchema: z.object(loadTestSchema),
         _meta: {
             keywords: ["load test", "performance test"],
         },

package/build/tools/generate-tests/generateMockRestTool.d.ts

@@ -1,8 +1,7 @@
-import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { McpServer, CallToolResult } from "@modelcontextprotocol/server";
 import { MockProtocol } from "../../types/TestTypes.js";
 export { MockProtocol } from "../../types/TestTypes.js";
 import { TestGenerationService } from "../../services/TestGenerationService.js";
-import { CallToolResult } from "@modelcontextprotocol/sdk/types.js";
 export declare const MOCK_PROTOCOL_EXAMPLES = "\n<example protocol=\"rest\">\nGenerate a REST mock for one HTTP endpoint. Required fields: protocol=\"rest\", endpointURL, method. Use apiSchema with an empty method only when intentionally generating all schema methods.\n{\n  \"protocol\": \"rest\",\n  \"endpointURL\": \"http://payment-service:5001/orders/:order_id/payment_authorizations\",\n  \"method\": \"PUT\",\n  \"requestAware\": true,\n  \"requestData\": \"{\"payment_method_id\":\"pm_123\"}\",\n  \"responseData\": \"{\"accepted\":true}\",\n  \"responseStatusCode\": \"200\"\n}\n</example>\n\n<example protocol=\"rest-traffic-simulation\">\nGenerate a REST mock with traffic simulation (latency + drop rate). minLatency/maxLatency inject a random delay per response; dropRate drops a percentage of requests.\n{\n  \"protocol\": \"rest\",\n  \"endpointURL\": \"http://payment-service:5001/payments\",\n  \"method\": \"POST\",\n  \"responseData\": \"{\"status\":\"ok\"}\",\n  \"minLatency\": 500,\n  \"maxLatency\": 1000,\n  \"dropRate\": 10\n}\n</example>\n\n<example protocol=\"rest-conditional\">\nGenerate a conditional REST mock that selects a response based on request data. Use \"when\" to match request fields and \"requestSchema\" to validate the request body. Multiple mocks for the same endpoint+method are evaluated in order; the first matching \"when\" wins.\n{\n  \"protocol\": \"rest\",\n  \"endpointURL\": \"http://payment-service:5001/api/v1/orders\",\n  \"method\": \"POST\",\n  \"when\": {\"request.body.payment.method\": \"card\"},\n  \"requestSchema\": \"{\"type\":\"object\",\"required\":[\"orderId\",\"payment\"]}\",\n  \"responseData\": \"{\"status\":\"confirmed\"}\",\n  \"responseStatusCode\": \"201\",\n  \"noMatchStatusCode\": 404,\n  \"validationFailureStatusCode\": 422\n}\n</example>\n\n<example protocol=\"grpc\">\nGenerate a gRPC mock. Required fields: protocol=\"grpc\", endpointURL as host:port, protoPath, grpcServiceName. method is the RPC method name; omit or leave empty to generate all service methods. use responseData for successful protobuf-shaped responses, or grpcStatusCode/grpcStatusMessage for gRPC status errors.\n{\n  \"protocol\": \"grpc\",\n  \"endpointURL\": \"profile-service:50051\",\n  \"protoPath\": \"/repo/proto/profiles.proto\",\n  \"grpcServiceName\": \"ProfileService\",\n  \"method\": \"GetProfile\",\n  \"responseData\": \"{\"eligible\":true}\"\n}\n</example>\n\n<example protocol=\"grpc-traffic-simulation\">\nGenerate a gRPC mock with traffic simulation. Same latency/drop fields as REST.\n{\n  \"protocol\": \"grpc\",\n  \"endpointURL\": \"profile-service:50051\",\n  \"protoPath\": \"/repo/proto/profiles.proto\",\n  \"grpcServiceName\": \"ProfileService\",\n  \"method\": \"GetProfile\",\n  \"responseData\": \"{\"eligible\":true}\",\n  \"minLatency\": 200,\n  \"maxLatency\": 800,\n  \"dropRate\": 5\n}\n</example>\n\n<example protocol=\"grpc-status-error\">\nGenerate a gRPC status error mock. Do not provide responseData with grpcStatusCode.\n{\n  \"protocol\": \"grpc\",\n  \"endpointURL\": \"profile-service:50051\",\n  \"protoPath\": \"/repo/proto/profiles.proto\",\n  \"grpcServiceName\": \"ProfileService\",\n  \"method\": \"GetProfile\",\n  \"grpcStatusCode\": 5,\n  \"grpcStatusMessage\": \"profile not found\"\n}\n</example>\n\n<example protocol=\"kafka-producer\">\nGenerate a Kafka producer validation mock. Required fields: protocol=\"kafka\", endpointURL as broker host:port, kafkaTopic, and requestData. Do not pass method or responseData. Traffic simulation (minLatency/maxLatency/dropRate) is NOT supported for Kafka.\n{\n  \"protocol\": \"kafka\",\n  \"endpointURL\": \"broker:9092\",\n  \"kafkaTopic\": \"events\",\n  \"requestData\": \"{\"name\":\"order.created\"}\"\n}\n</example>\n\n<example protocol=\"kafka-consumer\">\nGenerate a Kafka consumer message mock. Required fields: protocol=\"kafka\", endpointURL as broker host:port, kafkaTopic, and responseData. Do not pass method or requestData. Traffic simulation (minLatency/maxLatency/dropRate) is NOT supported for Kafka.\n{\n  \"protocol\": \"kafka\",\n  \"endpointURL\": \"broker:9092\",\n  \"kafkaTopic\": \"events\",\n  \"responseData\": \"{\"accepted\":true}\"\n}\n</example>";
 type MockParams = {
     protocol?: MockProtocol;

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

@@ -110,7 +110,7 @@ Generate a Kafka consumer message mock. Required fields: protocol="kafka", endpo
 </example>`;
 const mockSchema = {
     protocol: z
-        .nativeEnum(MockProtocol)
+        .enum(MockProtocol)
         .default(MockProtocol.Rest)
         .describe("Protocol for the mock to generate. Use 'rest' for HTTP/OpenAPI mocks, 'grpc' for protobuf/gRPC mocks, and 'kafka' for Kafka topic mocks. See <example> blocks in the tool description for protocol-specific required fields."),
     endpointURL: z
@@ -209,7 +209,7 @@ const mockSchema = {
         .optional()
         .describe("MUST be absolute path to a trace file (e.g., /path/to/trace.json) to generate the mock from captured traffic."),
     when: z
-        .record(z.unknown())
+        .record(z.string(), z.unknown())
         .optional()
         .describe("Conditional-selection predicate (operator map) for REST and gRPC mocks. " +
         "When multiple mocks share an (endpoint, method), the server evaluates each mock's `when` in declared order " +
@@ -566,7 +566,7 @@ Mocks simulate REST, gRPC, or Kafka dependencies so that consumers can develop a
 3. Inline response data (\`responseData\`): generates a static mock with a fixed response.
 
 ${MOCK_PROTOCOL_EXAMPLES}`,
-        inputSchema: mockSchema,
+        inputSchema: z.object(mockSchema),
     }, async (params) => {
         const service = new MockGenerationService();
         const result = await service.generateTest(params);

package/build/tools/generate-tests/generateSmokeRestTool.d.ts

@@ -1,4 +1,4 @@
-import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { McpServer } from "@modelcontextprotocol/server";
 import { TestType } from "../../types/TestTypes.js";
 import { TestGenerationService, BaseTestParams } from "../../services/TestGenerationService.js";
 export declare class SmokeTestService extends TestGenerationService {

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

@@ -28,7 +28,7 @@ export function registerSmokeTestTool(server) {
 Smoke testing is a preliminary check used to verify that an endpoint is accessible and returns a valid response. Smoke tests are useful for quickly identifying critical defects after significant changes. They provide rapid validation for basic functionality verification and endpoint accessibility testing.
 
 **IMPORTANT: If an apiSchema parameter (OpenAPI/Swagger file path or URL) is provided, DO NOT attempt to read or analyze the file contents. These files can be very large. Simply pass the path/URL to the tool - the backend will handle reading and processing the schema file.**`,
-        inputSchema: smokeTestSchema,
+        inputSchema: z.object(smokeTestSchema),
         _meta: {
             keywords: ["smoke test", "quick test"],
         },

package/build/tools/generate-tests/generateUILoadRestTool.d.ts

@@ -0,0 +1,64 @@
+import { McpServer, CallToolResult } from "@modelcontextprotocol/server";
+import { z } from "zod";
+import { ProgrammingLanguage } from "../../types/TestTypes.js";
+/**
+ * One recorded journey becomes three files: the browser half, the protocol half, and the
+ * fleet manager that runs them together.
+ *
+ * The split is the point. A ui-load run measures one user flow at two levels at once --
+ * a few real browsers for what a person experiences, and cheap protocol traffic for what
+ * the backend carries -- so the numbers come from the same journey rather than from two
+ * tests that drifted apart.
+ */
+export declare const uiLoadTestSchema: {
+    playwrightTrace: z.ZodOptional<z.ZodString>;
+    playwrightInput: z.ZodOptional<z.ZodString>;
+    playwrightStoragePath: z.ZodDefault<z.ZodString>;
+    language: z.ZodPreprocess<z.ZodDefault<z.ZodEnum<typeof ProgrammingLanguage>>, unknown>;
+    framework: z.ZodPreprocess<z.ZodDefault<z.ZodString>, unknown>;
+    hosts: z.ZodArray<z.ZodObject<{
+        name: z.ZodString;
+        region: z.ZodDefault<z.ZodString>;
+        dockerHost: z.ZodDefault<z.ZodString>;
+        tls: z.ZodDefault<z.ZodString>;
+        hostPort: z.ZodDefault<z.ZodNumber>;
+        address: z.ZodDefault<z.ZodString>;
+        workerImage: z.ZodDefault<z.ZodString>;
+        workerTag: z.ZodDefault<z.ZodString>;
+    }, z.core.$strip>>;
+    browserCoverage: z.ZodDefault<z.ZodNumber>;
+    loadDuration: z.ZodDefault<z.ZodNumber>;
+    loadNumThreads: z.ZodDefault<z.ZodNumber>;
+    loadCount: z.ZodDefault<z.ZodNumber>;
+    loadTargetRPS: z.ZodDefault<z.ZodNumber>;
+    loadRampupDuration: z.ZodDefault<z.ZodNumber>;
+    loadRampupInterval: z.ZodDefault<z.ZodNumber>;
+    thresholds: z.ZodDefault<z.ZodString>;
+    deployWorker: z.ZodDefault<z.ZodBoolean>;
+    include: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    exclude: z.ZodDefault<z.ZodArray<z.ZodString>>;
+    output: z.ZodDefault<z.ZodString>;
+    outputDir: z.ZodString;
+    allowTraceReuse: z.ZodDefault<z.ZodBoolean>;
+    force: z.ZodDefault<z.ZodBoolean>;
+};
+type UILoadParams = z.infer<z.ZodObject<typeof uiLoadTestSchema>>;
+/**
+ * Generate the three ui-load files from one Playwright trace.
+ *
+ * Separate from the REST generators because it does not go through
+ * generateRestTestWrapper: ui-load has its own FFI export, which is what lets it take
+ * hosts and a browser/protocol split that the shared wrapper has no room for.
+ */
+export declare function generateUILoadTest(params: UILoadParams): Promise<CallToolResult>;
+/**
+ * The tool's entry point: the trace-reuse guard and the usage event around the generation,
+ * as skyramp_ui_test_generation has them.
+ *
+ * The guard is scoped "ui-load", not "ui". It namespaces by generator on purpose -- a UI
+ * test and a hybrid trio from one recording are different artifacts -- so what it stops
+ * here is a second, differently named TRIO from the same zip.
+ */
+export declare function handleUILoadTest(params: UILoadParams): Promise<CallToolResult>;
+export declare function registerUILoadTestTool(server: McpServer): void;
+export {};