github-fetcher

GitHub repository health

github_repo_health

Read-onlyIdempotent

Fetches a one-call repository health snapshot: stars, open issue and PR counts, label breakdowns, windowed opened/closed totals, and release info to assess project activity.

Instructions

One-call repository snapshot: stars, true open issue and PR counts, has_issues/has_discussions, window opened/closed counts and per-label open counts (search-backed), and the latest release. Window terms: opened_total = issues created inside the window (any current state); opened_still_open = the subset still open; closed = issues closed inside the window (any creation date). Costs about 10 upstream calls, 9 of them search (within the 30 requests/minute search quota). open_issues here counts issues only; github_repo.open_issues includes pull requests.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>"
    },
    "name": "github_repo_health"
  }
}

Input Schema

Name	Required	Description
`repo`	Yes	Repository in owner/name form
`fresh`	No	Bypass the local cache
`labels`	No	Open-issue labels to count, default bug/regression/data-loss/reproduced
`window_days`	No	Analysis window in days, default 30

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 1, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

This description adds high value by providing critical operational context missing from annotations, specifically the cost implication ('Costs about 10 upstream calls') and the associated rate limit constraint. This prevents potential call budget overruns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but highly functional. It uses a front-loaded structure to summarize the return data, followed by logical blocks defining metric behavior and operational costs. Every piece of information is relevant to tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is extremely thorough. It defines complex, derived metrics (e.g., 'opened_total = issues created inside the window') which an agent needs to fully interpret the tool's intended output and functionality, even if the output structure itself is dynamic.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since the schema coverage is 100%, the description focuses on clarifying semantic intent. It defines how `window_days` influences the resulting metrics and provides default expectations for the `labels` parameter, significantly aiding parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The tool description provides a clear, specific purpose: generating a 'One-call repository snapshot'. It explicitly lists the various metrics returned (stars, counts, release data), clearly distinguishing its function from simple listing tools like `github_issues`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While it doesn't explicitly reference sibling tools for comparison, it provides clear usage context by explaining the sophisticated nature of the health check. The detailed definitions of window terms help guide the agent on when this complex tool is necessary versus a simpler query.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.