This server provides MCP tools to explore and validate Python class definitions and constructor calls in a codebase before an agent writes or refactors code.
get_signature: Get a class's constructor contract (required arguments, accepted keywords, fields, methods, including inherited ones). Duplicated names return every definition; open-ended constructors are reported honestly as unknowable.
verify_snippet: Check a drafted snippet's constructor calls against the registry before writing it, with optional file_path to help disambiguate duplicated names.
search_classes: Find class names by fragment, with case-insensitive and fuzzy fallback, and see definition counts, types, and locations.
list_duplicates: List duplicate class names, split into accepted layered pairs versus genuine smells, and see suggestions/disambiguation guidance.
get_usages: Find every usage of a class — imports, inheritance, instantiations, annotations, references, including via aliases — useful before renames or refactors.
server_info: Check server status, project root, version, registry size, and when the registry was generated.
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., "@registree Verify the UserService constructor signature before I write that call."
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.
An anti-hallucination class registry for coding agents, served over MCP.
Coding agents guess constructor signatures from memory — a keyword that
doesn't exist, a required argument left out — and you pay for the guess in a
TypeError and a debugging round-trip. registree removes the guess: it walks
your codebase with ast (never imports), builds a registry of every class
definition, and serves it as MCP tools so the agent can verify the
signature before writing the call.
Two principles run through every tool:
Names map to lists. A duplicated class name returns every definition; the server never silently picks the first match.
Honesty over confidence. An open-ended constructor (**kwargs,
Pydantic extra=/alias=) reports its contract as unknowable, never as
an empty list pretending to be an answer.
Scan — an AST walk over your source tree extracts every class:
constructor parameters (including **kwargs and positional-only), typed
fields with defaults, inheritance, docstrings. Classification is
transitive: a model routed through your project's own base class is still
recognized as a Pydantic model.
Serve — the registry is cached as JSON and exposed over MCP stdio. It maintains itself: generated on first use, regenerated whenever a scanned file is newer than the cache.
Answer — the agent queries it at the moment of use, instead of guessing.
Related MCP server: oxcode
tool | use it |
| before writing a constructor or method call — required args, accepted keywords, the class's methods (inherited included), every definition of a duplicated name |
| after drafting code — checks constructor calls against the registry |
| when unsure of the exact class name |
| which names need an explicit import to disambiguate |
| before a rename — every usage, including through import aliases ( |
| server status and registry size |
No install needed with uv — MCP clients launch
it with uvx. For direct CLI use:
uv tool install registree # or: pip install registreeRequires Python 3.12+.
Any MCP client, JSON config form:
{
"mcpServers": {
"registree": {
"command": "uvx",
"args": ["registree", "serve", "--root", "/path/to/your/project"]
}
}
}Omitting --root serves the directory the client launches the server in,
which for most MCP clients is the project root.
Quickstart (any agent): docs/quickstart.md
Claude Code setup, including the hook integration: docs/claude-code.md
The MCP tools work with any MCP client — Claude Code, Claude Desktop, Cursor, Windsurf, Cline, Zed, VS Code Copilot agent mode, Gemini CLI, and anything else that speaks MCP over stdio. Structured tool output degrades gracefully for clients that only read text content.
The hook adapters (hook-check, hook-regen) target Claude Code's hook
protocol, which can intercept a pending file edit — or, opt-in, Python
about to be run through a quoted shell heredoc — and hand the model
advisory feedback before it lands, a deterministic checkpoint the MCP
layer alone can't provide. See docs/claude-code.md.
That protocol is spreading: VS Code Copilot agent mode (Preview) reads the
same format — same events, same stdin JSON, even .claude/settings.json —
and the adapters tolerate its camelCase field names. Codex CLI and Gemini
CLI use close-enough hook contracts that ports are straightforward. Agents
whose hook systems can't intercept file edits pre-application (Cursor,
Windsurf without model feedback, Zed with no hooks yet) still get the full
MCP toolset — the hooks just add a deterministic layer where the platform
supports one.
The same engine is available directly:
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 exits non-zero only for duplicate names that are
genuine smells — the accepted ORM/domain layered pair passes — so it is safe
to wire into CI from day one.
Lives at .registree/registry.json by default — add .registree/ to your
.gitignore. Every command that touches it accepts --registry-path to put
it anywhere else; relative paths are anchored to the project root.
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 .Run the server directly (speaks MCP over stdio; exits on 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.
