Keelen

List GitHub Repositories

list_github_repos

List the CALLER's own GitHub-visible repos (for import_project).

For an OAuth connector that is the connected member; for a static workspace
key it is an eligible active owner. Each entry has full_name,
default_branch, private, language, pushed_at. A `full_name` is what
import_project(repo_full_name) connects. A COMPLETE listing publishes an
actor-bound proof valid for 10 minutes, and that proof is what authorizes a
later import by the same caller. Reading the list can MINT a short-lived
GitHub installation token, so this is not a pure read. Returns 409 if GitHub
isn't connected yet — connect_github() is required first. A provider
failure is translated into a typed, actionable error instead of passing
GitHub's response through: a missing or suspended App installation, a
revoked OAuth token, or a non-rate-limit permission denial is a 409 naming
connect_github(); a recognized rate limit is a 429; other provider failures
are a 502; a timeout or transport failure is a 503.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_github_repos"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses side effects that annotations cannot convey: reading the list can mint a short-lived GitHub installation token, so it is 'not a pure read,' which correctly explains the readOnlyHint=false and non-idempotent hints. It further details the 10-minute actor-bound proof that authorizes a later import, and maps failure modes to concrete status codes (409 with connect_github() for missing/suspended installation, revoked token, or permission denial; 429 rate limit; 502 other provider failure; 503 timeout).

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?

Structure is front-loaded: purpose and caller scoping first, then the import linkage, then side effects, then error semantics. Every sentence earns its place, though the four-status error enumeration is dense and could be compressed to a table-like single clause without losing meaning.

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?

For a zero-parameter tool with an output schema and partial annotations, the description covers everything an agent needs before calling: auth prerequisite, caller identity semantics, the side effect that explains the annotation profile, the proof artifact it produces, and all error outcomes. Nothing material is missing.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4; there is nothing to disambiguate. The description instead spends its words on the shape of each returned entry (full_name, default_branch, private, language, pushed_at) and the significance of full_name as the import key, which is genuinely useful even though an output schema exists.

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 first sentence states a specific verb and resource ('List the CALLER's own GitHub-visible repos') and immediately ties it to its downstream consumer, import_project. It also scopes the ambiguous notion of 'caller' by contrasting OAuth connectors from static workspace keys, so an agent can distinguish this from import_project or list_projects without opening any schema.

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?

Usage context is strong: it is explicitly 'for import_project', and it states that a full_name is what import_project(repo_full_name) consumes, plus a hard prerequisite ('connect_github() is required first'). It stops short of an explicit when-not-to-use rule, but the workflow ordering (connect -> list -> import) is unambiguous.

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

All Keelen tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.