RepoGrammar
The server exposes a read-only RepoGrammar MCP tool for retrieving repository convention evidence and readiness information to guide coding agents.
Find analogues: Locate pattern families and examples for a path, symbol, framework role, or pattern question.
Show family: Retrieve details for an exact family id returned by prior queries.
Explain deviation: Compare a target against an inferred or explicitly specified comparison family.
Check conformance: Assess whether a target conforms to a comparison family.
Inspect readiness: Get a bounded, source-free capability/queryability report, optionally scoped by target or directory/module.
Control response density: Use
mode(compact/evidence/deep),verbosity(minimal/standard/full), andtoken_budget.Include optional details: Request exceptions, variations, or line-numbered source spans (source spans are opt-in and off by default).
Support agent workflows: Returns family ids as follow-up handles, read plans, provenance, freshness checks, UNKNOWN reasons, and recovery actions.
Integrates with OpenAI's Codex to deliver source-backed structural facts and bounded read plans.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@RepoGrammarfind context for app/routes.py"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
RepoGrammar
Repository conventions for coding agents.
Documentation · Quickstart · Changelog · Contributing
RepoGrammar indexes repeated implementations in your repository and gives coding
agents a source-backed read plan: examples of how this codebase implements a
route, fixture, model, or data-access role, with the evidence behind each match.
When the evidence is insufficient, it returns UNKNOWN with a recovery action.
It runs locally and exposes a pattern-first CLI and one read-only MCP tool. There are no LLM calls, API keys, embeddings, or cloud services in the analysis path. Python 3.10+ is required for the bundled Python analyzer.
Verified GitHub release baseline: 0.5.0. For current channel versions and their verification, see the publication evidence.

