Skip to main content
Glama

pack

Read-only

Read and search multiple project files in one call: combine regex searches with context, whole-file or partial reads, glob listings, and git status to reduce tool round trips.

Instructions

Read and search the project in ONE call instead of several: a regex search (with the lines around each hit if you ask), any number of files (whole, a line range, or one function), glob listings and git status together. Use it whenever you need 2+ files, or a search plus what it finds. Output is size-capped; .env files and keys are redacted.

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": "pack"
  }
}

Input Schema

NameRequiredDescriptionDefault
rootNoSubdirectory of the workspace to work in (default: the workspace root).
filesNoFiles to read: 'src/app.ts' (whole), 'src/app.ts:10-80' (lines), 'src/app.ts#handleLogin' (one function or class), 'src/app.ts#' (outline).
globsNoGlobs to list, e.g. 'src/**/*.ts'.
queryNoRegex to search the repo for (plain text with literal: true).
contextNoLines of code to show around each search hit (0-30), so the matches need no second read.
literalNoTreat query as plain text.
max_bytesNoInline size cap, 4000-44000; overflow goes to files.
git_statusNoInclude git status.
inline_onlyNoNever spill to files.
max_matchesNoSearch hit cap (default 80, max 300).
allow_secretsNoShow secret files. Only when the user asked.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that: output is size-capped, .env files and keys are redacted by default, and the schema gates secrets behind an explicit user request. It does not describe the shape of the returned bundle, which is the remaining gap.

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?

Two dense sentences, with the capability list first and the decision rule second, followed by the safety/size caveat. Nothing is redundant and the most actionable guidance is front-loaded.

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 an 11-parameter tool with no output schema, the description covers scope, the main usage trigger, size caps, and redaction behavior. It could be complete with a sentence on how the combined results are structured or ordered, which matters for a multi-source aggregator.

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 every one of the 11 parameters is already documented in the schema. The description only restates the file-spec forms ('whole, a line range, or one function') and the context-lines behavior, adding little syntax or default information beyond what the schema provides. The baseline 3 is appropriate.

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 description names specific verbs and resources (regex search, file reads, glob listings, git status) and frames the tool as a single-call aggregator. It is clear what the tool returns, but it never contrasts itself with the sibling tools 'batch' and 'ship', so the agent must infer the boundary from naming alone.

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 gives an explicit trigger condition: 'Use it whenever you need 2+ files, or a search plus what it finds.' That is a clear when-to-use rule, but there is no when-not guidance or mention of alternatives for single-file or single-search cases.

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