@astrasyncai/verification-gateway 2.4.12 → 2.5.0

package/dist/adapters/mcp.d.mts

@@ -1,5 +1,5 @@
 import { Request, Response, RequestHandler } from 'express';
-import { A as AccessLevel, G as GatewayConfig, i as VerificationResult } from '../types-L15pYd2c.mjs';
+import { A as AccessLevel, G as GatewayConfig, i as VerificationResult } from '../types-B3USs-Kx.mjs';
 
 /**
  * MCP server-side helpers — companion to `transport/mcp.ts` (which handles the
@@ -85,7 +85,7 @@ interface ParsedMcpRequest {
      * (canonical SDK location) OR `params.arguments.purpose` (legacy /
      * conventional callers). The discriminator is on `purposeSourceFromBody`.
      * Adapter combines this with the `X-Astra-Purpose` header (header wins)
-     * before mapping; final fallback at `mcpToPdlss` is `'mcp_invoke'`.
+     * before mapping; final fallback at `mcpToPdlss` is `undefined`.
      */
     purposeFromBody?: string;
     /** Which body location resolved `purposeFromBody`. */
@@ -120,60 +120,45 @@ declare function parseMcpJsonRpc(body: unknown): ParsedMcpRequest | null;
 /**
  * PDLSS mapping for an MCP request. The platform's PDLSS taxonomy is
  * `purpose / action / resource`; for MCP traffic the audit-useful dimensions
- * are the JSON-RPC method and (for `tools/call`) the tool name. Doc-stable so
- * dashboards and audits can correlate consistently across cohort-3 partners.
+ * are the JSON-RPC method and (for `tools/call`) the tool name.
  *
- * Rules:
- *   - `purpose` is always `mcp_invoke` for MCP traffic — sets the high-level
- *     PDLSS bucket.
- *   - `action` is the JSON-RPC method, optionally `:tool_name` suffixed for
- *     `tools/call`. Lets PDLSS allowlist specific tools.
- *   - `resource` is `mcp:tool/<name>` for `tools/call`, `mcp:method/<method>`
- *     otherwise. Lets PDLSS scope on tool identity.
+ * v2.5.0 rules:
+ *   - `resource` defaults to the HTTP request path (e.g. `/mcp`). Per-tool
+ *     overrides via `toolGates` config let merchants map tools to specific
+ *     backend resources (e.g. `/api/catalog`).
+ *   - `purpose` defaults to `undefined` (backend evaluator applies
+ *     skip-when-undefined). Per-tool overrides via `toolGates` config let
+ *     merchants declare the semantic purpose each tool fulfils.
+ *   - `action` is the bare tool name for `tools/call`, the JSON-RPC method
+ *     otherwise. Header/body overrides available.
  */
 interface McpPdlssMapping {
-    purpose: string;
+    purpose: string | undefined;
     action: string;
     resource: string;
-    /**
-     * Round-13 (R13-1 / R13-2): the resolution channel for purpose and
-     * action — disjoint enums sharing the same structure per
-     * `feedback_symmetric_fallbacks_for_symmetric_concepts.md`. Adapters
-     * log both at debug level so partners can confirm header / body
-     * pass-through, support can triage tickets, and we can watch the
-     * `default_*` / `transport_layer` decay over time as integrations
-     * mature.
-     *
-     * Round-12 (F19) used a narrower `purposeSource: 'header' |
-     * 'tool_argument' | 'default_mcp_invoke'` — round-13 widens to also
-     * carry the `_meta` source distinct from `tool_argument`, so the round-13
-     * R13-1 fallback (which now reads both `_meta.astrasync.purpose` AND
-     * `params.arguments.purpose`) can report WHICH body location resolved.
-     */
-    purposeSource: 'header' | 'meta' | 'tool_argument' | 'default_mcp_invoke';
+    purposeSource: 'header' | 'meta' | 'tool_argument' | 'tool_gate' | undefined;
     actionSource: 'header' | 'meta' | 'tool_argument' | 'transport_layer';
 }
 /**
- * Round-13 (R13-1 + R13-2) — canonical precedence chain documented ONCE,
- * applied identically to both purpose and action. Per
- * `feedback_symmetric_fallbacks_for_symmetric_concepts.md` — drift
- * between two paired concepts generates the same support-ticket class
- * repeatedly, so the resolution order is:
+ * v2.5.0 — PDLSS field derivation for MCP requests.
+ *
+ * Purpose precedence:
+ *   - If `toolGate.purpose` is provided, it is authoritative (header/body ignored).
+ *   - Otherwise: header → body `_meta` → body `arguments` → `undefined`.
+ *
+ * Resource precedence:
+ *   - `toolGate.resource` if provided, else `requestPath`.
  *
- *   1. `X-Astra-<concept>` HTTP header (caller's explicit override)
- *   2. `params._meta.astrasync.<concept>` body field (canonical SDK location)
- *   3. `params.arguments.<concept>` body field (legacy / conventional)
- *   4. Transport-layer default:
- *        purpose → 'mcp_invoke'
- *        action  → '<method>:<toolName>' (or just '<method>')
+ * Action precedence (unchanged from v2.4.14):
+ *   - header → body `_meta` → body `arguments` → bare tool name / method.
  *
- * The header tier is the adapter's job (it has `req.headers` access);
- * this function takes the resolved `headerPurpose` / `headerAction`
- * inputs and combines them with the body extraction already done in
- * `parseMcpJsonRpc`. The discriminator is reported on `purposeSource` /
- * `actionSource` for debug logging.
+ * @param requestPath  The HTTP request path (e.g. '/mcp'). Required.
+ * @param toolGate     Resolved per-tool config from `toolGates`, if present.
  */
