Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

github_repos

GitHub — repositories: profile, branches, commits, tags, releases.

The entry point for getting oriented in a repository before reading its code (github_files) or its tickets (github_issues).

⚠️ A 404 on a private repository almost always signals a token without the right, not a wrong name.

⚠️ op='commit' returns the commit WITH its diff: GitHub caps at 300 files and truncates beyond that without saying so in files — compare to stats to notice.

⚠️ op='latest_release' ignores drafts AND prereleases: it is not the last tag created.

op: mine | org | user (repository lists) · get · branches · commits · commit (with diff) · compare (base…head) · tags · contributors · languages · topics · releases · release · latest_release · create_release · update_release.

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": "github_repos"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNothe operation, see above.mine
orgNoop='org' — the organization whose repositories are listed.
refNoop='commit' — branch, tag or SHA.
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
baseNoop='compare' — the starting reference.
fullNolist ops only (mine | org | user | branches | commits | tags | contributors | releases) — the page as GitHub sends it. Default: the index view (no API links; users, labels, milestones, repositories by name; a body by its `_length`).
headNoop='compare' — the ending reference.
pageNopage number.
pathNoop='commits' — only keep commits touching this path.
repoNorepository name.
sortNoop='mine'/'org'/'user' — created | updated | pushed | full_name.
ownerNorepository owner.
sinceNoop='commits' — lower bound (ISO 8601).
untilNoop='commits' — upper bound (ISO 8601).
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
authorNoop='commits' — filter by author.
fieldsNoop='create_release'/'update_release' — the body (tag_name required).
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_accountNoCompte à OPÉRER parmi : `Julien` (org), `Tulina front` (org). `oto_identity(op='list')`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
per_pageNorows per page (1-100, default 30).
usernameNoop='user' — the account whose public repositories are listed.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
release_idNoop='release'/'update_release' — the targeted release.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden and delivers three high-value, non-obvious behaviors: a 404 on a private repo usually means an under-scoped token rather than a bad name, op='commit' silently truncates diffs past 300 files so `stats` must be cross-checked, and latest_release skips drafts and prereleases so it is not the last tag created. It does not cover the write operations (create_release, update_release) — permissions required, reversibility — nor pagination or rate-limit behavior.

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?

Purpose and sibling routing are front-loaded, followed by scannable ⚠️ warnings, then the op list — a sensible order for an agent skimming. The trailing op enumeration largely duplicates the schema enum, which is mild redundancy, but the earlier warnings justify their length.

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 24-parameter, 17-op gateway with no annotations and no output schema, the description supplies the orientation framing and the sharpest traps. Gaps remain around op-specific preconditions and the difference between the index view and `full` output (left entirely to the schema), but nothing essential to calling it is missing.

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 every one of the 24 parameters is already documented at the field level, which sets the baseline at 3. The description adds little beyond restating the op enum and tying a few ops to their params inside the warnings; it does not explain cross-op requirements such as which identifiers each op needs (owner/repo vs org vs username).

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 description names the resource (repositories) and enumerates the concrete facets it covers (profile, branches, commits, tags, releases), then positions itself explicitly as the orientation entry point relative to two named siblings, github_files and github_issues. An agent can tell what this tool is for and what it is not for without opening the 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?

It states the operating context clearly: use this first to get oriented in a repo, then move to github_files for code or github_issues for tickets. That is genuine when-to-use routing. It stops short of telling the agent which of the 17 ops to reach for under a given intent, leaving op selection to the enum and param descriptions.

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

All Tulina toolsInspect
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.

Resources