Skip to main content
Glama
Sign In

searchcode

by com.searchcode
OverviewDiscussionsAdmin

code_get_files

Get contents of multiple files from a remote public git repository in a single call. Reduces round-trips when you need to read several related files. Max 10 files per batch, 5000 total lines budget across all files. Each file supports optional line ranges. Failed files return per-file errors without blocking other files.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repository": "<repository>",
      "paths": "<paths>"
    },
    "name": "code_get_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathsYesList of files to read. Each entry has a path and optional line range.
max_linesNoPer-file safety cap on lines returned (cap: 2000).
repositoryYesFull git URL of ONE public remote repository, e.g. "https://github.com/redis/redis". Required. There is no cross-repository or global search: this API analyses one repository per call, cloning it on demand. Wildcards and placeholders ("*", "all", "global", a bare host like "github.com") are rejected — if you do not have a specific repository URL, ask for one rather than guessing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / repository / description
      Previous value: -"Git URL of a public remote repository"New value: +"Full git URL of ONE public remote repository, e.g. \"https://github.com/redis/redis\". Required. There is no cross-repository or global search: this API analyses one repository per call, cloning it on demand. Wildcards and placeholders (\"*\", \"all\", \"global\", a bare host like \"github.com\") are rejected — if you do not have a specific repository URL, ask for one rather than guessing."
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and mostly delivers: it discloses the 10-file cap, the 5000-line cross-file budget, and per-file error isolation so one failure doesn't abort the batch. It omits auth/rate-limit context and the public-repo cloning behavior (the latter covered in the schema).

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 tight sentences, front-loaded with purpose, then benefit, then hard limits, then error semantics. Nothing is redundant and no sentence can be dropped without losing information.

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?

No output schema exists, so the description should sketch return behavior; it explains per-file error returns but not the successful content shape (e.g., contents keyed by path). The imposed limits and error model make it adequate for a 3-parameter batch 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 baseline is 3. The description adds value beyond the schema by disclosing the 5000 total-line budget across all files, which is not expressed anywhere in the parameter definitions, and confirms optional per-file line ranges.

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?

States a specific verb and resource ('Get contents of multiple files from a remote public git repository') plus batch scope ('in a single call'). The 'multiple files' framing implicitly separates it from the single-file sibling code_get_file, though that sibling is never named.

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 a clear selection condition: 'Reduces round-trips when you need to read several related files.' It does not name code_get_file as the single-file alternative or state when not to batch, so exclusions are absent, keeping it below 5.

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

All searchcode 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