github/github-mcp-server · error

non-finite numeric value

Error message

non-finite numeric value

What it means

Thrown by toInt in pkg/github/params.go when the parsed numeric value is NaN or ±Inf. Standard JSON cannot carry these values, so in practice they arrive as strings that Go's ParseFloat happily accepts ("NaN", "Inf", "+Inf", "-Infinity") and are then rejected as non-finite before integer conversion.

Source

Thrown at pkg/github/params.go:81

// toInt converts a value to int, handling both float64 and string representations.
// Some MCP clients send numeric values as strings. It rejects NaN, ±Inf,
// fractional values, and values outside the int range.
func toInt(val any) (int, error) {
	var f float64
	switch v := val.(type) {
	case float64:
		f = v
	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)
	}
	if f > math.MaxInt || f < math.MinInt {
		return 0, fmt.Errorf("numeric value out of int range: %v", f)
	}
	return int(f), nil
}

// toInt64 converts a value to int64, handling both float64 and string representations.
// Some MCP clients send numeric values as strings. It rejects NaN, ±Inf,
// fractional values, and values that lose precision in the float64→int64 conversion.
func toInt64(val any) (int64, error) {
	var f float64
	switch v := val.(type) {
	case float64:
		f = v

View on GitHub (pinned to 0ea1f775a7)

Solutions

1. Fix the upstream computation so it never produces NaN/Infinity (guard divide-by-zero, check Number.isFinite before sending).
2. Send a concrete integer value for the parameter.
3. Validate arguments client-side with Number.isFinite when the value originates from math.

Example fix

// before
const page = String(total / perPage); // "Infinity" or "NaN"
arguments = { owner, repo, page };
// after
const page = Number.isFinite(total / perPage) ? total / perPage : 1;
arguments = { owner, repo, page };

function finiteNumber(v, fallback) {
  return typeof v === "number" && Number.isFinite(v) ? v : fallback;
}
// when building arguments from computed values:
args.page = finiteNumber(computedPage, 1);

function isFiniteNumberLike(v: unknown): v is number {
  return typeof v === "number" && Number.isFinite(v);
}

On 'non-finite numeric value', trace which computed argument produced NaN/Infinity, fix the computation (usually a divide-by-zero or missing total), then retry.

When it happens

Trigger: page: "NaN" or per_page: "Infinity" sent to an int parameter; client code stringifying a computed Infinity/NaN (e.g. division by zero formatted to string) into the arguments.

Common situations: Downstream calculations (percentages, counts) that yield NaN/Infinity being forwarded without checks; copy-paste of literal debug values; clients mapping JavaScript's Infinity to the string "Infinity".

Related errors

• invalid numeric value: %s
• expected number, got %T
• non-integer numeric value: %v
• numeric value out of int range: %v
• parameter %s is not a valid number: %w

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