Skip to main content
Glama

project_map

Generate a directory tree and list supported text files for a local project while respecting gitignore rules and excluding file contents, in markdown or JSON.

Instructions

Directory tree and the list of supported text files, without file contents.

Respects default ignores and .gitignore files. Symlinks are not followed.

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

Input Schema

NameRequiredDescriptionDefault
pathNoLocal project directory. Defaults to the server's working directory.
formatNoOutput format: 'markdown' (default) or 'json' (structured envelope).markdown

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: default ignores are respected, .gitignore files are honored, and symlinks are not followed. It still omits practical limits an explorer tool needs, such as depth/size caps and whether hidden files appear beyond ignore rules.

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?

Three short sentences with no filler; the core scope is front-loaded and the ignore/symlink constraints follow as compact qualifiers.

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?

An output schema exists, so return shape need not be explained, and the description covers the key behavioral rules for a read-only exploration tool. The only real gap is scale/limit behavior (very large repos, depth limits), which is not disclosed anywhere.

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 coverage is 100%, so both path and format are already documented in the schema. The description adds no extra meaning about path resolution beyond 'server's working directory' or about the markdown vs json output choice, so it sits at baseline.

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 the concrete output ('Directory tree and the list of supported text files') and immediately scopes it as 'without file contents', which contrasts cleanly with the content-returning siblings read/read_many. It is specific about the resource and what is excluded, though it states no explicit verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use statement with named alternatives. The phrase 'without file contents' implicitly points to read/read_many for actual content, but the agent must infer that routing rather than being told.

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