{"record":{"id":"f0339f67655958c7","repo":"github/github-mcp-server","slug":"numeric-value-out-of-int-range-v","errorCode":null,"errorMessage":"numeric value out of int range: %v","messagePattern":"numeric value out of int range: (.+?)","errorType":"validation","errorClass":null,"httpStatus":null,"severity":"error","filePath":"pkg/github/params.go","lineNumber":87,"sourceCode":"\tcase float64:\n\t\tf = v\n\tcase string:\n\t\tvar err error\n\t\tf, err = strconv.ParseFloat(v, 64)\n\t\tif err != nil {\n\t\t\treturn 0, fmt.Errorf(\"invalid numeric value: %s\", v)\n\t\t}\n\tdefault:\n\t\treturn 0, fmt.Errorf(\"expected number, got %T\", val)\n\t}\n\tif math.IsNaN(f) || math.IsInf(f, 0) {\n\t\treturn 0, fmt.Errorf(\"non-finite numeric value\")\n\t}\n\tif f != math.Trunc(f) {\n\t\treturn 0, fmt.Errorf(\"non-integer numeric value: %v\", f)\n\t}\n\tif f > math.MaxInt || f < math.MinInt {\n\t\treturn 0, fmt.Errorf(\"numeric value out of int range: %v\", f)\n\t}\n\treturn int(f), nil\n}\n\n// toInt64 converts a value to int64, handling both float64 and string representations.\n// Some MCP clients send numeric values as strings. It rejects NaN, ±Inf,\n// fractional values, and values that lose precision in the float64→int64 conversion.\nfunc toInt64(val any) (int64, error) {\n\tvar f float64\n\tswitch v := val.(type) {\n\tcase float64:\n\t\tf = v\n\tcase string:\n\t\tvar err error\n\t\tf, err = strconv.ParseFloat(v, 64)\n\t\tif err != nil {\n\t\t\treturn 0, fmt.Errorf(\"invalid numeric value: %s\", v)\n\t\t}","sourceCodeStart":69,"sourceCodeEnd":105,"githubUrl":"https://github.com/github/github-mcp-server/blob/0ea1f775a7c73eff1bd2e25904d01136756bbfe2/pkg/github/params.go#L69-L105","documentation":"Thrown by toInt in pkg/github/params.go when a valid, finite, integral number exceeds the platform int range (f > math.MaxInt or f < math.MinInt). On 64-bit platforms this takes values above ~9.2e18; on 32-bit builds the ceiling is much lower (~2.1e9), so the same request can fail only on 32-bit servers.","triggerScenarios":"per_page: 1e20 or page: 99999999999999999999 sent to an int parameter; IDs designed for int64 (e.g. large project/item IDs) routed to a plain-int tool parameter.","commonSituations":"Confusing an int-typed parameter with a bigint-typed one (comment_id/field_id/item_id use RequiredBigInt); sentinel values like 9223372036854775807 used as 'max'; 32-bit container builds lowering the ceiling.","solutions":["Send a value within int range (roughly ±2.1e9 on 32-bit, ±9.2e18 on 64-bit).","For large GitHub IDs, use the tools whose parameters go through RequiredBigInt (int64) rather than the int path.","Clamp absurd computed values (page*per_page overflow, default-to-max idioms) before sending."],"exampleFix":"// before\narguments = { owner, repo, per_page: 9223372036854775807 };\n// after\narguments = { owner, repo, per_page: 100 };","handlingStrategy":"validation","validationCode":"function clampInt(v, min, max) {\n  return Math.min(Math.max(Math.trunc(v), min), max);\n}\n// e.g. arguments.per_page = clampInt(requestedPer, 1, 100);","typeGuard":null,"tryCatchPattern":"On 'numeric value out of int range', clamp to a sane bound (per_page <= 100, page small) and retry; if the value is an ID, switch to a bigint-typed tool parameter.","preventionTips":["Never use MaxInt-style sentinels for 'give me everything' — per_page has a hard API cap anyway.","Know your deployment's platform: 32-bit server builds have a much lower int ceiling.","Clamp computed page offsets before sending."],"tags":["validation","numeric","overflow","argument-parsing","mcp-tool"],"backgroundTag":null,"analyzedSha":"0ea1f775a7c73eff1bd2e25904d01136756bbfe2","analyzedAt":"2026-08-15T18:10:19.804Z","schemaVersion":2},"datasetVersion":"2026-08-15T22:17:37.221Z"}