Un registro de clases anti-alucinaciones para agentes de codificación, servido a través de MCP.
Los agentes de codificación adivinan las firmas de los constructores de memoria — una palabra clave que no existe, un argumento obligatorio omitido — y pagas por la suposición con un TypeError y un viaje de ida y vuelta de depuración. registree elimina la suposición: recorre tu código con ast (nunca importa), construye un registro de cada definición de clase y lo sirve como herramientas MCP para que el agente pueda verificar la firma antes de escribir la llamada.
Dos principios atraviesan todas las herramientas:
Los nombres se asignan a listas. Un nombre de clase duplicado devuelve todas las definiciones; el servidor nunca elige silenciosamente la primera coincidencia.
Honestidad sobre confianza. Un constructor abierto (**kwargs, extra=/alias= de Pydantic) informa su contrato como incognoscible, nunca como una lista vacía que pretende ser una respuesta.
Escaneo — un recorrido AST sobre tu árbol de fuentes extrae cada clase: parámetros del constructor (incluyendo **kwargs y solo posicionales), campos tipados con valores predeterminados, herencia, docstrings. La clasificación es transitiva: un modelo enrutado a través de la clase base de tu propio proyecto sigue siendo reconocido como un modelo Pydantic.
Servir — el registro se almacena en caché como JSON y se expone a través de MCP stdio. Se mantiene solo: se genera en el primer uso, se regenera cuando un archivo escaneado es más nuevo que la caché.
Responder — el agente lo consulta en el momento de uso, en lugar de adivinar.
Related MCP server: codegraph-mcp
herramienta | úsala |
| antes de escribir una llamada al constructor — argumentos obligatorios, palabras clave aceptadas, cada definición de un nombre duplicado |
| después de redactar código — comprueba las llamadas al constructor contra el registro |
| cuando no estés seguro del nombre exacto de la clase |
| qué nombres necesitan una importación explícita para desambiguar |
| antes de un renombrado — cada uso, incluso a través de alias de importación ( |
| estado del servidor y tamaño del registro |
No se necesita instalación con uv — los clientes MCP lo lanzan con uvx. Para uso directo desde CLI:
uv tool install registree # or: pip install registreeRequiere Python 3.12+.
Cualquier cliente MCP, formato de configuración JSON:
{
"mcpServers": {
"registree": {
"command": "uvx",
"args": ["registree", "serve", "--root", "/path/to/your/project"]
}
}
}Omitir --root sirve el directorio en el que el cliente lanza el servidor, que para la mayoría de los clientes MCP es la raíz del proyecto.
Inicio rápido (cualquier agente): docs/quickstart.md
Configuración de Claude Code, incluida la integración de hooks: docs/claude-code.md
Las herramientas MCP funcionan con cualquier cliente MCP — Claude Code, Claude Desktop, Cursor, Windsurf, Cline, Zed, modo agente de VS Code Copilot, Gemini CLI y cualquier otra cosa que hable MCP sobre stdio. La salida estructurada de las herramientas se degrada con elegancia para clientes que solo leen contenido de texto.
Los adaptadores de hooks (hook-check, hook-regen) se dirigen al protocolo de hooks de Claude Code, que puede interceptar una edición de archivo pendiente y dar al modelo comentarios de asesoramiento antes de que se aplique la escritura — un punto de control determinista que la capa MCP por sí sola no puede proporcionar. Ver docs/claude-code.md.
Ese protocolo se está extendiendo: el modo agente de VS Code Copilot (Vista previa) lee el mismo formato — mismos eventos, mismo JSON de stdin, incluso .claude/settings.json — y los adaptadores toleran sus nombres de campo en camelCase. Codex CLI y Gemini CLI usan contratos de hooks lo suficientemente cercanos como para que los puertos sean sencillos. Los agentes cuyos sistemas de hooks no pueden interceptar ediciones de archivos antes de su aplicación (Cursor, Windsurf sin comentarios del modelo, Zed sin hooks todavía) aún obtienen el conjunto completo de herramientas MCP — los hooks solo añaden una capa determinista donde la plataforma la soporta.
El mismo motor está disponible directamente:
registree gen # build the registry
registree conflicts # duplicate names: accepted layering vs smells
registree usages SomeClass # every usage, alias-aware — run before renames
registree hook-check # Claude Code PreToolUse adapter (advisory)
registree hook-regen # Claude Code PostToolUse adapter (debounced)registree conflicts sale con código distinto de cero solo para nombres duplicados que son olores genuinos — el par aceptado de capas ORM/dominio pasa — por lo que es seguro conectarlo a CI desde el primer día.
Vive en .registree/registry.json por defecto — añade .registree/ a tu .gitignore. Cada comando que lo toca acepta --registry-path para ponerlo en cualquier otro lugar; las rutas relativas se anclan a la raíz del proyecto.
uv sync # creates .venv, installs deps + dev tools
uv run pytest # includes a real stdio JSON-RPC handshake test
uv run mypy src tests
uv run ruff check .
uv run black --check .Ejecuta el servidor directamente (habla MCP sobre stdio; sale al recibir EOF):
uv run registreeConstructor contract AND callable surface for a class — EVERY
definition if the name is duplicated. Call this before writing an
instantiation or a method call: it reports the required arguments, the
accepted keywords, honest null when a constructor is open-ended or
unknowable, and the class's methods (inherited included, each with its
kind and defining class) so a method name can be verified rather than
guessed. When methods_complete is false an ancestor was unresolvable,
so a listed method exists but an unlisted one still might.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| found | Yes | |
| ambiguous | Yes | |
| class_name | Yes | |
| definitions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses important behavioral details: duplicate definitions are all returned, null is returned only in specific constructor cases, inherited methods are included with kind and defining class, and the methods_complete=false caveat about unresolvable ancestors is explicitly explained.
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?
The description is dense but information-rich, front-loading the core purpose and then detailing edge cases and caveats. It is slightly verbose and uses informal phrasing like 'honest null' and 'EVERY definition,' but every sentence adds meaningful behavioral information.
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?
The description covers the tool's output surface, when to use it, duplicate-name behavior, and the methods_complete caveat, and an output schema is present. It does not address error cases or class_name resolution format, but for a single-parameter introspective tool it is largely sufficient.
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?
The schema has only one parameter, class_name, with no parameter description, and the description does not explicitly document the expected format (e.g., fully qualified vs. simple name, case sensitivity). It does add some meaning by noting that duplicate names return every definition, but it leaves format and resolution details implicit.
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 description names a specific resource ('a class') and a precise result: the constructor contract and callable surface, including required arguments, accepted keywords, methods, and inherited methods. It clearly distinguishes get_signature from siblings like search_classes, list_duplicates, verify_snippet, and get_usages by what it returns and when it is meant to be called.
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?
The description gives explicit guidance: 'Call this before writing an instantiation or a method call.' It conveys the intended use context clearly but does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every place a class name is used — imports, inheritance,
instantiations, annotations, references — including usages through import
aliases (from pkg.db.models import X as XDB). Run this BEFORE a
rename to enumerate what must change.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| class_name | Yes | ||
| include_tests | No |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| total | Yes | |
| usages | Yes | |
| aliases | Yes | |
| truncated | Yes | |
| class_name | Yes | |
| files_affected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool includes usages through import aliases and that it should be run before a rename, which implies it is a read-only operation. However, it does not mention pagination or the limit parameter's behavior, which is a minor gap.
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?
The description is concise, front-loaded with the core purpose, and every sentence adds value. It uses a clear example of import aliases and a practical instruction (run before rename) without unnecessary fluff.
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?
Given the tool's complexity (3 parameters, output schema present), the description covers the main use case and provides actionable guidance. It lacks details on limit and include_tests, but the output schema likely clarifies return values. The description is sufficient for an agent to select and invoke the tool correctly.
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 description coverage is 0%, so the description must compensate. It explains the class_name parameter implicitly by describing what usages are found, but it does not explain the limit or include_tests parameters. The description adds some context for class_name but leaves the other two parameters undocumented.
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 description clearly states the tool's purpose: to find every place a class name is used, listing specific usage types (imports, inheritance, instantiations, annotations, references) and including import aliases. It distinguishes itself from siblings by focusing on usages rather than searching or listing classes.
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?
The description explicitly instructs to run this tool BEFORE a rename to enumerate what must change, providing clear when-to-use guidance. It also implies when not to use it (e.g., for searching classes, which is handled by search_classes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate class names, split into accepted layered pairs (ORM model + domain model sharing a name across layers) and genuine smells. Names listed here always need an explicit import to disambiguate.
| Name | Required | Description | Default |
|---|---|---|---|
| smells_only | No |
| Name | Required | Description |
|---|---|---|
| smells | Yes | |
| layered | Yes | |
| alias_convention | Yes | |
| total_duplicate_names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the responsibility for behavioral transparency. The description explains the classification outcome (accepted layered pairs vs genuine smells) and the consequence (explicit import needed). It does not disclose details like return format or whether it filters based on the 'smells_only' parameter beyond what the schema implies, but the behavior is reasonably described.
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?
The description is two sentences, concise and front-loaded with the core purpose. It includes necessary context (accepted layered pairs definition) and consequence (explicit import). No wasted words.
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?
The tool is relatively simple with one optional parameter, and the description covers the purpose and outcome. An output schema exists, so the description does not need to explain return details. The main gap is the lack of explanation for the 'smells_only' parameter, but overall it is adequate for its complexity.
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?
The schema has one parameter, 'smells_only' with a default of false. Schema description coverage is 0%, so the description must compensate. The description does not explain the parameter's effect (e.g., filtering results to only genuine smells). The baseline is 3 given the single parameter with default, but the description adds little about its semantics.
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 description clearly states the tool's purpose: listing duplicate class names and distinguishing between accepted layered pairs and genuine smells. It also explains the implication (explicit import needed). Distinguished from siblings because it focuses on duplicates, while siblings like search_classes or get_usages serve different functions, but does not explicitly name alternatives.
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?
The description implies when to use this tool: when checking for duplicate class names and needing to know which duplicates are acceptable vs smells. It provides the criterion for accepted layered pairs (ORM model + domain model sharing a name across layers). It doesn't explicitly state when not to use it, but the purpose is clear enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find classes by name fragment (case-insensitive), falling back to fuzzy matching when nothing contains the fragment. Use this when unsure of the exact class name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| query | Yes | |
| truncated | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavior burden. It discloses case-insensitivity and the fuzzy-match fallback, which are non-obvious and valuable. It does not mention result ordering or empty-result behavior, but the presence of an output schema likely covers return structure. It adds meaningful behavioral insight beyond the bare schema.
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?
Two tightly packed sentences. The first front-loads the primary action and key behaviors (case-insensitive, fuzzy fallback), and the second gives usage guidance. No filler or redundant phrasing.
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 straightforward search tool with an output schema present and only two params, the description is nearly sufficient. It explains the search behavior and primary use caseable gaps: it doesn't mention behavior when no results match beyond the fallback, or any limit semantics. These are minor for a search tool.
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 description coverage is 0%, so the description must compensate. It implies 'query' is a name fragment via 'Find classes by name fragment', giving some meaning to that parameteraine, but it never mentions the 'limit' parameter or its semantics. The description covers only one of two parameters, leaving the other undocumented.
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 description clearly states the verb (Find), the resource (classes), and the search mechanism (name fragment, case-insensitive). It also distinguishes itself from siblings by framing the operation as a fuzzy search fallback, which an agent can immediately differentiate from listing or other operations.
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 provides explicit when-to-use guidance: 'Use this when unsure of the exact class name.' However, it does not explicitly name alternatives or state when NOT to use it. This leaves exclusion logic to the agent's judgment, preventing a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report server status, the project it serves, and registry size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| root | Yes | |
| status | Yes | |
| version | Yes | |
| registry_classes | Yes | |
| registry_generated_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full transparency burden. 'Report' implies a read-only, non-mutating behavior, which is helpful, but it does not specify whether it hits a live endpoint, any error semantics, or output shape. It is not misleading, but it is minimal.
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?
A single sentence with a front-loaded verb and concise object list. There is no filler, and all three reported elements are enumerated efficiently.
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?
Given zero parameters, the presence of an output schema, and the high-level nature of the report, the description is fully adequate for an agent to select and invoke this tool. It covers the main informational content, and no missing detail would confuse a capable agent.
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?
The input schema has zero properties, so the description does not need to explain parameters. It profitably defines what the tool reports (status, project, registry size) and thereby gives the agent meaningful context beyond the empty schema.
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 description states a clear verb ('Report') with a concrete resource ('server') and specifies the exact output categories: status, project, and registry size. This distinguishes it unambiguously from the code-focused sibling tools such as get_signatures or list_duplicates.
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?
The intended use is implied—call this when you need server status, the associated project, or registry size—but no explicit guidance is given about when to prefer it over alternatives or what action it might precede. There are no usage conditions, exclusions, or context cues beyond the obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a draft snippet's constructor calls against the registry before writing it to a file. Pass the intended file_path when known — imports in the snippet and the target location both help disambiguate duplicated names.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| file_path | No |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| note | Yes | |
| error | Yes | |
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It describes a 'check' but does not explicitly state whether it is read-only (no side effects), what happens on success/failure, or if any state is modified. The note about disambiguation is useful, but the lack of explicit side-effect or return behavior leaves room for assumptions.
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?
The description is concise and front-loaded, with only two sentences. The first sentence states the purpose and timing, and the second adds a key parameter hint. No redundant or unnecessary words.
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?
Given the tool's moderate complexity (2 parameters, 0% schema coverage), the description adequately explains the main purpose, the file_path parameter's purpose and when to use it, and the context (before writing). It does not describe the return value, but an output schema exists, so that is presumably covered there. The description is sufficient for an AI agent to understand when and how to invoke it.
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 0%, and the description adds meaning to the 'file_path' parameter by explaining its role in disambiguation. However, it does not clarify the 'code' parameter beyond context (it is inferred as the snippet content). The description compensates partially but not fully for the lack of schema descriptions.
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 description clearly states the tool's function: verifying a draft snippet's constructor calls against a registry before writing to a file. It uses a specific verb ('check') and a specific resource ('draft snippet's constructor calls against the registry'). It distinguishes from sibling tools (e.g., get_signature, list_duplicates) by focusing on validation pre-write, though the term 'check' could be more explicit about the action's outcome.
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?
The description provides usage context by saying 'before writing it to a file' and instructs to pass the file_path when known, explaining that imports and target location disambiguate duplicates. However, it does not explicitly mention when not to use this tool or compare it to alternatives, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0get_signature4 fields changedOutput schema / $defs / Definition / properties / methodsAdded value: +{
+ "items": {
+ "$ref": "#/$defs/MethodSummary"
+ },
+ "title": "Methods",
+ "type": "array"
+}Output schema / $defs / Definition / properties / methods_completeAdded value: +{
+ "title": "Methods Complete",
+ "type": "boolean"
+}Output schema / $defs / Definition / requiredPrevious value: -[
- "file_path",
- "line_number",
- "type",
- "module",
- "file_type",
- "parent_classes",
- "summary",
- "init_signature",
- "fields",
- "required_arguments",
- "accepted_keywords"
-]New value: +[
+ "file_path",
+ "line_number",
+ "type",
+ "module",
+ "file_type",
+ "parent_classes",
+ "summary",
+ "init_signature",
+ "fields",
+ "methods",
+ "methods_complete",
+ "required_arguments",
+ "accepted_keywords"
+]Output schema / $defs / MethodSummaryAdded value: +{
+ "properties": {
+ "accepts_kwargs": {
+ "title": "Accepts Kwargs",
+ "type": "boolean"
+ },
+ "defined_in": {
+ "title": "Defined In",
+ "type": "string"
+ },
+ "is_async": {
+ "title": "Is Async",
+ "type": "boolean"
+ },
+ "kind": {
+ "title": "Kind",
+ "type": "string"
+ },
+ "name": {
+ "title": "Name",
+ "type": "string"
+ },
+ "returns": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Returns"
+ },
+ "signature": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Signature"
+ }
+ },
+ "required": [
+ "name",
+ "signature",
+ "kind",
+ "is_async",
+ "accepts_kwargs",
+ "returns",
+ "defined_in"
+ ],
+ "title": "MethodSummary",
+ "type": "object"
+}v0.1.0get_signatureget_usageslist_duplicatessearch_classesserver_infoverify_snippetScored across 6 tools
Each tool targets a clearly distinct concern: server status, class signature lookup, snippet validation, usage enumeration, name search, and duplicate reporting. Even the two validation-adjacent tools differ in scope (single class vs. full snippet), so an agent can reliably pick the right one.
Most tool names follow a clear verb_noun pattern: get_signature, get_usages, search_classes, list_duplicates, verify_snippet. The single outlier is server_info, which lacks a verb and would fit better as get_server_info, but the overall convention is still consistent enough to be predictable.
Six tools is a well-scoped set for a read-only code intelligence registry. Each tool covers a necessary mode of interaction without redundancy or bloat.
The tool surface covers the full workflow: discover classes, resolve duplicates, inspect signatures, validate snippets, and enumerate usages before refactoring. There are no obvious dead ends or missing operations for the stated purpose.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Serves your design system and coding standards to coding agents, so they stop guessing.
