Agent Kiosk

github_intel

Read-onlyIdempotent

Analyze GitHub repository metrics and recent releases via owner/repo, or search a topic to discover rapidly growing repositories.

Instructions

GitHub repository & open-source competitive intelligence. Pass 'owner/repo' for deep repository metrics and latest releases, or a keyword topic to find the fastest-growing repositories.

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": {
      "query": "<query>"
    },
    "name": "github_intel"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Number of repositories when searching by topic (1-15, default: 5)
`query`	Yes	Repository 'owner/repo' (e.g., 'vercel/next.js') OR search topic (e.g., 'mcp server')

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.5.0Oct 18, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds mode-dependent behavior (deep metrics + releases vs. ranked growing repos), which is modestly useful, but it discloses nothing about auth requirements, rate limits, or result ordering/timeliness — notable gaps for an open-world GitHub-backed tool.

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 tool's domain and then the two input branches. Every clause carries routing information; nothing is redundant or padded.

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 2-parameter, no-output-schema tool, the description covers both invocation modes and hints at the returned content (repository metrics, latest releases, fastest-growing repos). It leaves the shape/number of results and whether limit only applies to topic search unaddressed, but that is a minor gap given the annotations carry the safety context.

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 100%: both the 'owner/repo' vs. topic semantics of 'query' and the 1-15 range/default of 'limit' are already documented in the schema. The description echoes the owner/repo syntax without adding format rules or edge cases beyond it, so the baseline 3 applies.

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 verb+resource ('GitHub repository & open-source competitive intelligence') and distinguishes its two operating modes: single-repo deep metrics vs. topic-based discovery. It does not, however, differentiate itself from adjacent siblings like package_audit or security_audit, so an agent must infer that this tool is about growth/release intelligence rather than security or dependency auditing.

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?

Explicitly tells the agent how to route input: 'Pass owner/repo for deep repository metrics... or a keyword topic to find the fastest-growing repositories.' That resolves the otherwise ambiguous single 'query' parameter. It stops short of stating when to prefer this over sibling tools (package_audit, security_audit, web_extract), so there are no true exclusions.

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