What causes "expected number, got %T" in github/github-mcp-server?

Pass a plain JSON number (or numeric string) for the parameter.

expected number, got %T

Error message

expected number, got %T

What it means

Thrown by toInt in pkg/github/params.go when a value destined for an int parameter is neither a float64 (JSON number) nor a string — i.e. a bool, array, or object. JSON decodes numbers to float64, so this error means the argument is structurally the wrong kind of value, not just malformed text.

Source

Thrown at pkg/github/params.go:78

	return errors.As(err, &acceptedError)
}

// 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

View on GitHub (pinned to 0ea1f775a7)

Solutions

Pass a plain JSON number (or numeric string) for the parameter.
Unwrap single-element arrays before sending.
Check the tool's inputSchema for the exact expected type of the failing parameter.
Enable client-side JSON schema validation of tool arguments before dispatch.

Example fix

// before
arguments: { owner, repo, per_page: [30] }
// after
arguments: { owner, repo, per_page: 30 }

Defensive patterns

Strategy: type-guard

Validate before calling

function assertScalarNumber(name, v) {
  if (v !== undefined && typeof v !== "number" && typeof v !== "string") {
    throw new Error(`${name} must be number or numeric string, got ${typeof v}`);
  }
}

Type guard

function isNumberLike(v: unknown): v is number | string {
  return (typeof v === "number" && Number.isFinite(v)) ||
         (typeof v === "string" && v.trim() !== "" && !isNaN(Number(v)));
}

Try / catch

On 'expected number, got bool/array/map', correct the argument shape client-side (unwrap arrays, extract scalar fields) and retry once.

Prevention

Do not forward raw form or LLM payloads into tool arguments; map fields explicitly.
Reject true/false and objects for numeric fields at your boundary.
Log the full arguments object on failure to spot structural mistakes quickly.

When it happens

Trigger: per_page: true, page: [1], or per_page: {"value": 30} passed to an int-typed parameter of a tool like list_issues or list_pull_requests.

Common situations: LLMs answering a numeric field with true/false; clients passing a single-element array; nested objects produced by double-wrapping of the arguments payload; boolean flags mistakenly reused for numeric fields.

Related errors

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