mirror of
https://github.com/lukaszraczylo/traefik-llmgateway.git
synced 2026-10-20 05:56:56 +00:00
fix(mcp): stop weighting tools/list budget, widen fan-out, split caps
Addresses critical finding 3 and important findings 3-4 from security review round 2, 2026-08-22. Critical finding 3 — the tools/list-per-backend weight charged against the caller's own requests-per-minute/day budget (security audit finding 1b) was not default-preserving: both live groups have an empty MCP allow-list (all 11 servers), so it silently cut every configured requests-per-minute budget by ~11x with no config change, and examples/kubernetes.yaml's shipped requests-per-minute: 10 would 429 the very first tools/list call ever made. Reverted: checkAndCountWeighted removed from limits.go, handleMCPFederated back to a plain checkAndCount. The real amplification stays fully visible to an operator via countTargetRequests' existing per-server 'mcp' target-scope counters — a separate scope from the user/group budget — rather than silently consuming tenant quota. The fan-out semaphore (below) is the actual protection against the amplification finding 1 described. Important finding 3 — the fan-out semaphore (4 concurrent backends) tripled worst-case latency (907ms measured at 300ms/server, was ~300ms) and pushed the hung-backend worst case to ceil(11/4)x20s=60s, past the ~30s timeout many MCP clients use. Raised to 8, and every backend in one tools/list call now shares ONE overall toolsListBackendTimeout deadline (fanoutCtx) instead of each getting a fresh one from its own staggered start — restoring this function's original 'bounds the whole call regardless of server count' invariant even with bounded concurrency. Important finding 4 — the 4MiB response cap (sized for the tools/list fan-out's memory-amplification risk) silently applied to tools/call too, where exactly one backend is ever contacted and a legitimate result (an image, an extracted document) can be much larger. tools/call now uses mcpBackendCallResponseMaxBytes (10MiB, the pre-finding-1c budget); tools/list keeps the 4MiB cap. A response that hits either cap is detected via a cap+1 read (never silently truncated into a confusing parse failure) and reported to the client as 'response too large'.
This commit is contained in:
+152
-68
@@ -67,20 +67,51 @@ const (
|
||||
)
|
||||
|
||||
// mcpBackendResponseMaxBytes caps a single backend MCP server's HTTP
|
||||
// response body doBackendJSONRPC will read into memory — previously
|
||||
// maxRequestBytes (10MiB, routes_unified.go), a budget sized for a
|
||||
// CLIENT's own chat/embeddings request body, not a backend's JSON-RPC
|
||||
// reply (security audit finding 1c, 2026-08-22). 4MiB matches this
|
||||
// codebase's other "generous but bounded" read caps for a non-primary-
|
||||
// request-body read (cache.go's maxAccountingTeeBytes is also 4MiB) —
|
||||
// comfortably above any tools/list schema listing or tools/call result
|
||||
// this gateway has actually seen live (typically low KB), while bounding
|
||||
// mcpFederatedFanoutConcurrency backends' worst-case concurrent memory to
|
||||
// 4 × 4MiB = 16MiB, against the unbounded ~110MiB (11 production servers
|
||||
// × up to 10MiB each, all fired at once) the security audit measured
|
||||
// before this fix.
|
||||
// response body for the tools/list FAN-OUT path only (mcpFederatedToolsList)
|
||||
// — previously maxRequestBytes (10MiB, routes_unified.go), a budget sized
|
||||
// for a CLIENT's own chat/embeddings request body, not a backend's
|
||||
// JSON-RPC reply (security audit finding 1c, 2026-08-22). 4MiB matches
|
||||
// this codebase's other "generous but bounded" read caps for a non-
|
||||
// primary-request-body read (cache.go's maxAccountingTeeBytes is also
|
||||
// 4MiB) — measured at 547KiB for a real tools/list response describing
|
||||
// 20 fat tools (security review round 2, 2026-08-22), comfortably below
|
||||
// this cap — while bounding mcpFederatedFanoutConcurrency backends'
|
||||
// worst-case concurrent memory to a small multiple of 4MiB, against the
|
||||
// unbounded ~110MiB (11 production servers × up to 10MiB each, all fired
|
||||
// at once) the security audit measured before this fix. This cap is
|
||||
// deliberately NOT used for tools/call — see mcpBackendCallResponseMaxBytes,
|
||||
// whose own doc comment covers why the fan-out memory argument does not
|
||||
// apply there.
|
||||
const mcpBackendResponseMaxBytes = 4 << 20
|
||||
|
||||
// mcpBackendCallResponseMaxBytes caps a single backend's response for the
|
||||
// tools/call path (mcpFederatedToolsCall) — kept at maxRequestBytes
|
||||
// (10MiB), the SAME budget this file used everywhere before finding 1c,
|
||||
// deliberately NOT shrunk to mcpBackendResponseMaxBytes (security review
|
||||
// round 2, 2026-08-22, important finding 4): tools/call always resolves
|
||||
// to exactly ONE backend (resolveFederatedTool), so the fan-out memory-
|
||||
// amplification argument that justifies the fan-out path's smaller cap
|
||||
// does not hold here at all — a single tool result can legitimately be
|
||||
// much larger than a tools/list schema listing (an extracted document, an
|
||||
// image or other blob a tool returns), and silently truncating one into
|
||||
// a generic parse failure would be a real, avoidable regression for any
|
||||
// tool whose legitimate results sit between 4MiB and 10MiB.
|
||||
const mcpBackendCallResponseMaxBytes = maxRequestBytes
|
||||
|
||||
// mcpResponseTooLargeMarker is a fixed, unique substring doBackendJSONRPC
|
||||
// embeds in its own error message when a backend response hits its
|
||||
// call's maxBytes cap (security review round 2, 2026-08-22, important
|
||||
// finding 4) — detected via strings.Contains, deliberately NOT an
|
||||
// errors.Is-checked sentinel. matchesSentinel's own doc comment
|
||||
// (limits.go) proves errors.Is safe under Yaegi only for chains reaching
|
||||
// a call site this package's own yaegi-check harness actually exercises
|
||||
// at runtime under the real interpreter — federation's tools/call path
|
||||
// is not one of those exercised paths today, so a plain string check
|
||||
// trades a little idiom for zero interpreter risk here, rather than
|
||||
// relying on reasoning about compiled-vs-interpreted-origin values that
|
||||
// nothing in the gate actually verifies for this specific path.
|
||||
const mcpResponseTooLargeMarker = "mcp backend response too large"
|
||||
|
||||
// jsonrpcRequest is one JSON-RPC 2.0 request/notification, decoded from
|
||||
// the client's POST body and re-encoded (with a synthetic id) for this
|
||||
// gateway's own outbound calls to a backend MCP server (mcpBackendCall).
|
||||
@@ -249,27 +280,32 @@ func allowedMCPServerNames(cfg *Config, grp *group) []string {
|
||||
//
|
||||
// checkAndCount runs once per incoming request, before method dispatch —
|
||||
// covering the caller's own user/group/total scopes exactly like every
|
||||
// other metered route — with per-target attribution added separately
|
||||
// other metered route, charging the plain weight of one request
|
||||
// regardless of method — with per-target attribution added separately
|
||||
// inside mcpFederatedToolsList/mcpFederatedToolsCall (their own doc
|
||||
// comments cover exactly what "attributed" means for each).
|
||||
//
|
||||
// The weight charged to checkAndCount is 1 for every method EXCEPT
|
||||
// tools/list (security audit finding 1b, 2026-08-22): a tools/list call
|
||||
// fans out to every server allowedMCPServerNames(grp) returns — up to the
|
||||
// whole MCP catalog, concurrently (mcpFederatedToolsList's own doc
|
||||
// comment) — so one incoming client request can cost this gateway many
|
||||
// real outbound backend calls. Charging it as a single request against
|
||||
// the caller's requests-per-minute/requests-per-day budget undercounts
|
||||
// that real cost; weighting it by len(names) instead makes the budget
|
||||
// reflect what the request actually does. This is computed and charged
|
||||
// exactly once, right here, before dispatch — never doubled by anything
|
||||
// mcpFederatedToolsList itself does (its own countTargetRequests call is a
|
||||
// SEPARATE scope kind, "mcp"/target-id, entirely disjoint from the
|
||||
// user/group/total scopes checkAndCountWeighted evaluates here; see
|
||||
// countTargetRequests' own doc comment, limits.go). tools/call, by
|
||||
// contrast, always resolves to exactly ONE backend (resolveFederatedTool),
|
||||
// so it keeps the plain weight of 1 — checkAndCountWeighted(scopes, 1) is
|
||||
// byte-for-byte checkAndCount's own existing behavior.
|
||||
// tools/list's fan-out is deliberately NOT charged against the caller's
|
||||
// own requests-per-minute/requests-per-day budget (security review round
|
||||
// 2, 2026-08-22, critical finding 3 — reverting security audit finding
|
||||
// 1b's weighted-charge attempt): weighting checkAndCount by the number of
|
||||
// allowed MCP servers is not default-preserving — on this operator's own
|
||||
// live fleet, both configured groups have an empty MCP allow-list (every
|
||||
// server allowed), so EVERY tools/list call would have weighed 11,
|
||||
// silently turning a configured requests-per-minute: 60 into an effective
|
||||
// budget of 5 successful tools/list calls per minute, and
|
||||
// examples/kubernetes.yaml's shipped requests-per-minute: 10 would have
|
||||
// 429'd the very FIRST tools/list call ever made — with no config change
|
||||
// on the operator's part. The fan-out's real amplification is still
|
||||
// fully visible to an operator without silently consuming tenant quota:
|
||||
// mcpFederatedToolsList's own countTargetRequests call attributes one
|
||||
// request to EVERY server actually attempted, at the "mcp"/target-id
|
||||
// scope (limits.go) — a SEPARATE scope kind from the user/group/total
|
||||
// scopes checkAndCount evaluates here — so the dashboard's targets view
|
||||
// already shows the true per-server cost. The fan-out's outbound HTTP/
|
||||
// memory cost is bounded instead by mcpFederatedFanoutConcurrency's
|
||||
// semaphore (mcpFederatedToolsList's own doc comment), which is the
|
||||
// actual protection against the amplification finding 1 described.
|
||||
func (g *Gateway) handleMCPFederated(w http.ResponseWriter, r *http.Request, u *user, grp *group) {
|
||||
if r.Header.Get("Upgrade") != "" {
|
||||
writeOAIError(w, http.StatusNotImplemented, "invalid_request_error", "websocket/upgrade passthrough not supported")
|
||||
@@ -292,17 +328,7 @@ func (g *Gateway) handleMCPFederated(w http.ResponseWriter, r *http.Request, u *
|
||||
}
|
||||
|
||||
scopes := withTotalScope(buildLimitScopes(u, grp))
|
||||
|
||||
var toolsListNames []string
|
||||
weight := int64(1)
|
||||
if req.Method == "tools/list" {
|
||||
toolsListNames = allowedMCPServerNames(g.cfg, grp)
|
||||
if n := int64(len(toolsListNames)); n > weight {
|
||||
weight = n
|
||||
}
|
||||
}
|
||||
|
||||
if violation := g.limiter.checkAndCountWeighted(scopes, weight); violation != nil {
|
||||
if violation := g.limiter.checkAndCount(scopes); violation != nil {
|
||||
writeLimitViolation(w, violation)
|
||||
return
|
||||
}
|
||||
@@ -313,7 +339,7 @@ func (g *Gateway) handleMCPFederated(w http.ResponseWriter, r *http.Request, u *
|
||||
case req.Method == "ping":
|
||||
writeJSONRPCResult(w, req.ID, map[string]any{})
|
||||
case req.Method == "tools/list":
|
||||
g.mcpFederatedToolsList(w, r, req, toolsListNames)
|
||||
g.mcpFederatedToolsList(w, r, req, allowedMCPServerNames(g.cfg, grp))
|
||||
case req.Method == "tools/call":
|
||||
g.mcpFederatedToolsCall(w, r, req, grp)
|
||||
case strings.HasPrefix(req.Method, "notifications/"):
|
||||
@@ -413,8 +439,16 @@ type mcpToolsListResult struct {
|
||||
// doBackendJSONRPC issues one JSON-RPC 2.0 POST to targetURL — an MCP
|
||||
// server's own configured base URL, the same single endpoint
|
||||
// handleTargetProxy reverse-proxies every method to — carrying sessionID
|
||||
// as the Mcp-Session-Id request header when non-empty. It is the one place
|
||||
// that actually builds and sends an HTTP request for this file; every
|
||||
// as the Mcp-Session-Id request header when non-empty, and reading at
|
||||
// most maxBytes of the response body (mcpBackendResponseMaxBytes for the
|
||||
// tools/list fan-out, mcpBackendCallResponseMaxBytes for tools/call —
|
||||
// their own doc comments cover why the two differ; security review round
|
||||
// 2, 2026-08-22, important finding 4). A response body that hits maxBytes
|
||||
// is reported with mcpResponseTooLargeMarker in its message, not silently truncated into
|
||||
// whatever partial (and likely invalid) JSON happened to fit.
|
||||
//
|
||||
// It is the one place that actually builds and sends an HTTP request for
|
||||
// this file; every
|
||||
// other function in the handshake-fallback machinery (mcpBackendCall,
|
||||
// mcpBackendHandshake, mcpBackendCloseSession's own DELETE aside) goes
|
||||
// through this.
|
||||
@@ -439,7 +473,7 @@ type mcpToolsListResult struct {
|
||||
// that WAS valid JSON but not a real JSON-RPC response (see
|
||||
// parseBackendJSONRPC's own validity check) would have silently produced
|
||||
// an all-zero-fields response otherwise.
|
||||
func (g *Gateway) doBackendJSONRPC(ctx context.Context, targetURL, method string, params any, sessionID string) (resp *jsonrpcResponse, status int, respSessionID string, err error) {
|
||||
func (g *Gateway) doBackendJSONRPC(ctx context.Context, targetURL, method string, params any, sessionID string, maxBytes int64) (resp *jsonrpcResponse, status int, respSessionID string, err error) {
|
||||
paramsRaw, err := json.Marshal(params)
|
||||
if err != nil {
|
||||
return nil, 0, "", err
|
||||
@@ -476,10 +510,17 @@ func (g *Gateway) doBackendJSONRPC(ctx context.Context, targetURL, method string
|
||||
status = httpResp.StatusCode
|
||||
respSessionID = httpResp.Header.Get(mcpSessionHeader)
|
||||
|
||||
respBody, err := io.ReadAll(io.LimitReader(httpResp.Body, mcpBackendResponseMaxBytes))
|
||||
// Reads one byte past maxBytes so a response that hits the cap is
|
||||
// DETECTABLE (len(respBody) > maxBytes) rather than silently truncated
|
||||
// and handed to parseBackendJSONRPC to fail confusingly (security
|
||||
// review round 2, 2026-08-22, important finding 4).
|
||||
respBody, err := io.ReadAll(io.LimitReader(httpResp.Body, maxBytes+1))
|
||||
if err != nil {
|
||||
return nil, status, respSessionID, err
|
||||
}
|
||||
if int64(len(respBody)) > maxBytes {
|
||||
return nil, status, respSessionID, fmt.Errorf("%s: exceeds %d bytes", mcpResponseTooLargeMarker, maxBytes)
|
||||
}
|
||||
if status < 200 || status >= 300 {
|
||||
return nil, status, respSessionID, fmt.Errorf("upstream returned HTTP %d", status)
|
||||
}
|
||||
@@ -500,13 +541,13 @@ func (g *Gateway) doBackendJSONRPC(ctx context.Context, targetURL, method string
|
||||
// the initialize call itself failed outright (network error, non-2xx, a
|
||||
// JSON-RPC error response to initialize itself) — there is no retry of a
|
||||
// failed handshake.
|
||||
func (g *Gateway) mcpBackendHandshake(ctx context.Context, targetURL string) (sessionID string, err error) {
|
||||
func (g *Gateway) mcpBackendHandshake(ctx context.Context, targetURL string, maxBytes int64) (sessionID string, err error) {
|
||||
initParams := map[string]any{
|
||||
"protocolVersion": defaultMCPProtocolVersion,
|
||||
"capabilities": map[string]any{},
|
||||
"clientInfo": map[string]any{"name": "traefik-llmgateway", "version": pluginVersion},
|
||||
}
|
||||
resp, _, respSessionID, err := g.doBackendJSONRPC(ctx, targetURL, "initialize", initParams, "")
|
||||
resp, _, respSessionID, err := g.doBackendJSONRPC(ctx, targetURL, "initialize", initParams, "", maxBytes)
|
||||
if err != nil {
|
||||
return "", err
|
||||
}
|
||||
@@ -567,9 +608,14 @@ func (g *Gateway) mcpBackendCloseSession(ctx context.Context, targetURL, session
|
||||
// except the close itself — see mcpSessionCloseTimeout's own doc
|
||||
// comment); callers derive it from context.WithTimeout(r.Context(), ...)
|
||||
// with toolsListBackendTimeout or toolsCallBackendTimeout (MF1, review
|
||||
// round 2, 2026-08-21).
|
||||
func (g *Gateway) mcpBackendCall(ctx context.Context, targetURL, method string, params any) (*jsonrpcResponse, error) {
|
||||
resp, status, _, err := g.doBackendJSONRPC(ctx, targetURL, method, params, "")
|
||||
// round 2, 2026-08-21). maxBytes is doBackendJSONRPC's own response-size
|
||||
// cap, passed straight through to every doBackendJSONRPC call this
|
||||
// function makes (bare attempt, handshake, retry) — callers pass
|
||||
// mcpBackendResponseMaxBytes or mcpBackendCallResponseMaxBytes depending
|
||||
// on which path they are (security review round 2, 2026-08-22, important
|
||||
// finding 4).
|
||||
func (g *Gateway) mcpBackendCall(ctx context.Context, targetURL, method string, params any, maxBytes int64) (*jsonrpcResponse, error) {
|
||||
resp, status, _, err := g.doBackendJSONRPC(ctx, targetURL, method, params, "", maxBytes)
|
||||
if err == nil && resp.Error == nil {
|
||||
return resp, nil
|
||||
}
|
||||
@@ -579,7 +625,7 @@ func (g *Gateway) mcpBackendCall(ctx context.Context, targetURL, method string,
|
||||
return nil, err
|
||||
}
|
||||
|
||||
sessionID, initErr := g.mcpBackendHandshake(ctx, targetURL)
|
||||
sessionID, initErr := g.mcpBackendHandshake(ctx, targetURL, maxBytes)
|
||||
if initErr != nil {
|
||||
// The handshake itself failed: surface the bare attempt's own
|
||||
// outcome when it has one (a JSON-RPC error response is more
|
||||
@@ -600,7 +646,7 @@ func (g *Gateway) mcpBackendCall(ctx context.Context, targetURL, method string,
|
||||
}()
|
||||
}
|
||||
|
||||
retryResp, _, _, retryErr := g.doBackendJSONRPC(ctx, targetURL, method, params, sessionID)
|
||||
retryResp, _, _, retryErr := g.doBackendJSONRPC(ctx, targetURL, method, params, sessionID, maxBytes)
|
||||
if retryErr != nil {
|
||||
return nil, retryErr
|
||||
}
|
||||
@@ -685,19 +731,28 @@ func lastSSEDataLine(body []byte) []byte {
|
||||
// per allowed server with NO cap at all: with the 11 production servers,
|
||||
// one client call could hold up to 11 concurrent connections and up to
|
||||
// 11× mcpBackendResponseMaxBytes of backend response bodies in memory at
|
||||
// once, entirely outside this gateway's own admission control. 4 keeps
|
||||
// every server eventually contacted — a goroutine blocks on the
|
||||
// semaphore, it is never dropped or skipped — while capping the worst
|
||||
// case to 4 concurrent backends' cost, not the whole catalog's.
|
||||
const mcpFederatedFanoutConcurrency = 4
|
||||
// once, entirely outside this gateway's own admission control. Every
|
||||
// server is eventually contacted regardless of this bound — a goroutine
|
||||
// blocks on the semaphore, it is never dropped or skipped. 8 (raised from
|
||||
// an initial 4, security review round 2, 2026-08-22, important finding
|
||||
// 3): 4 measurably tripled worst-case wall-clock latency for an
|
||||
// unrestricted group against all 11 servers (907ms measured at 300ms/
|
||||
// server, versus ~300ms pre-bound) and, against hung backends, pushed the
|
||||
// worst case to ceil(11/4)×toolsListBackendTimeout = 60s — well past the
|
||||
// ~30s timeout many real MCP clients use, holding the ServeHTTP goroutine
|
||||
// the whole time. 8 nearly halves both: ceil(11/8)=2 batches. The fanoutCtx
|
||||
// deadline below (not this constant alone) is what actually re-bounds the
|
||||
// worst case back down near toolsListBackendTimeout regardless of
|
||||
// concurrency or backend count — see its own doc comment.
|
||||
const mcpFederatedFanoutConcurrency = 8
|
||||
|
||||
// mcpFederatedToolsList implements the federated "tools/list": it fans
|
||||
// out one mcpBackendCall per server in names (handleMCPFederated's own
|
||||
// allowedMCPServerNames(grp) call, made once there so the SAME set that
|
||||
// was weighed into checkAndCountWeighted is the set actually contacted),
|
||||
// at most mcpFederatedFanoutConcurrency at a time — each under its own
|
||||
// toolsListBackendTimeout budget (context.WithTimeout off r.Context(),
|
||||
// MF1) — then merges every reachable server's own tools into one result,
|
||||
// allowedMCPServerNames(grp) call, made once there so the exact set
|
||||
// contacted is always the one the client actually asked to reach), at
|
||||
// most mcpFederatedFanoutConcurrency at a time — every backend sharing
|
||||
// ONE overall toolsListBackendTimeout deadline (fanoutCtx, below) — then
|
||||
// merges every reachable server's own tools into one result,
|
||||
// each tool's name prefixed "<serverName>_<toolName>", the exact
|
||||
// underscore-separator convention the old agentgateway this plugin
|
||||
// replaces used, and the one pugbot's mcpclient and agentkit have already
|
||||
@@ -725,6 +780,24 @@ func (g *Gateway) mcpFederatedToolsList(w http.ResponseWriter, r *http.Request,
|
||||
merged = make([]mcpTool, 0, len(names))
|
||||
failed []string
|
||||
)
|
||||
// fanoutCtx bounds the WHOLE fan-out to toolsListBackendTimeout from
|
||||
// when THIS call started — not each individual backend's own start
|
||||
// (security review round 2, 2026-08-22, important finding 3). With
|
||||
// mcpFederatedFanoutConcurrency backends running at once, a later
|
||||
// batch's goroutines only begin once an earlier one's semaphore slot
|
||||
// frees; giving each one its own FRESH toolsListBackendTimeout budget
|
||||
// (this function's pre-bound design, and its own initial post-
|
||||
// semaphore revision) let total wall-clock grow with
|
||||
// ceil(len(names)/mcpFederatedFanoutConcurrency) batches. Every
|
||||
// backend below shares this ONE already-ticking context instead —
|
||||
// context.WithTimeout always resolves to the earlier of a parent's
|
||||
// existing deadline and its own duration (proven by
|
||||
// TestHandleMCPFederated_ToolsList_SlowBackend_BoundedByRequestContext),
|
||||
// so deriving fanoutCtx from r.Context() here preserves that same
|
||||
// property for the request's own deadline, on top of this one.
|
||||
fanoutCtx, fanoutCancel := context.WithTimeout(r.Context(), toolsListBackendTimeout)
|
||||
defer fanoutCancel()
|
||||
|
||||
sem := make(chan struct{}, mcpFederatedFanoutConcurrency)
|
||||
for _, name := range names {
|
||||
wg.Add(1)
|
||||
@@ -752,10 +825,8 @@ func (g *Gateway) mcpFederatedToolsList(w http.ResponseWriter, r *http.Request,
|
||||
sem <- struct{}{}
|
||||
defer func() { <-sem }()
|
||||
|
||||
ctx, cancel := context.WithTimeout(r.Context(), toolsListBackendTimeout)
|
||||
defer cancel()
|
||||
targetURL := g.cfg.MCPServers[name].URL
|
||||
resp, err := g.mcpBackendCall(ctx, targetURL, "tools/list", struct{}{})
|
||||
resp, err := g.mcpBackendCall(fanoutCtx, targetURL, "tools/list", struct{}{}, mcpBackendResponseMaxBytes)
|
||||
|
||||
mu.Lock()
|
||||
defer mu.Unlock()
|
||||
@@ -867,11 +938,24 @@ func (g *Gateway) mcpFederatedToolsCall(w http.ResponseWriter, r *http.Request,
|
||||
ctx, cancel := context.WithTimeout(r.Context(), toolsCallBackendTimeout)
|
||||
defer cancel()
|
||||
targetURL := g.cfg.MCPServers[serverName].URL
|
||||
resp, err := g.mcpBackendCall(ctx, targetURL, "tools/call", mcpToolCallParams{Name: toolName, Arguments: params.Arguments})
|
||||
// mcpBackendCallResponseMaxBytes (10MiB), not the fan-out's smaller
|
||||
// mcpBackendResponseMaxBytes (security review round 2, 2026-08-22,
|
||||
// important finding 4): tools/call always resolves to exactly ONE
|
||||
// backend, so the fan-out memory-amplification argument does not
|
||||
// apply here — see mcpBackendCallResponseMaxBytes' own doc comment.
|
||||
resp, err := g.mcpBackendCall(ctx, targetURL, "tools/call", mcpToolCallParams{Name: toolName, Arguments: params.Arguments}, mcpBackendCallResponseMaxBytes)
|
||||
g.limiter.countTargetRequest(targetKindMCP, serverName)
|
||||
if err != nil {
|
||||
g.logf("federated tools/call: server %q: %v", serverName, err)
|
||||
writeJSONRPCErrorResponse(w, req.ID, jsonrpcInternalError, "upstream error")
|
||||
// A response that hit mcpBackendCallResponseMaxBytes gets its own
|
||||
// specific message, not the generic "upstream error" a truncated-
|
||||
// then-unparsable body would otherwise produce (security review
|
||||
// round 2, 2026-08-22, important finding 4).
|
||||
if strings.Contains(err.Error(), mcpResponseTooLargeMarker) {
|
||||
writeJSONRPCErrorResponse(w, req.ID, jsonrpcInternalError, "response too large")
|
||||
} else {
|
||||
writeJSONRPCErrorResponse(w, req.ID, jsonrpcInternalError, "upstream error")
|
||||
}
|
||||
return
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user