RepoGrammar
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| repogrammar_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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.