fix(server): handleExecute preserves caller requestContext.headers + explorer honors per-tool rules

[encodedz]

Summary

Two isolated server-side fixes to ATP's handler surface. Both are bug fixes; neither introduces a new API or changes existing contracts for callers that were working.

1. handleExecute merges caller-supplied requestContext.headers

packages/server/src/handlers/execute.handler.ts

When a caller passes config.requestContext.headers through client.execute(code, config) (already a typed entry point via Record<string, unknown>), the in-process handler silently dropped them. Root cause: the executionConfig builder did:

requestContext: {
  ...requestConfig.requestContext,  // .headers present if caller set it
  headers: ctx.headers,             // overwrites — caller headers lost
  ...
}

Fix: merge the two header bags. Caller-supplied headers first, then ctx.headers takes precedence on overlapping keys. Non-conflicting caller entries survive; for conflicts, transport-layer session auth still wins so callers cannot spoof session headers.

 requestContext: {
   ...requestConfig.requestContext,
-  headers: ctx.headers,
+  headers: {
+    ...(requestConfig.requestContext as { headers?: Record<string, string> } | undefined)?.headers,
+    ...ctx.headers,
+  },
   path: ctx.path,
   method: ctx.method,
 },

Impact: purely additive. No caller that relied on the old behavior (silently dropped headers) can observe a regression, because silently-dropped data has no observable consequence. Callers that DID supply requestContext.headers and expected them to survive now get what they expected.

2. ExplorerService.getFilterContext iterates allowedGroups, not raw apiGroups

packages/server/src/explorer/index.ts

filterApiGroups(this.apiGroups) already returns per-tool-filtered groups — isToolAllowed correctly drops functions whose names are in blockTools / not in allowOnlyTools / carry a blocked operationType / blocked sensitivityLevel. The subsequent loop in getFilterContext then re-iterated the unfiltered this.apiGroups and re-added every function in any allowed group:

for (const group of this.apiGroups) {
  if (!context.allowedGroups.has(group.name)) continue;
  if (group.functions) {
    for (const func of group.functions) {
      context.allowedTools.add(`${group.name}:${func.name}`);  // unfiltered!
    }
  }
}

Net symptom: per-tool rules (allowOnlyTools, blockTools, blockOperationTypes, blockSensitivityLevels) worked correctly for the sandbox's api.* namespace AND for SearchEngine.search (which already iterates allowedGroups — the correct pattern). But explore_api returned every operation regardless. For downstream governance layers that rely on explore_api to serve a grant-filtered discovery surface, this was a silent no-op.

Fix: iterate the already-filtered allowedGroups. Mirrors the existing pattern in SearchEngine.search.

-for (const group of this.apiGroups) {
-  if (!context.allowedGroups.has(group.name)) continue;
+for (const group of allowedGroups) {
   if (group.functions) {
     for (const func of group.functions) {
       context.allowedTools.add(`${group.name}:${func.name}`);
     }
   }
 }

Live verification

Both fixes exercised via an end-to-end smoke in DaPulse/mcp-tools (ATP POC branch feat/odedgo/ocana-poc-mcp-gateway). With both applied, atp.explore_api correctly filters by per-tool grant rules, and atp.execute_code correctly forwards per-provider auth tokens from the caller through to the sandbox's outbound HTTPS calls.

Test plan

• Unit test: calling handleExecute with config.requestContext.headers = { 'x-custom': 'abc' } results in an executionConfig.requestContext.headers containing 'x-custom': 'abc' (plus whatever was in ctx.headers).
• Unit test: handleExecute with overlapping keys — config.requestContext.headers = { 'authorization': 'caller' } and ctx.headers = { 'authorization': 'session' } — final value is 'session' (ctx wins on conflict).
• Unit test: ExplorerService.explore('/openapi/calendar/events') with runInRequestScope({ toolRules: { allowOnlyTools: ['calendar.events_list'] } }) → items contains exactly ['events_list'], not the full events resource list.
• Regression check: existing SearchEngine.search per-tool filtering tests continue to pass (pattern borrowed from there).

🤖 Generated with Claude Code

[maslo55555]

I guess you forgot to add an assertion that all tools exist