-declare function mcpToPdlss(parsed: ParsedMcpRequest, headerPurpose?: string, headerAction?: string): McpPdlssMapping;
+declare function mcpToPdlss(parsed: ParsedMcpRequest, requestPath: string, headerPurpose?: string, headerAction?: string, toolGate?: {
+    purpose?: string;
+    resource?: string;
+}): McpPdlssMapping;
 /**
  * Recommended minimum access level per method type. The MCP middleware uses
  * this to split low-risk handshake / introspection traffic from high-risk
@@ -200,10 +185,9 @@ declare function mcpRiskTier(parsed: ParsedMcpRequest): AccessLevel;
  *       from `tools/call start_checkout` (high risk). This middleware peels
  *       the JSON-RPC body and applies a per-method risk tier.
  *
- *   (b) **PDLSS mapping**.  Forwards `purpose=mcp_invoke`,
- *       `action=method[:tool]`, `resource=mcp:tool/<name>` so audit traces
- *       are stable across cohort-3 partners. See `transport/mcp-server.ts`
- *       for the exact mapping.
+ *   (b) **PDLSS mapping**.  Derives purpose, action, and resource from
+ *       `toolGates` config and request context. See `transport/mcp-server.ts`
+ *       `mcpToPdlss()` for the exact mapping.
  *
  *   (c) **Inner-hop dedupe**.  Outbound responses set
  *       `X-Astra-Verified-Hop` so a downstream REST endpoint that the tool
@@ -249,13 +233,51 @@ declare global {
         }
     }
 }
+/**
+ * Extended per-tool gate with optional PDLSS purpose + resource overrides.
+ *
+ * When `purpose` is set, it is authoritative for that tool — the agent's
+ * `X-Astra-Purpose` header is ignored. This lets the merchant declare what
+ * semantic purpose each tool fulfils rather than trusting agent self-declaration.
+ *
+ * When `resource` is set, it overrides the default (`req.path`) for that
+ * tool's verify-access call — e.g. mapping `list_products` to `/api/catalog`.
+ */
+interface ToolGateConfig {
+    minAccessLevel: AccessLevel;
+    purpose?: string;
+    resource?: string;
+}
 interface McpMiddlewareOptions extends GatewayConfig {
     /**
-     * Per-tool override for the minimum access level. Tools not listed inherit
-     * the default tier from `mcpRiskTier` (`tools/call` → `'standard'`). Use
-     * for high-risk tools that demand `'full'` or low-risk read-only tools.
+     * Per-tool gating for `tools/call` invocations. Tools not listed inherit
+     * the default tier from `mcpRiskTier` (`tools/call` → `'standard'`).
+     *
+     * Accepts both the shorthand access-level string and the full object shape:
+     * ```typescript
+     * toolGates: {
+     *   browse_catalog: 'read-only',                // shorthand
+     *   list_products:  { minAccessLevel: 'none',    // full shape
+     *                     purpose: 'shopping.search',
+     *                     resource: '/api/catalog' },
+     *   start_checkout: { minAccessLevel: 'standard',
+     *                     purpose: 'shopping.purchase',
+     *                     resource: '/api/checkout/*' },
+     * }
+     * ```
+     *
+     * When `tools/call` arrives for a tool not declared in `toolGates`, the SDK
+     * falls back to a risk-tier default based on the method classification
+     * (`mcpRiskTier`). For `tools/call` the fallback is `'standard'`. Best
+     * practice: declare every tool you expose explicitly.
+     *
+     * The action axis for non-tools/call MCP methods (`tools/list`,
+     * `resources/list`, `prompts/list`, etc.) is the literal JSON-RPC method
+     * name (e.g. `'tools/list'`). Merchants gating MCP traffic by action should
+     * declare per-tool gates in `toolGates`, not endpoint-level `allowedActions`
+     * — the latter applies to REST-style action values, not MCP method strings.
      */
-    toolGates?: Record<string, AccessLevel>;
+    toolGates?: Record<string, AccessLevel | ToolGateConfig>;
     /**
      * Per-method override (e.g. tighten `tools/list` to `'read-only'` if you
      * don't want unregistered probes seeing your tool catalogue). Matches by
@@ -280,9 +302,22 @@ interface McpMiddlewareOptions extends GatewayConfig {
     /** Custom denied handler. Defaults to a structured JSON-RPC error response. */
     onDenied?: (result: VerificationResult, req: Request, res: Response) => void;
     /**
-     * If `false`, don't trust an inbound `X-Astra-Verified-Hop` header (always
-     * call verify-access). Default `true` — recommended for inner-hop endpoints
-     * called by your own MCP tools.
+     * If `true`, trust an inbound `X-Astra-Verified-Hop` header to skip
+     * verify-access when it carries a recent marker for the resolved agent.
+     *
+     * **DEFAULT FLIPPED TO `false` in SDK 2.4.13** (audit F-A1-01). The marker
+     * is plaintext semicolon-delimited with no HMAC, so any client that sets
+     * the header (with the right format + fresh timestamp + matching ASTRA-id)
+     * skipped verify-access entirely. The per-process verify-access result
+     * cache already dedupes legitimate repeat calls — this optimization
+     * provided no additional savings, only a bypass surface.
+     *
+     * Set this to `true` ONLY if you control every upstream MCP hop that sets
+     * the header AND you trust the network path between hops (mTLS, internal
+     * VPC, etc.). For most installs, leave at the safe default.
+     *
+     * Future SDK release will either remove this option entirely OR add HMAC
+     * signing to the marker. Tracked as round-19+ work.
      */
     trustVerifiedHop?: boolean;
     /** Window for accepting an upstream verified-hop marker. Default 60_000ms. */
@@ -294,6 +329,15 @@ interface McpMiddlewareOptions extends GatewayConfig {
     recordDecisions?: boolean;
     /** Forward runtime challenge (default `true`). */
     enableRuntimeChallenge?: boolean;
+    /**
+     * Posture when the MCP middleware itself throws an internal error.
+     * Default `'open'` for backward compatibility in SDK 2.4.13. Shadow logs
+     * record what WOULD be denied with `failOnError: 'closed'` so merchants
+     * can grep correlationId for impact analysis during the 1-week
+     * observation window. Default flips to `'closed'` in a follow-up release.
+     * Audit F-A1-06.
+     */
+    failOnError?: 'open' | 'closed';
 }
 /**
  * Create the MCP middleware. Attach AFTER `express.json()` — the body must
@@ -301,4 +345,4 @@ interface McpMiddlewareOptions extends GatewayConfig {
  */
 declare function createMcpMiddleware(options: McpMiddlewareOptions): RequestHandler;
 
-export { MCP_VERIFIED_HOP_HEADER, type McpMiddlewareOptions, type ParsedMcpRequest, createMcpMiddleware, isVerifiedHopValidFor, mcpRiskTier, mcpToPdlss, parseMcpJsonRpc, parseVerifiedHop, serializeVerifiedHop };
+export { MCP_VERIFIED_HOP_HEADER, type McpMiddlewareOptions, type ParsedMcpRequest, type ToolGateConfig, createMcpMiddleware, isVerifiedHopValidFor, mcpRiskTier, mcpToPdlss, parseMcpJsonRpc, parseVerifiedHop, serializeVerifiedHop };

package/dist/adapters/mcp.d.ts

@@ -1,5 +1,5 @@
 import { Request, Response, RequestHandler } from 'express';
-import { A as AccessLevel, G as GatewayConfig, i as VerificationResult } from '../types-L15pYd2c.js';
+import { A as AccessLevel, G as GatewayConfig, i as VerificationResult } from '../types-B3USs-Kx.js';
 
 /**
  * MCP server-side helpers — companion to `transport/mcp.ts` (which handles the
@@ -85,7 +85,7 @@ interface ParsedMcpRequest {
      * (canonical SDK location) OR `params.arguments.purpose` (legacy /
      * conventional callers). The discriminator is on `purposeSourceFromBody`.
      * Adapter combines this with the `X-Astra-Purpose` header (header wins)
-     * before mapping; final fallback at `mcpToPdlss` is `'mcp_invoke'`.
+     * before mapping; final fallback at `mcpToPdlss` is `undefined`.
      */
     purposeFromBody?: string;
     /** Which body location resolved `purposeFromBody`. */
@@ -120,60 +120,45 @@ declare function parseMcpJsonRpc(body: unknown): ParsedMcpRequest | null;
 /**
  * PDLSS mapping for an MCP request. The platform's PDLSS taxonomy is
  * `purpose / action / resource`; for MCP traffic the audit-useful dimensions
- * are the JSON-RPC method and (for `tools/call`) the tool name. Doc-stable so
- * dashboards and audits can correlate consistently across cohort-3 partners.
+ * are the JSON-RPC method and (for `tools/call`) the tool name.
  *
- * Rules:
- *   - `purpose` is always `mcp_invoke` for MCP traffic — sets the high-level
- *     PDLSS bucket.
- *   - `action` is the JSON-RPC method, optionally `:tool_name` suffixed for
- *     `tools/call`. Lets PDLSS allowlist specific tools.
- *   - `resource` is `mcp:tool/<name>` for `tools/call`, `mcp:method/<method>`
- *     otherwise. Lets PDLSS scope on tool identity.
+ * v2.5.0 rules:
+ *   - `resource` defaults to the HTTP request path (e.g. `/mcp`). Per-tool
+ *     overrides via `toolGates` config let merchants map tools to specific
+ *     backend resources (e.g. `/api/catalog`).
+ *   - `purpose` defaults to `undefined` (backend evaluator applies
+ *     skip-when-undefined). Per-tool overrides via `toolGates` config let
+ *     merchants declare the semantic purpose each tool fulfils.
+ *   - `action` is the bare tool name for `tools/call`, the JSON-RPC method
+ *     otherwise. Header/body overrides available.
  */
 interface McpPdlssMapping {
-    purpose: string;
+    purpose: string | undefined;
     action: string;
     resource: string;
-    /**
-     * Round-13 (R13-1 / R13-2): the resolution channel for purpose and
-     * action — disjoint enums sharing the same structure per
-     * `feedback_symmetric_fallbacks_for_symmetric_concepts.md`. Adapters
-     * log both at debug level so partners can confirm header / body
-     * pass-through, support can triage tickets, and we can watch the
-     * `default_*` / `transport_layer` decay over time as integrations
-     * mature.
-     *
-     * Round-12 (F19) used a narrower `purposeSource: 'header' |
-     * 'tool_argument' | 'default_mcp_invoke'` — round-13 widens to also
-     * carry the `_meta` source distinct from `tool_argument`, so the round-13
-     * R13-1 fallback (which now reads both `_meta.astrasync.purpose` AND
-     * `params.arguments.purpose`) can report WHICH body location resolved.
-     */
-    purposeSource: 'header' | 'meta' | 'tool_argument' | 'default_mcp_invoke';
+    purposeSource: 'header' | 'meta' | 'tool_argument' | 'tool_gate' | undefined;
     actionSource: 'header' | 'meta' | 'tool_argument' | 'transport_layer';
 }
 /**
- * Round-13 (R13-1 + R13-2) — canonical precedence chain documented ONCE,
- * applied identically to both purpose and action. Per
- * `feedback_symmetric_fallbacks_for_symmetric_concepts.md` — drift
- * between two paired concepts generates the same support-ticket class
- * repeatedly, so the resolution order is:
+ * v2.5.0 — PDLSS field derivation for MCP requests.
+ *
+ * Purpose precedence:
+ *   - If `toolGate.purpose` is provided, it is authoritative (header/body ignored).
+ *   - Otherwise: header → body `_meta` → body `arguments` → `undefined`.
+ *
+ * Resource precedence:
+ *   - `toolGate.resource` if provided, else `requestPath`.
  *
- *   1. `X-Astra-<concept>` HTTP header (caller's explicit override)
- *   2. `params._meta.astrasync.<concept>` body field (canonical SDK location)
- *   3. `params.arguments.<concept>` body field (legacy / conventional)
- *   4. Transport-layer default:
- *        purpose → 'mcp_invoke'
- *        action  → '<method>:<toolName>' (or just '<method>')
+ * Action precedence (unchanged from v2.4.14):
+ *   - header → body `_meta` → body `arguments` → bare tool name / method.
  *
- * The header tier is the adapter's job (it has `req.headers` access);
- * this function takes the resolved `headerPurpose` / `headerAction`
- * inputs and combines them with the body extraction already done in
- * `parseMcpJsonRpc`. The discriminator is reported on `purposeSource` /
- * `actionSource` for debug logging.
+ * @param requestPath  The HTTP request path (e.g. '/mcp'). Required.
+ * @param toolGate     Resolved per-tool config from `toolGates`, if present.
  */
-declare function mcpToPdlss(parsed: ParsedMcpRequest, headerPurpose?: string, headerAction?: string): McpPdlssMapping;
+declare function mcpToPdlss(parsed: ParsedMcpRequest, requestPath: string, headerPurpose?: string, headerAction?: string, toolGate?: {
+    purpose?: string;
+    resource?: string;
+}): McpPdlssMapping;
 /**
  * Recommended minimum access level per method type. The MCP middleware uses
  * this to split low-risk handshake / introspection traffic from high-risk
@@ -200,10 +185,9 @@ declare function mcpRiskTier(parsed: ParsedMcpRequest): AccessLevel;
  *       from `tools/call start_checkout` (high risk). This middleware peels
  *       the JSON-RPC body and applies a per-method risk tier.
  *
- *   (b) **PDLSS mapping**.  Forwards `purpose=mcp_invoke`,
- *       `action=method[:tool]`, `resource=mcp:tool/<name>` so audit traces
- *       are stable across cohort-3 partners. See `transport/mcp-server.ts`
- *       for the exact mapping.
+ *   (b) **PDLSS mapping**.  Derives purpose, action, and resource from
+ *       `toolGates` config and request context. See `transport/mcp-server.ts`
+ *       `mcpToPdlss()` for the exact mapping.
  *
  *   (c) **Inner-hop dedupe**.  Outbound responses set
  *       `X-Astra-Verified-Hop` so a downstream REST endpoint that the tool
@@ -249,13 +233,51 @@ declare global {
         }
     }
 }
+/**
+ * Extended per-tool gate with optional PDLSS purpose + resource overrides.
+ *
+ * When `purpose` is set, it is authoritative for that tool — the agent's
+ * `X-Astra-Purpose` header is ignored. This lets the merchant declare what
+ * semantic purpose each tool fulfils rather than trusting agent self-declaration.
+ *
+ * When `resource` is set, it overrides the default (`req.path`) for that
+ * tool's verify-access call — e.g. mapping `list_products` to `/api/catalog`.
+ */
+interface ToolGateConfig {
+    minAccessLevel: AccessLevel;
+    purpose?: string;
+    resource?: string;
+}
 interface McpMiddlewareOptions extends GatewayConfig {
     /**
-     * Per-tool override for the minimum access level. Tools not listed inherit
-     * the default tier from `mcpRiskTier` (`tools/call` → `'standard'`). Use
-     * for high-risk tools that demand `'full'` or low-risk read-only tools.
+     * Per-tool gating for `tools/call` invocations. Tools not listed inherit
+     * the default tier from `mcpRiskTier` (`tools/call` → `'standard'`).
+     *
+     * Accepts both the shorthand access-level string and the full object shape:
+     * ```typescript
+     * toolGates: {
+     *   browse_catalog: 'read-only',                // shorthand
+     *   list_products:  { minAccessLevel: 'none',    // full shape
+     *                     purpose: 'shopping.search',
+     *                     resource: '/api/catalog' },
+     *   start_checkout: { minAccessLevel: 'standard',
+     *                     purpose: 'shopping.purchase',
+     *                     resource: '/api/checkout/*' },
+     * }
+     * ```
+     *
+     * When `tools/call` arrives for a tool not declared in `toolGates`, the SDK
+     * falls back to a risk-tier default based on the method classification
+     * (`mcpRiskTier`). For `tools/call` the fallback is `'standard'`. Best
+     * practice: declare every tool you expose explicitly.
+     *
+     * The action axis for non-tools/call MCP methods (`tools/list`,
+     * `resources/list`, `prompts/list`, etc.) is the literal JSON-RPC method
+     * name (e.g. `'tools/list'`). Merchants gating MCP traffic by action should
+     * declare per-tool gates in `toolGates`, not endpoint-level `allowedActions`
+     * — the latter applies to REST-style action values, not MCP method strings.
      */
-    toolGates?: Record<string, AccessLevel>;
+    toolGates?: Record<string, AccessLevel | ToolGateConfig>;
     /**
      * Per-method override (e.g. tighten `tools/list` to `'read-only'` if you
      * don't want unregistered probes seeing your tool catalogue). Matches by
@@ -280,9 +302,22 @@ interface McpMiddlewareOptions extends GatewayConfig {
     /** Custom denied handler. Defaults to a structured JSON-RPC error response. */
     onDenied?: (result: VerificationResult, req: Request, res: Response) => void;
     /**
-     * If `false`, don't trust an inbound `X-Astra-Verified-Hop` header (always
-     * call verify-access). Default `true` — recommended for inner-hop endpoints
-     * called by your own MCP tools.
+     * If `true`, trust an inbound `X-Astra-Verified-Hop` header to skip
+     * verify-access when it carries a recent marker for the resolved agent.
+     *
+     * **DEFAULT FLIPPED TO `false` in SDK 2.4.13** (audit F-A1-01). The marker
+     * is plaintext semicolon-delimited with no HMAC, so any client that sets
+     * the header (with the right format + fresh timestamp + matching ASTRA-id)
+     * skipped verify-access entirely. The per-process verify-access result
+     * cache already dedupes legitimate repeat calls — this optimization
+     * provided no additional savings, only a bypass surface.
+     *
+     * Set this to `true` ONLY if you control every upstream MCP hop that sets
+     * the header AND you trust the network path between hops (mTLS, internal
+     * VPC, etc.). For most installs, leave at the safe default.
+     *
+     * Future SDK release will either remove this option entirely OR add HMAC
+     * signing to the marker. Tracked as round-19+ work.
      */
     trustVerifiedHop?: boolean;
     /** Window for accepting an upstream verified-hop marker. Default 60_000ms. */
@@ -294,6 +329,15 @@ interface McpMiddlewareOptions extends GatewayConfig {
     recordDecisions?: boolean;
     /** Forward runtime challenge (default `true`). */
     enableRuntimeChallenge?: boolean;
+    /**
+     * Posture when the MCP middleware itself throws an internal error.
+     * Default `'open'` for backward compatibility in SDK 2.4.13. Shadow logs
+     * record what WOULD be denied with `failOnError: 'closed'` so merchants
+     * can grep correlationId for impact analysis during the 1-week
+     * observation window. Default flips to `'closed'` in a follow-up release.
+     * Audit F-A1-06.
+     */
+    failOnError?: 'open' | 'closed';
 }
 /**
  * Create the MCP middleware. Attach AFTER `express.json()` — the body must
@@ -301,4 +345,4 @@ interface McpMiddlewareOptions extends GatewayConfig {
  */
 declare function createMcpMiddleware(options: McpMiddlewareOptions): RequestHandler;
 
-export { MCP_VERIFIED_HOP_HEADER, type McpMiddlewareOptions, type ParsedMcpRequest, createMcpMiddleware, isVerifiedHopValidFor, mcpRiskTier, mcpToPdlss, parseMcpJsonRpc, parseVerifiedHop, serializeVerifiedHop };
+export { MCP_VERIFIED_HOP_HEADER, type McpMiddlewareOptions, type ParsedMcpRequest, type ToolGateConfig, createMcpMiddleware, isVerifiedHopValidFor, mcpRiskTier, mcpToPdlss, parseMcpJsonRpc, parseVerifiedHop, serializeVerifiedHop };