Skip to main content
Glama
Sign In
@sumirati/mcp-github

@sumirati/mcp-github

by sumirati
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Get File Contents

get_file_contents
Read-onlyIdempotent

Read file contents, extract symbol outlines, slice line ranges, or list directory entries from a GitHub repository at a git ref without cloning. Automatically decodes Base64 to UTF-8.

Instructions

Read current file contents, extract symbol outlines, slice line ranges, or list directory entries from a repository at a specified git ref without cloning. Automatically decodes Base64 file contents into plain text UTF-8. Eager daily driver tool for inspecting source code, configuration files, and directory layouts.

Input Schema

NameRequiredDescriptionDefault
refNoGit reference (branch name, tag, or commit SHA) to read from (default: default branch / HEAD)
pathYesRelative path to file or directory in repository (e.g. 'README.md', 'src/index.js', or '' for root)
repoYesRepository name (e.g. 'Hello-World' or 'mcp-github')
ownerYesRepository owner (user or organization, e.g. 'octocat' or 'buggycode')
end_lineNoOptional 1-based end line to slice file contents
start_lineNoOptional 1-based start line to slice file contents
outline_onlyYesExtract top-level symbol signatures (functions, classes, interfaces, types) with line numbers to conserve tokens (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.2.0
    • addedInput schema / properties / end_line
      Added value: +{
+  "description": "Optional 1-based end line to slice file contents",
+  "type": "number"
+}
    • addedInput schema / properties / outline_only
      Added value: +{
+  "default": false,
+  "description": "Extract top-level symbol signatures (functions, classes, interfaces, types) with line numbers to conserve tokens (default: false)",
+  "type": "boolean"
+}
    • addedInput schema / properties / start_line
      Added value: +{
+  "description": "Optional 1-based start line to slice file contents",
+  "type": "number"
+}
    • changedInput schema / required
      Previous value: -[
-  "owner",
-  "repo",
-  "path"
-]New value: +[
+  "owner",
+  "repo",
+  "path",
+  "outline_only"
+]
  2. Changed2 schema fields changedv2.1.0
    • changedInput schema / properties / path / description
      Previous value: -"Path to the file or directory in repository (e.g. 'README.md' or 'src/index.js')"New value: +"Relative path to file or directory in repository (e.g. 'README.md', 'src/index.js', or '' for root)"
    • changedInput schema / properties / ref / description
      Previous value: -"Branch name, tag, or commit SHA (default: default branch / HEAD)"New value: +"Git reference (branch name, tag, or commit SHA) to read from (default: default branch / HEAD)"
  3. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds real value beyond them: no cloning required, automatic Base64-to-UTF-8 decoding, and token conservation via outline mode. It omits error/edge behavior (binary files, missing paths), keeping it at a 4.

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?

Three sentences, front-loaded with the core capability and followed by behavioral detail and usage context. Dense but not padded; 'Eager daily driver tool' is slightly colloquial but conveys intent efficiently.

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 read-only, 7-parameter tool with no output schema, the description covers all four operating modes and the key behavioral traits (decoding, no clone, token conservation). The main gap is what the returned content looks like for directory listings versus file reads, but this is minor for a read tool.

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 100%, so the baseline is 3, but the description goes further by tying its modes to parameters: symbol outlines map to outline_only, line ranges to start_line/end_line, and directory layouts to path. This semantic linkage helps the agent understand how the parameters combine, though it adds no syntax details beyond the schema.

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 a specific verb and resource ('Read current file contents') and enumerates the four distinct modes (read, outline extraction, line-range slicing, directory listing) plus the git-ref scope. It is easily distinguishable from siblings like get_commit and get_repository, which deal with different resources.

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 provides clear usage context ('Eager daily driver tool for inspecting source code, configuration files, and directory layouts') that tells the agent when this tool is the natural choice. It stops short of naming alternatives or exclusions (e.g., when to prefer get_commit or get_repository instead), so it is clear context rather than explicit routing.

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