Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

github_commit_files

Destructive

Commit one or more files to a GitHub repository. Prefer the exact owner from github_list_repositories; 'repo' also accepts the combined 'owner/name' form. Creates or updates files in a single atomic commit. Use this to add Dockerfiles, CI workflows, configuration files, etc. Maximum 20 files and 500KB total content per commit.

Input Schema

NameRequiredDescriptionDefault
repoYesRepository name. Also accepts the combined 'owner/name' form.
filesYesFiles to create or update. Each entry has a 'path' and 'content'.
ownerYesRepository owner (e.g. 'octocat'). Prefer the exact owner from a prior github_list_repositories call. May be embedded in 'repo' as 'owner/name'.
branchNoBranch to commit to. Defaults to the repository's default branch.
merge_parentNoMerge another branch of this repository into 'branch': its name, never a commit id. The commit becomes a true merge commit whose parents are 'branch' and merge_parent, carrying every change merge_parent made since the two diverged with its file modes. 'files' must then resolve every file both sides changed since they diverged, with the complete merged content or as a deletion; the call is refused, naming them, while any is unresolved. Use it to resolve a pull request that conflicts with its base: merge_parent is the base branch and 'branch' the pull request's branch, never the default branch.
commit_messageYesGit commit message describing the changes.
confirm_large_deletionsNoPaths from 'files' whose new content is intentionally much shorter than the file it replaces. A commit that would replace an existing file with less than half of its content is refused unless that path is listed here. Leave this out unless a refusal named the path and removing that much is the change you intend.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / files / items / properties / delete
      Added value: +{
+  "description": "With merge_parent only: true resolves a file both sides changed by removing it (a file one side deleted or renamed away). Leave 'content' out. Counts as a large deletion (confirm_large_deletions).",
+  "type": "boolean"
+}
    • changedInput schema / properties / files / items / required
      Previous value: -[
-  "path",
-  "content"
-]New value: +[
+  "path"
+]
    • addedInput schema / properties / merge_parent
      Added value: +{
+  "description": "Merge another branch of this repository into 'branch': its name, never a commit id. The commit becomes a true merge commit whose parents are 'branch' and merge_parent, carrying every change merge_parent made since the two diverged with its file modes. 'files' must then resolve every file both sides changed since they diverged, with the complete merged content or as a deletion; the call is refused, naming them, while any is unresolved. Use it to resolve a pull request that conflicts with its base: merge_parent is the base branch and 'branch' the pull request's branch, never the default branch.",
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / confirm_large_deletions
      Added value: +{
+  "description": "Paths from 'files' whose new content is intentionally much shorter than the file it replaces. A commit that would replace an existing file with less than half of its content is refused unless that path is listed here. Leave this out unless a refusal named the path and removing that much is the change you intend.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / files / items / properties / content / description
      Previous value: -"File content as a string."New value: +"The COMPLETE new content of the file. The commit replaces the whole file with this string; it is not a patch, so anything left out is deleted."
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Adds real behavior beyond the destructiveHint annotation: atomicity of the commit, hard limits (20 files / 500KB total), and that files are created or updated in place. What it leaves implicit is that each 'content' fully replaces the existing file — that warning lives only in the schema, and the irreversible overwrite risk of a destructive commit could be stated more plainly.

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?

Four short sentences, front-loaded with the action, then owner sourcing, then atomicity, then limits. Every sentence carries information an agent needs and nothing is padded.

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 7-parameter write tool with no output schema, the description covers scope, sourcing, atomicity, and quotas. The one gap is the return value — nothing tells the agent what comes back (commit SHA, URL, changed paths) to confirm or chain the operation.

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 parameters are already thoroughly documented, including the 'owner/name' form, merge_parent semantics, and confirm_large_deletions. The description repeats the owner source and the combined repo form, adding no meaning the schema doesn't already carry — baseline 3 is correct.

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?

States a specific verb and resource — commit one or more files to a GitHub repo — and immediately distinguishes scope with 'creates or updates files in a single atomic commit'. Among the many github_* siblings, only this one writes files, and the description makes that unambiguous.

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?

Gives both a positive use case ('add Dockerfiles, CI workflows, configuration files') and a routing hint to call github_list_repositories first for the owner. It never says when NOT to use it — e.g., versus reading files or managing branches — so the alternative-sibling routing is incomplete.

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

All Ankra toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources