Skip to main content
Glama
alessandro-afloarei

ShadowGit MCP Server

Read docs pages

get_docs
Read-onlyIdempotent

Read AI-written documentation pages for a tracked project, including area facts, current wording, and changes since each snapshot, to decide what to update before writing with write_docs.

Instructions

Read the docs pages ShadowGit keeps for a tracked project: one per area of its map, plus an Overview, each written by an AI assistant. A page comes with the facts ShadowGit draws from the map (folder, sizes, layers, what it depends on and what depends on it, processes, its most depended-on symbols, the project's rules that name it), its words so far with who wrote them and at which snapshot, and what changed in the area since them: symbols changed in their code, dependency facts, links that no longer name anything. With no arguments: the pages the latest AI session changed whose words are missing or behind. With areas, and overview: those pages. With all: pages without words, largest area first, five at a time, with more for the following batch. Answers head, the snapshot write_docs keeps the words at, and next: write the pages' words with write_docs. Needs the ShadowGit app running.

Input Schema

NameRequiredDescriptionDefault
allNoPages without words, five at a time
moreNoThe more get_docs answered with all, as given: the following batch
repoNoProject name or absolute path. Defaults to the current project.
areasNoArea ids, as get_docs names them: most are the area's folder, as get_map lists it
overviewNoThe Overview page, alone or with areas

Output Schema

NameRequiredDescriptionDefault
headYesThe newest snapshot, which write_docs keeps the words at
moreYesFor all: the following batch, to pass back as more; null at the last
nextNoThe step that follows: write these pages with write_docs
repoYes
pagesYes
limitsYes
mapAsOfYesThe snapshot the answer is drawn from

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.6.1

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, it discloses what is returned (map facts, words with authors and snapshots, changes since then), the default no-argument behavior, the all-mode batch size and ordering, and the requirement that the ShadowGit app be running. This is substantial behavioral context that annotations alone do not provide.

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?

The purpose is front-loaded and the description avoids filler, but it is a dense single paragraph with telegraphic clauses and an awkward final sentence about head and next. It remains compact for a five-parameter tool with branching modes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema and rich annotations, the description still covers the important context: return contents, default behavior, batching, the write_docs follow-up, and the app-running prerequisite. Nothing material for correct invocation is missing.

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 adds meaning about how parameters combine: no arguments has a default behavior, areas and overview select specific pages, all triggers largest-area-first batches of five, and more continues the following batch. That goes beyond the schema's parameter descriptions.

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 opens with a specific verb and resource: read the docs pages ShadowGit keeps for a tracked project. It explains the page structure (one per map area plus an Overview) and distinguishes the read operation from write_docs, so an agent can identify it without opening the schema.

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 explicit invocation modes: no arguments returns pages the latest AI session changed with missing or stale words, areas/overview selects those pages, and all batches pages without words. It also points to write_docs for the follow-up write action. The only gap is that it does not explicitly contrast with get_map or other read siblings.

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