Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

github_repo

Fetch public details of a GitHub repository by owner and repo name, including stars, forks, license, topics, default branch, and last push time.

Instructions

Retrieve a GitHub repository. Returns the public details of one GitHub repository, identified by the required owner and repo. Fields include the full name, description, main language, topics, stars, forks, watchers, open issues, license, default branch and last push time.

Input Schema

NameRequiredDescriptionDefault
repoYesRepository name
ownerYesRepository owner (user or org login)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It signals a read-only operation by using 'Retrieve' and 'Returns the public details', which is helpful. It does not disclose authentication requirements, rate limits, error behavior, or whether the response is paginated. For a simple getter it is adequate but leaves notable gaps.

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?

The description is three sentences, front-loaded with the core purpose, followed by input identification and a list of returned fields. Every sentence earns its place, and there is no redundant or filler content.

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?

No output schema exists, so the description compensates by enumerating the returned fields (full name, description, language, topics, stars, etc.). It also identifies the required inputs. Given the simplicity of the tool and the absence of annotations, this is nearly complete, though it omits error handling and rate limit information.

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 description coverage is 100%, so the schema already documents both parameters with clear descriptions ('Repository name' and 'Repository owner (user or org login)'). The description adds no additional format details, examples, or constraints beyond restating that owner and repo are required. Baseline 3 applies when the schema does the heavy lifting.

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 ('Retrieve') and resource ('GitHub repository') and clarifies that it returns details for one repository identified by owner and repo. It lists the returned fields, making the scope concrete. However, it does not distinguish this tool from sibling tools like github_search_repositories or github_repo_contributors, so it stops short of a 5.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention conditions like 'use this when you have a known owner/repo pair' or 'for search, use github_search_repositories instead'. The required parameters imply the need for owner and repo, but that is usage context, not selection guidance.

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

Deploy Server

Other Tools