Recorded from a real CLI run on a fixture repository; playback is slowed for readability.
Quick start
Choose an installation route, then initialize your project → connect your agent → verify. Releases that include the one-command bootstrap can combine these steps.
Full Python project setup requires Python 3.10+ within 3.x, Git, Bash,
curl, tar, and gzip. CLI-only installation does not require Python.
Supported platforms are macOS arm64/x86_64, Linux x86_64 with glibc 2.35+, and
Linux arm64 with glibc 2.39+. The native installer does not require Rust, Cargo,
Node.js, Docker, or API keys. The npm launcher requires Node.js 18 or newer.
1. Install the CLI
Choose npm or the pinned native installer below; you do not need both.
npm
npm install -g @sioyooo/repogrammar &&
repogrammar versionThe launcher downloads and verifies the matching native release on first use.
It does not initialize a project or configure an agent. Continue with step 2.
To pin a version, append @<version> to the package name; that version must
have matching GitHub native assets.
Pinned native baseline: 0.5.0
This single block downloads the pinned installer, verifies its checksum, and installs the CLI. It does not alter coding-agent settings or index a repository. For an existing installation, review the update and PATH behavior before rerunning the installer.
(
set -eu
install_tmp="$(mktemp -d)" || exit 1
trap 'rm -rf "$install_tmp"' EXIT
cd "$install_tmp" || exit 1
curl -fsSLO https://github.com/SioYooo/RepoGrammar/releases/download/v0.5.0/install.sh || exit 1
curl -fsSLO https://github.com/SioYooo/RepoGrammar/releases/download/v0.5.0/install.sh.sha256 || exit 1
if command -v sha256sum >/dev/null 2>&1; then
sha256sum -c install.sh.sha256 || exit 1
else
shasum -a 256 -c install.sh.sha256 || exit 1
fi
bash install.sh --version v0.5.0 --install-cli-only --yes
) &&
export PATH="$HOME/.local/bin:$PATH" &&
repogrammar versionAdd the export PATH line to ~/.zshrc or ~/.bashrc once to keep the command
available in new terminals. Expected version: 0.5.0.
2. Index your project
From your project's directory:
repogrammar initinit builds the current project's index and starts background
updates. There is no global repository scanner. Run init once in each project.
The explicit form repogrammar init --project "$PWD" --yes does the same thing;
use --no-autosync for CI or a one-shot index.
3. Connect your coding agent (optional)
repogrammar install --target auto --scope global --yes --no-telemetryRestart the coding-agent session after connecting. Choose a specific client with
--target codex, --target claude-code, or --target opencode.
4. Verify setup
From the initialized project:
command -v repogrammar
repogrammar version
repogrammar statusCheck that the version and command path match the installation you chose.
If the index is unavailable or stale, run repogrammar doctor and follow its
recovery guidance. After
restarting your agent, confirm that repogrammar_context is available in its
MCP tools. Installing the CLI alone does not establish a working agent session.
One-command bootstrap
The 0.5.1 source includes --quickstart: review one plan, authorize it, then install
the CLI, connect detected supported agents, index the selected Git repository,
and start repository-local autosync. No agent is required for CLI/index setup.
After a successful quickstart, go straight to Verify setup;
the separate install, init and agent-connection steps are already handled.
Use an installer and matching binary that include the quickstart-v1 capability;
the pinned 0.5.0 baseline above does not. The
quickstart guide
records availability, verified commands, plan preview, noninteractive execution
and agent selection. The
publication checklist
records the artifact and installation gates for this flow.
I want to… | Guide |
Install, update, or troubleshoot | |
Connect Codex | |
Connect Claude Code | |
Connect opencode | |
See every command | Run |
Understand evidence and limits | |
Remove the installation |
Related MCP server: TokenLighten
When should I index again?
Situation | Action |
First time in a project |
|
Normal edits while autosync is running | Nothing; updates run in the background |
Autosync is stopped, or you want an immediate update |
|
You need a full rebuild, or recovery guidance requests one |
|
You are unsure whether the index is ready |
|
index remains available for compatibility. Use init to start, sync for
ordinary changes, and resync to rebuild. Do not repeatedly run init after
normal edits.
Usage
Find examples for an exact repository location:
repogrammar find "path/to/routes.py:7" --project "$PWD" --mode compact
repogrammar families --project "$PWD"
repogrammar sync --project "$PWD"Start with an exact path or symbol when available. Framework-qualified queries
such as FastAPI route are also supported. See the CLI reference
for the complete commands and the MCP contract
for coding-agent integration.
Background updates
init starts a daemon for that repository. On macOS and Linux, native file
notifications coalesce edits before a sync. Idle native operation reconciles
metadata periodically instead of rescanning the tree every second. Git-ignored
untracked directories are pruned before fingerprint traversal, while tracked
files and ignore exceptions remain visible.
If native watching fails, autosync logs the fallback and polls with bounded
idle backoff. Failed syncs retry with bounded backoff even without another edit.
File notifications are hints; explicit sync and query-time hashes remain the
freshness authority. These changes reduce background work; no battery-life
percentage is claimed.
repogrammar autosync status --project "$PWD"
repogrammar autosync stop --project "$PWD"
repogrammar autosync start --project "$PWD"For CI or one-shot analysis, initialize with --no-autosync. See the
autosync contract for intervals and recovery.
How it works
repository → local index → pattern families → examples + bounded read plan
└──────────→ UNKNOWN + recovery actionRepository conventions: find compatible implementations and their exceptions.
Verifiable context: every result carries provenance and freshness checks.
Incremental updates: native filesystem events wake autosync; changes use the existing incremental indexer. Periodic reconciliation and polling fallback handle unavailable watchers.
Agent integration: connect Codex, Claude Code, or opencode through MCP.
How does it differ from other code tools?
Tool or mechanism | What it contributes | Where RepoGrammar fits |
grep / text search | Exact strings and source locations | Qualifies repeated implementation-family context and the source reads still required |
Semantic search / RAG | Retrieves material relevant to a query; a generation layer may use it | Provides a bounded local evidence contract, without embeddings or generation in its analysis path |
CodeGraph / symbol graphs | Declarations, references, and call paths | Complements graph navigation with family selection, provenance, and abstention |
Static analyzers | Checks under a tool's specified semantic model | Reports bounded convention evidence and static alignment; it is not a sound whole-program analyzer |
These are mechanism comparisons, not benchmark or superiority claims. Static alignment is not proof of runtime equivalence. The FastAPI/pytest fixture walkthrough shows a read plan, optional source spans, and negative cases you can reproduce.
What do UNKNOWN and a bounded read plan mean?
UNKNOWN means the requested claim lacks sufficient qualifying evidence. Its
typed reason and recovery action tell the agent what remains unresolved; it
does not mean the repository is incorrect. PARTIAL_CONTEXT can provide local
metadata without selecting a proven family. A bounded read plan names a limited
set of source locations and remaining reading obligations. Read the required
source before editing; the plan does not replace that obligation. See the
MCP contract
and UNKNOWN policy.
Does repository code leave my machine?
RepoGrammar's analysis runs locally and makes no LLM, embedding, or cloud calls. MCP responses contain metadata by default; source spans require explicit opt-in. The coding agent receiving that response has its own data-handling policy and may send metadata or requested source to its provider. Local analysis is not a privacy guarantee for the entire agent session. Anonymous telemetry is off by default and excludes source and paths; explicit upload is separate. See the telemetry contract for local diagnostics and consent boundaries.
Scope and limitations
The official language focus is Python: FastAPI, pytest, Pydantic, and SQLAlchemy. Other languages have bounded structural or dependency-inventory capabilities; these are not full language support. The strict Top-20 qualification program remains 0/20 complete. Read the language audit for the evidence and unresolved gates.
RepoGrammar is pre-1.0. It is not a sound whole-program analyzer, and neither a syntax match nor a dependency declaration proves behavior. Dynamic dispatch, unsupported frameworks, stale indexes, and incomplete semantics can result in abstention. Read known limitations before relying on a result.
Public binary targets are macOS arm64/x86_64 and glibc Linux arm64/x86_64. Windows and musl Linux are not supported installation targets.
Use ordinary source inspection when a repository has few repeated patterns,
your framework is outside the bounded scope, or an answer remains UNKNOWN.
Use runtime tests or a suitable semantic analyzer when the question requires
behavioral correctness, security assurance, or whole-program proof.
Development
cargo build --locked
cargo test --workspace --all-featuresRead CONTRIBUTING.md and the testing policy for the full checks. Architecture and specifications live in docs/. Report bugs through GitHub Issues; report security issues according to SECURITY.md.
License
MIT.
Available Tools
1 toolrepogrammar_contextA
Read-only RepoGrammar pattern-family context. For find_analogues, explain_deviation, and check_conformance, pass the path, symbol/member id, framework role, or pattern question you have; RepoGrammar discovers candidate families internally and returns family ids as follow-up handles. Use show_family only with an exact family id. Use inspect_readiness (no target) for a bounded, source-free capability report: a summary token, per-dimension states (repository, active index, family evidence freshness, prevalence, retrieval, static alignment, providers, autosync, measurement), the top blocking-unknown mechanisms, and one executable recovery action. Add an optional target and/or within (a directory/module scope) to inspect_readiness for a bounded, source-free SCOPED queryability report over just that scope: a summary token, a resolvability verdict, scoped indexing coverage and file count, languages/providers present, resolvable family count, freshness, and one recovery action — with no source-span hydration and no family-query telemetry. Start with compact mode and do not request include_source_spans by default. Use read_plan before editing, and fall back on UNKNOWN/FALLBACK/stale/omitted/insufficient results. Do not run repogrammar stats in normal agent loops. No silent setup; run setup/resync/autosync only when user or project policy permits machine integration and repo-local analysis state.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| target | No | ||
| within | No | Optional directory/module scope. Consumed only by inspect_readiness to request a bounded, source-free scoped queryability report over that scope. | |
| against | No | Optional comparison-family scope for explain_deviation and check_conformance: an exact family: id, framework role, or pattern that pins the single comparison family. Omitted, the comparison family is inferred from the target unit's membership or its (language, kind, role) key. Ambiguous or unmatched against abstains with candidate handles; it never false-selects. | |
| operation | Yes | ||
| verbosity | No | Response field density. Additive under product-schemas.v1: `standard` (default) is the current shape, `minimal` opts into the lean shape, `full` retains every diagnostic field. Orthogonal to `mode`. | |
| token_budget | No | ||
| include_exceptions | No | ||
| include_variations | No | ||
| include_source_spans | No | Explicit opt-in for bounded, line-numbered, hash-checked source spans selected from the read_plan. Defaults to false. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it discloses a lot: read-only nature, source-free behavior ('no source-span hydration and no family-query telemetry'), abstention semantics ('never false-selects', 'abstains with candidate handles'), fallback handling (UNKNOWN/FALLBACK/stale), and a setup/policy constraint ('run setup/resync/autosync only when user or project policy permits'). It omits latency/rate-limit or cost characteristics and only sketches the response envelope, but behavioral disclosure is well above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a long single block, but front-loaded with purpose and operation routing, and the size is defensible given five operations and ten parameters. Most sentences carry distinct operational content; the only drag is that inspect_readiness detail sits mid-paragraph before the generic defaults, slightly disrupting flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a ten-parameter, five-operation tool with no output schema, the description covers operation behavior and several return shapes (family ids as handles, summary token, per-dimension states, one recovery action), which is genuinely useful. But it leaves verbosity, token_budget, include_exceptions, and include_variations unaddressed and gives only partial guidance on how the modes interact with the responses, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40%, so the description must compensate. It adds real meaning for mode ('Start with compact mode'), target, and within (scoped queryability report), and echoes the abstention behavior of against. However, token_budget, include_exceptions, include_variations, and verbosity are never explained in the description, leaving several parameters documented only by terse schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb+resource ('Read-only RepoGrammar pattern-family context') and the body enumerates the five operations (find_analogues, show_family, explain_deviation, check_conformance, inspect_readiness) with what each returns. An agent can distinguish the operations, though the dense prose makes the overall scope harder to grasp at a glance than a crisp statement would.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing per operation ('For find_analogues, explain_deviation, and check_conformance, pass...', 'Use show_family only with an exact family id', 'Use inspect_readiness (no target) for...'), plus defaults and exclusions ('Start with compact mode', 'do not request include_source_spans by default', 'Do not run repogrammar stats in normal agent loops', 'No silent setup'). When-to-use and when-not are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.5.1- First observed
repogrammar_context
TDQS
Scored across 1 tool
With only one exposed tool there is no cross-tool selection risk, but that single tool internally multiplexes several distinct operations (find_analogues, explain_deviation, check_conformance, show_family, inspect_readiness, read_plan), and the boundary between them is only conveyed through a very dense prose description. An agent must parse a long block to know which mode to invoke and when, which is effectively ambiguity pushed inside one tool.
The single name repogrammar_context is readable and uses a consistent snake_case prefix_noun convention. There is no pattern to violate with only one tool, but the namespace-prefixed form is coherent and predictable for any future additions.
One tool for a surface that describes at least six distinct operations (pattern-family discovery, deviation explanation, conformance checks, family display, readiness/scoped-readiness inspection, change planning) plus setup/resync/autosync behavior is under-factored. The mega-tool approach forces mode dispatch and hidden branching, making the count too thin for the apparent scope.
The read-only analysis domain is partially covered: discovery, explanation, conformance, readiness, and planning are all reachable, and source-hydration is intentionally gated. However setup/resync/autosync are referenced only as behaviors of the same tool rather than distinct operations, and there is no explicit enumeration or listing of family ids beyond follow-up handles, leaving lifecycle steps implicit.
Maintenance
Related MCP Connectors
Repo intel for AI coding agents: overview, PRs, contributors, hot files, CI, deps. Remote MCP.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Code-map tools for AI agents: see a repo's structure first, then edit only what matters.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Related MCP Servers
- AlicenseDqualityDmaintenanceRead-only repository context explorer for coding agents. Provides repository exploration tools via CLI or MCP adapter.1GPL 3.0
- FlicenseNot gradedqualityAmaintenanceLocal-first MCP toolkit that provides coding agents focused repository context via read_file, search_files, and edit_file tools, reducing token usage and task cost.2-

Euthynosofficial
AlicenseNot gradedqualityBmaintenanceA local, read-only MCP server that provides AI coding agents with structural evidence about a repository, including dependency analysis and impact assessment, while naming the boundary of every answer without any LLM calls.21 npmApache 2.0- AlicenseBqualityAmaintenanceEnables coding agents to retrieve token-budgeted, source-hashed code context from explicitly registered local repositories via read-only MCP tools, reducing broad repository crawling while providing structure, symbols, and impact slices.10MIT