Skip to main content
Glama

GitHub Hot Board

Get board snapshot

get_board
Read-only

Top-N rows of one leaderboard (rank, stars, forks, issues, language, description). Refreshes in hourly batches; generatedAt is the batch stamp (fetch once per hour).

Input Schema

NameRequiredDescriptionDefault
slugYesone of the 10 board slugs
limitNo
languageNooptional source-language facet; supported only for overall / weekly / monthly

Output Schema

NameRequiredDescriptionDefault
slugYes
itemsYes
sourceYesgithub-search | github-trending | github-search-fallback — which upstream produced this batch
degradedYestrue = the official Trending scrape failed and a Search-based fallback methodology was served; cite with care (HTML pages show the same warning)
languageYes
batchSizeYes
generatedAtYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful non-annotation behavior: hourly batch refreshes, generatedAt as the batch stamp, and fetch-once-per-hour guidance.

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

Conciseness5/5

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

Two tight sentences front-loaded with the resource and return fields. Every sentence carries useful information, including the refresh/caching note.

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

Completeness4/5

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

For a simple read-only snapshot tool with an output schema and readOnlyHint annotation, the description covers refresh semantics and top-N behavior adequately. The main omission is explicit routing guidance among sibling tools, though the slug enum and list_boards likely cover discovery.

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

Parameters3/5

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

Schema coverage is 67%, and the description clarifies that 'top-N' maps to the limit concept while listing returned fields. It does not add slug enum meaning, limit bounds/default, or language facet restrictions beyond what the schema already provides.

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

Purpose4/5

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

States a specific action and resource: returns top-N rows of one leaderboard and enumerates the fields returned. It is clear but does not explicitly distinguish itself from siblings such as get_board_movers or list_boards.

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

Usage Guidelines3/5

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

Provides operational guidance about hourly batch refreshes and fetching once per hour. However, it does not state when to use get_board versus get_board_movers, list_boards, or search_library, and it gives no exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.