Skip to main content
Glama

get_file_ledger

Retrieve the complete change history of a file to understand its modification timeline before making edits.

Instructions

Get all logged changes that touched a specific file path. Use to understand the change history of a file before modifying it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filePathYes

Implementation Reference

  • Core handler: getFileLedger reads the ledger file, filters entries whose filesAffected include the given filePath (normalized), and returns matching entries along with git branch/sha context.
    async function getFileLedger(filePath: string): Promise<LedgerQueryResult> {
      const [entries, context] = await Promise.all([
        fs.readLedger(ledgerPath),
        git.getBranchContext(repoDir),
      ]);
    
      const normalized = filePath.replace(/\\/g, '/');
      return {
        entries: entries.filter((e) =>
          e.filesAffected.some((f) => f.replace(/\\/g, '/').includes(normalized)),
        ),
        branch: context.branch,
        sha: context.shortSha,
      };
    }
  • Zod schema for get_file_ledger: requires filePath (non-empty string).
    export const GetFileLedgerSchema = z.object({
      filePath: z.string().min(1),
    });
  • Registration of the 'get_file_ledger' MCP tool: description, schema binding, and handler that delegates to manager.getFileLedger().
    server.tool('get_file_ledger', 'Get all logged changes that touched a specific file path. Use to understand the change history of a file before modifying it.', GetFileLedgerSchema.shape, async (args) => {
      const result = await manager.getFileLedger(args.filePath);
      return {
        content: [{ type: 'text' as const, text: JSON.stringify(result, null, 2) }],
      };
    });
  • Helper: readLedger reads the JSONL ledger file and parses each line into a LedgerEntry array. Used by getFileLedger to load all entries.
    async function readLedger(ledgerPath: string): Promise<LedgerEntry[]> {
      if (!existsSync(ledgerPath)) return [];
      const raw = await readFile(ledgerPath, 'utf8');
      return raw
        .trim()
        .split('\n')
        .filter(Boolean)
        .map((line) => JSON.parse(line) as LedgerEntry);
    }
  • src/index.ts:49-50 (registration)
    Top-level wiring: registerLedgerTools is called with the server and ledgerManager, connecting the tool to the MCP server.
    registerCodeSearchTools(server, codeSearchManager, REPO_DIR);
    registerLedgerTools(server, ledgerManager);
Behavior2/5

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

No annotations are provided, and the description only says 'get all logged changes,' implying a read operation but not explicitly stating it is safe, non-destructive, or any other behavioral traits like required permissions or rate limits. The description carries the full burden but provides minimal transparency.

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?

The description is extremely concise—two sentences—with no redundant or filler content. Every word serves a purpose: the first sentence states the function, the second provides a usage context.

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?

Given the tool's simplicity (one parameter, no output schema), the description covers the essential purpose and a key usage scenario. It could optionally mention return order or pagination, but it is largely complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'specific file path' but adds no extra constraints (e.g., path format, absolute vs. relative, valid characters) beyond the schema's simple string type and minLength. This is insufficient for full parameter understanding.

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 clearly states the action ('get'), the resource ('all logged changes'), and the scope ('touched a specific file path'). It effectively distinguishes from siblings like 'get_all_changes' and 'get_changed_files' by specifying file-path filtering.

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?

The second sentence provides a clear use case: 'Use to understand the change history of a file before modifying it.' While it doesn't explicitly state when not to use or list alternatives, the context implies it is for pre-modification review.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/2loch-ness6/mempalace-mcp-dev'

If you have feedback or need assistance with the MCP directory API, please join our Discord server