What causes "perPage value %d cannot be negative" in github/github-mcp-server?

Use 0 (or omit per_page) to signal 'server default' — never -1

perPage value %d cannot be negative

Error message

perPage value %d cannot be negative

What it means

Returned by CursorPaginationParams.ToGraphQLParams when perPage is negative. first/last in GitHub's GraphQL pagination must be non-negative, so the guard rejects the request before it reaches the API. Negative values normally indicate a parsing or configuration bug upstream rather than user intent.

Source

Thrown at pkg/github/params.go:480

	PrevCursor      string `json:"prevCursor,omitempty"`
}

func buildPageInfo(resp *github.Response) pageInfo {
	return pageInfo{
		HasNextPage:     resp.After != "",
		HasPreviousPage: resp.Before != "",
		NextCursor:      resp.After,
		PrevCursor:      resp.Before,
	}
}

// ToGraphQLParams converts cursor pagination parameters to GraphQL-specific parameters.
func (p CursorPaginationParams) ToGraphQLParams() (*GraphQLPaginationParams, error) {
	if p.PerPage > 100 {
		return nil, fmt.Errorf("perPage value %d exceeds maximum of 100", p.PerPage)
	}
	if p.PerPage < 0 {
		return nil, fmt.Errorf("perPage value %d cannot be negative", p.PerPage)
	}
	first := int32(p.PerPage)

	var after *string
	if p.After != "" {
		after = &p.After
	}

	return &GraphQLPaginationParams{
		First: &first,
		After: after,
	}, nil
}

type GraphQLPaginationParams struct {
	First *int32
	After *string
}

View on GitHub (pinned to 0ea1f775a7)

Solutions

Use 0 (or omit per_page) to signal 'server default' — never -1
Clamp derived page sizes: if perPage < 0 { perPage = 0 } before building the call
Audit any arithmetic that computes per_page for underflow at boundary conditions

Example fix

// before
perPage := remainingItems - fetchedSoFar // can go negative
// after
perPage := remainingItems - fetchedSoFar
if perPage < 0 {
    perPage = 0
}

Defensive patterns

Strategy: validation

Validate before calling

func normalizePerPage(n int) int {
    if n < 0 {
        return 0 // 0 = server default
    }
    if n > 100 {
        return 100
    }
    return n
}

Type guard

func isNonNegative(n int) bool {
    return n >= 0
}

Try / catch

if _, err := p.ToGraphQLParams(); err != nil && strings.Contains(err.Error(), "cannot be negative") {
    // programming bug upstream: fix the computation, don't retry
    logAndAlert("negative per_page produced by pagination math")
}

Prevention

Use 0 or omission for 'default page size', never -1 sentinels
Guard derived page-size math with max(0, n) at the boundary
Unit-test pagination arithmetic at boundary conditions (remaining=0, fetched>remaining)

When it happens

Trigger: Arithmetic that computes page size as page*limit - offset gone negative; config defaulting to -1 as an 'unset' sentinel being forwarded verbatim; a client computing per_page as (remaining budget) which goes negative at the end of a crawl; sign errors when negating a value.

Common situations: '-1 means unlimited' conventions from other SDKs leaking into this server's per_page; crawler/scraper frameworks deriving page sizes dynamically; test fixtures with negative sizes.

Related errors

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