github/github-mcp-server · error

numeric value %v is too large to fit in int64

Error message

numeric value %v is too large to fit in int64

What it means

Thrown by toInt64 in pkg/github/params.go when the value is integral and finite but cannot be represented exactly as int64: either it exceeds the int64 range, or (the subtle case) a value in the 2^53..2^63 band was sent as a JSON number, lost precision in float64, and fails the float64(result) != f round-trip check.

Source

Thrown at pkg/github/params.go:118

	case string:
		var err error
		f, err = strconv.ParseFloat(v, 64)
		if err != nil {
			return 0, fmt.Errorf("invalid numeric value: %s", v)
		}
	default:
		return 0, fmt.Errorf("expected number, got %T", val)
	}
	if math.IsNaN(f) || math.IsInf(f, 0) {
		return 0, fmt.Errorf("non-finite numeric value")
	}
	if f != math.Trunc(f) {
		return 0, fmt.Errorf("non-integer numeric value: %v", f)
	}
	result := int64(f)
	// Check round-trip to detect precision loss for large int64 values
	if float64(result) != f {
		return 0, fmt.Errorf("numeric value %v is too large to fit in int64", f)
	}
	return result, nil
}

// RequiredParam is a helper function that can be used to fetch a requested parameter from the request.
// It does the following checks:
// 1. Checks if the parameter is present in the request.
// 2. Checks if the parameter is of the expected type.
// 3. Checks if the parameter is not empty, i.e: non-zero value
func RequiredParam[T comparable](args map[string]any, p string) (T, error) {
	var zero T

	// Check if the parameter is present in the request
	if _, ok := args[p]; !ok {
		return zero, fmt.Errorf("missing required parameter: %s", p)
	}

	// Check if the parameter is of the expected type

View on GitHub (pinned to 0ea1f775a7)

Solutions

  1. Send large IDs as decimal STRINGS, not JSON numbers — the string path through ParseFloat is the supported way to carry full-precision int64 values.
  2. In JavaScript, keep IDs as strings or BigInt end-to-end and never route them through Number.
  3. Confirm the value really is within int64 range; if it came from a prior tool response, re-read it from that response's raw string form.

Example fix

// before (JS loses precision above 2^53)
arguments = { ownerId, itemId: 9007199254740993 };
// after
arguments = { ownerId, itemId: "9007199254740993" };
Defensive patterns

Strategy: type-guard

Validate before calling

function safeBigintArg(name, v) {
  const s = typeof v === "string" ? v : String(v);
  const n = Number(s);
  if (!Number.isInteger(n) || Math.abs(n) > 9223372036854775807 || String(n) !== s) {
    throw new Error(`${name}: send large ids as exact decimal strings`);
  }
  return s;
}

Type guard

function isExactInt64String(v: unknown): v is string {
  if (typeof v !== "string" || !/^-?\d+$/.test(v)) return false;
  const n = Number(v);
  return Number.isSafeInteger(n) || Math.abs(BigInt(v)) <= 9223372036854775807n;
}

Try / catch

On 'too large to fit in int64', locate where the id became a JS Number (precision already lost), re-fetch the original id string from the API response, and retry with the string form. Retrying the same number will always fail.

Prevention

When it happens

Trigger: field_id sent as the JSON number 9007199254740993 (2^53+1, not representable in float64); comment_id like 1e19 overflowing int64; any ID above 9223372036854775807.

Common situations: Large GitHub/Projects v2 IDs serialized as JSON numbers by JS clients (JS numbers are float64, losing precision above 2^53); sending Number.MAX_SAFE_INTEGER+1; assuming the server will silently clamp.

Related errors

AI-assisted analysis of github/github-mcp-server@0ea1f775a7 (2026-08-15). Data as JSON: /api/errors/4af6c2347dca03ad. Report an issue: GitHub.