Skip to main content
Glama

github_files

GitHub — read and write repository files.

op='read' returns the decoded TEXT; op='list' returns the contents of a directory; op='readme' finds the README whatever its name.

⚠️ Beyond 1 MB, GitHub serves the metadata without the content: the read then says so by name rather than returning an empty string that would read as an empty file.

⚠️ Writing over an existing file REQUIRES its sha (the blob's, returned by op='list' or by a read). Without it, GitHub answers 409: it is its concurrency control, which guarantees we replace the version we read and not a change that arrived in the meantime. Omitting it is normal for a CREATION.

⚠️ Each write is a real commit on the targeted branch (branch, or the default branch) — visible in history, and attributed to the token holder.

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_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNoread | list | readme | write | delete.read
refNobranch, tag or SHA to read (default: default branch).
shaNoop='write' (update) / 'delete' — the existing blob's sha.
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
pathNopath of the file or directory.
repoNorepository name.
ownerNorepository owner.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
branchNoop='write'/'delete' — the target branch.
_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.
contentNoop='write' — the text content to write.
messageNoop='write'/'delete' — the commit message.
_accountNoCompte à OPÉRER parmi : `Julien` (org), `Tulina front` (org). `oto_identity(op='list')`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does real work: the >1 MB metadata-only behavior, the 409 concurrency control behind sha, and the fact that every write is a real attributed commit visible in history. However, delete is never characterized (does it need sha? is it reversible?) and no permission/auth or rate-limit context is given for a destructive-capable tool.

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?

Front-loaded with the capability, then the three hazards in descending order of consequence. The emoji-prefixed warning blocks are slightly noisy but each maps to a real failure mode, so nothing is padding. It is appropriately sized for five operations and fifteen parameters.

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?

A 15-parameter, 5-op, no-annotation, no-output-schema tool needs substantial prose, and this supplies the highest-risk facts (oversize reads, overwrite 409, commit attribution). Gaps remain: delete semantics, what read/list actually return structurally, and the mandatory _run_id context for reserved-row writes are not covered.

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?

Schema coverage is already 100%, so the baseline is 3; the description clears that bar by explaining *why* sha exists and what omitting it means, which the schema only states mechanically ('the existing blob's sha'). branch's default-branch fallback is also restated usefully. The opaque scoping parameters (_org, _group, _run_id, _account, _project, _instance) are left entirely to the schema.

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?

The lead sentence names a specific verb set and resource ('read and write repository files') and the description then enumerates each op's distinct outcome (read returns decoded TEXT, list returns directory contents, readme resolves the README regardless of filename). That is far more than a restatement of the name. It stops short of naming which sibling to use instead (github_repos, github_search), so it earns 4 rather than 5.

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?

Per-operation guidance is explicit, and the sha warning draws the crucial line between CREATION (omit sha, 'normal') and UPDATE (sha mandatory). What is absent is any exclusion or routing advice — nothing says when to use github_files versus github_search or github_repos, which matters in a tool list this dense.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources