Analyze the programming language composition of a GitHub repository. Returns percentage breakdown of languages used, dominant language, and file counts per language. Use for understanding project tech stack or evaluating language distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name (e.g. 'cpython', 'go') | |
| owner | Yes | Repository owner GitHub username or organization (e.g. 'python', 'golang') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value by specifying what the tool returns (percentage breakdown, dominant language, file counts). This goes beyond just a read-only flag, giving the agent a concrete picture of the tool's output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every clause serves a purpose. It avoids redundancy and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers purpose, usage context, and output details. It lacks explicit alternatives or exclusions, but given the tool's simplicity, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (owner, repo) fully described with examples. The description does not add parameter-specific insights beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes the programming language composition of a GitHub repository, with a specific action ('Analyze') and resource ('language composition'). It also details the specific outputs (percentage breakdown, dominant language, file counts), distinguishing it from siblings like get_repo_stats or search_repos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use cases: 'understanding project tech stack or evaluating language distribution.' While it doesn't explicitly mention when not to use it or name alternative tools, the context is sufficient for an agent to decide when this tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct task: searching, analyzing a single repo, analyzing language composition, and comparing multiple repos. Even though stats and compare both return metrics, their purposes are clearly separated (single vs. multi-repo), so no ambiguity.
All tool names follow the verb_noun pattern in snake_case (compare_repos, get_repo_languages, get_repo_stats, search_repos). The verbs are semantically appropriate and consistent in style.
The server is scoped to repository analytics and discovery, and four tools cover the core workflows without being sparse or bloated. Each tool has a clear purpose and earns its place.
The tool set covers the main steps of repository analysis: finding repos, getting overall stats, examining language breakdown, and comparing multiple candidates. Minor gaps exist (e.g., no direct tool for fetching README or file structure), but the provided surface is sufficient for the implied use case.