What can you do with this server?

This is a read-only MCP server for cross-stack impact analysis, tracing how changes in a Java (Spring Boot) backend ripple through an OpenAPI contract into a TypeScript frontend. * Index your project (index_project): Build or refresh a SQLite-backed index by parsing Java, TypeScript, and OpenAPI artifacts into a unified symbol graph. * Find symbols (find_symbol): Locate any class, method, field, enum, or endpoint by name and optionally kind, returning file and line information. * Find references (find_references): Retrieve intra-language references to a given symbol, showing where it is used within a single language layer. * Get endpoint details (get_endpoint): Look up an API endpoint to see how it maps across the Java controller, OpenAPI operation, and related DTO schema. * Analyze cross-stack impact (analyze_impact): Compute the full blast radius of a symbol — tracing it from Java through OpenAPI into TypeScript call sites, with confidence flags (high for type-resolved hits, heuristic for URL-matched calls) and a migration checklist. * Get Git context (get_git_context): Fetch recent commit history, authors, and blame summaries for a file or symbol to understand ownership and change history. * Explain a symbol (explain_symbol): Get an aggregated summary combining a symbol's definition, references, endpoint mapping, and Git context in one unified view.

Which integrations are available for this server?

Analyzes Java Spring Boot backend code, including enums, DTOs, JPA entities, and endpoints, to trace impact across the stack. Parses OpenAPI/Swagger specifications to link Java DTO fields to API schemas, enabling impact propagation from backend to frontend. Analyzes TypeScript frontend code to identify callers and heuristically match fetch/axios calls for cross-stack impact analysis.

How do I use javats-impact-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@javats-impact-mcp What would break if I rename OrderStatus.PENDING?" 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.

javats-impact-mcp

by thanhphuong080199

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

javats-impact-mcp

Demo: cross-stack blast radius from a single symbol

Read-only MCP server for cross-stack impact analysis across a Java (Spring Boot) backend and a TypeScript frontend, linked through OpenAPI.

The one-question demo: "If I rename an enum value, what breaks?"

OrderStatus.PENDING is a Java enum value. It is stored in the DB (orders.status, @Enumerated(STRING)), exposed on OrderDto.status in the OpenAPI spec, returned by GET /api/orders, and consumed by the frontend two ways.

find_symbol { name: "OrderStatus", kind: "enum" }      -> symbol_id
analyze_impact { symbol_id }

Returns (abridged):

{
  "endpoints": [{ "path": "/api/orders", "method": "GET" }],
  "tsCallers": [
    { "kind": "client_call", "file": ".../OrdersPage.tsx", "confidence": "high" },
    { "kind": "fetch_call",  "file": ".../rawFetchOrders.ts", "confidence": "heuristic" }
  ],
  "jpa": { "table": "orders", "column": "status", "enumerated": "EnumType.STRING" },
  "migration_checklist": [ "...", "Review 1 heuristic TS site (raw fetch URL match — verify manually)." ]
}

Related MCP server: OpenAPI Sync MCP

How it works

index_project builds a SQLite index with three indexers:
- Java (tree-sitter): classes, enums, fields, methods, annotations, scoped references.
- TypeScript (ts-morph): type-aware symbols, property accesses, fetch/axios call sites.
- OpenAPI (swagger-parser): endpoints, schemas, and maps_to edges bridging Java DTO fields to schema fields.
The 7 read-only tools query that index. analyze_impact walks Java → OpenAPI → TypeScript.

Tools (exactly 7, all read-only)

index_project, find_symbol, find_references, get_endpoint, analyze_impact, get_git_context, explain_symbol.

Configuration

javats-mcp.config.json (paths resolve relative to the file):

{ "backendPath": "...", "frontendPath": "...", "openApiSource": "./openapi.json",
  "generatedClientPath": "...", "indexPath": ".javats-mcp/index.db", "allowNetwork": false }

Register in Claude Desktop / Cursor

{
  "mcpServers": {
    "javats-impact": {
      "command": "node",
      "args": ["/absolute/path/to/dist/index.js"],
      "env": { "JAVATS_CONFIG": "/absolute/path/to/javats-mcp.config.json" }
    }
  }
}

Run npm run build first. For development, use command: "npx", args: ["tsx", "/abs/src/index.ts"].

Limitations / confidence model

high — resolved through the TypeScript type system (ts-morph) or a generated-client method reference. Renames provably affect these sites.
heuristic — matched by URL/path string against fetch/axios. Can miss dynamic URLs (template concatenation) and can over-match similar paths. Always verify these manually.
Java analysis is syntactic (tree-sitter), scoped by simple type name — it does not do full type resolution, so same-named types in different packages may conflate.
OpenAPI linking assumes springdoc-style schema names match Java DTO class names.
Read-only: no writes, no shell exec except git log/blame. Network off unless allowNetwork.

Requirements & no native builds

Requires Node 22+ (the index store uses the built-in node:sqlite). There are no native modules: Java parsing uses web-tree-sitter (WASM runtime) with prebuilt grammars from tree-sitter-wasms, and storage uses node:sqlite. npm install needs no C++ compiler on any platform. (node:sqlite is currently a stable-but-experimental Node API and prints a one-time notice on stderr at startup; it does not affect the MCP stdio protocol.)

Available Tools

7 tools

analyze_impactC

Cross-stack blast radius for a symbol, with confidence flags.

ParametersJSON Schema

Name	Required	Description	Default
`symbol_id`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

The description mentions 'confidence flags' but does not elaborate on what they indicate. There is no information about idempotency, side effects, performance, or authentication needs. Since no annotations are provided, the description carries the full burden of behavioral disclosure, which it fails to meet.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one noun phrase), which is concise but not a complete sentence. It lacks structure and does not use front-loading effectively. It could be more informative while staying brief.

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

Completeness2/5

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

With no output schema, the description should explain what the tool returns, but it only vaguely mentions 'confidence flags'. The tool name suggests analysis, but essential details like context dependencies or return format are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for parameters. The description mentions 'symbol' but does not clarify what symbol_id represents (e.g., a numeric ID, file path, or expression). No additional meaning is added beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Cross-stack blast radius for a symbol, with confidence flags' indicates the tool analyzes the impact of a symbol across stacks, which is distinct from siblings like find_references (locates usages) or explain_symbol (provides explanation). However, it lacks a clear verb and could be more precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as find_references or get_endpoint. The description does not mention prerequisites, limitations, or preferred scenarios.

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

explain_symbolC

Aggregate definition + refs + endpoint + git into one summary.

ParametersJSON Schema

Name	Required	Description	Default
`symbol_id`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It states it aggregates data but does not clarify if it's read-only, requires specific permissions, or any side effects. A read operation is implied but not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, which is efficient, but it sacrifices necessary detail. It front-loads the key idea but does not provide enough information to be fully actionable.

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

Completeness2/5

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

Given the tool's complexity (aggregating multiple data sources) and absence of output schema or parameter descriptions, the description is incomplete. It lacks details about the returned summary format, prerequisites, or potential errors.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one required parameter 'symbol_id' with no description. Schema description coverage is 0%, and the description adds no meaning about what the parameter represents (e.g., a numerical identifier). This is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it aggregates multiple aspects (definition, refs, endpoint, git) into a summary. The verb 'aggregate' is specific, but it doesn't fully differentiate from using multiple sibling tools separately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like find_symbol, find_references, etc. It implies usage when a comprehensive summary is needed, but lacks when-not or exclusion criteria.

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

find_referencesC

Intra-language references to a symbol.

ParametersJSON Schema

Name	Required	Description	Default
`symbol_id`	Yes

TDQS

C2.1/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It reveals the scope (intra-language) but omits whether the operation is read-only, what happens on failure, or output format. No behavioral details beyond scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (5 words) but sacrifices clarity. It is not a complete sentence and lacks structure. The phrase earns its place but is insufficiently informative.

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

Completeness2/5

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

With one parameter and no output schema, the description should at least specify what references are returned (e.g., locations, callers). The current text leaves the agent guessing about the result format and completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds no meaning about the sole parameter symbol_id. The schema defines type and required status, but the description does not explain what symbol_id represents or how to obtain it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Intra-language references to a symbol' indicates the tool retrieves references within the same language. It goes beyond a tautology but lacks a verb and does not explicitly state the action of finding.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus siblings like find_symbol or analyze_impact. The description does not mention context, prerequisites, or exclusions.

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

find_symbolA

Locate a class/method/field/enum/endpoint by name (file:line).

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No
`name`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It indicates the tool returns file:line location, suggesting a read-only operation. However, it does not disclose whether indexing is required or if the search is global.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, front-loaded sentence with no extraneous words. Every part contributes to understanding the tool's action.

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

Completeness3/5

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

No output schema, but description gives output format. It lacks information on prerequisites, error conditions, or result structure. Adequate for a simple tool, but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. The description only mentions 'by name' and lists symbol types, but the 'kind' parameter is left unexplained. It adds minimal value beyond the schema.

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 clearly states the tool's purpose: locating symbols (class, method, field, enum, endpoint) by name, with file:line output. It distinguishes from siblings like find_references and analyze_impact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (when you need to find a symbol's definition) but provides no explicit guidance on when to use alternatives or exclusions. It does not mention other tools.

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

get_endpointD

Java endpoint <-> OpenAPI operation <-> DTO schema.

ParametersJSON Schema

Name	Required	Description	Default
`pathOrMethod`	Yes

TDQS

D1.5/5.0

Behavior1/5

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

With no annotations provided, the description carries full burden but gives zero behavioral information. No mention of side effects, auth requirements, rate limits, or return behavior. The description is completely opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise but under-informative. The three-word phrase does not earn its place as it fails to convey actionable information. Conciseness should not sacrifice clarity.

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

Completeness1/5

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

Given no output schema and minimal parameters, the description should explain what the tool returns and its context. It is entirely incomplete, leaving the agent without sufficient information to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'pathOrMethod' has no description in the schema (0% coverage) and the tool description does not explain its purpose or format. No additional meaning is added beyond the type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description mentions Java endpoints, OpenAPI operations, and DTO schemas but does not specify a verb or clear action. It is ambiguous whether the tool retrieves, maps, or creates these items. No differentiation from siblings like analyze_impact or find_references.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not provide context or exclusions, leaving the agent to infer usage from the name alone.

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

get_git_contextC

Recent authors, commits, and blame summary for a file or symbol.

ParametersJSON Schema

Name	Required	Description	Default
`fileOrSymbol`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'recent' but does not define the recency window, nor does it describe side effects, error conditions (e.g., file not found), or authentication requirements. The agent has insufficient behavioral context for safe invocation.

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 description is a single concise sentence with no fluff. However, it could be restructured to front-load critical information (e.g., return type) without losing brevity. A score of 4 reflects efficient use of words but room for structural improvement.

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

Completeness2/5

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

Despite low complexity (one parameter, no output schema, no nested objects), the description is incomplete. It does not specify the return format (e.g., structured list, summary object), pagination behavior, or how to interpret 'recent'. The agent lacks enough information to use results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for parameters. The description adds 'file or symbol' to explain the parameter's semantic type, but it does not clarify format (e.g., full path vs relative, symbol naming convention). For a single parameter, more elaboration is expected to ensure correct input.

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 clearly states that the tool returns 'Recent authors, commits, and blame summary for a file or symbol', specifying the verb (retrieve), resource (git context), and input (file or symbol). This unambiguously distinguishes it from sibling tools like find_symbol or analyze_impact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, conditions, or exclude scenarios (e.g., when a file is not in a git repository). The agent must infer usage from the name alone.

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

index_projectC

Build/refresh the cross-stack index. Returns counts.

ParametersJSON Schema

Name	Required	Description	Default
`paths`	No

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'Build/refresh' implying mutation, but does not disclose side effects, destructiveness, authentication requirements, or rate limits. It is insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise and front-loaded. However, it is under-specified and lacks essential details, so it is not optimally balanced between brevity and completeness.

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

Completeness2/5

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

Given the tool has 1 optional parameter, no output schema, and no annotations, the description should provide more context about what the index is, what 'paths' represent, what 'counts' are returned, and how to use the tool. It is incomplete for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% descriptor coverage for the only parameter 'paths'. The description does not mention 'paths' or provide any meaning beyond the schema. Therefore, it adds no value to parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb 'Build/refresh' and the resource 'cross-stack index', and mentions return value 'counts'. It clearly indicates the tool's primary action, but the term 'cross-stack index' is somewhat vague and could be more specific. It does not differentiate from sibling tools, but the function appears distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it. The description merely states the action without any usage context.

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.

7 tool updatesv0.1.0Jul 28, 2026
- First observedanalyze_impact
- First observedexplain_symbol
- First observedfind_references
- First observedfind_symbol
- First observedget_endpoint
- First observedget_git_context
- First observedindex_project

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-07-28 16:02 across 7 tools

Disambiguation5/5

Each tool targets a distinct aspect: indexing, symbol lookup, reference finding, endpoint details, cross-stack impact, git context, and summary aggregation. No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., find_symbol, get_endpoint), making them predictable and easy to differentiate.

Tool Count5/5

With 7 tools, the set is well-scoped for a code impact analysis domain. Each tool serves a clear role without being too many or too few.

Completeness4/5

The tools cover core workflows: indexing, searching, referencing, endpoint mapping, impact analysis, and git context. Minor gaps exist like direct file content retrieval, but the set is sufficient for its stated purpose.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Meeba Brain A
io.github.meemoprasad
Repository knowledge graph MCP server for codebase understanding and debugging.
Code Analysis Developer Tools
51
Product Management Mcp D
io.github.varvararatta
MCP server for Product Management
Product Management Project Management
2
Swagger MCPOAuth
com.smartbear
MCP server for AI access to Swagger by SmartBear.
API Testing Documentation Access Developer Tools
144
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320

Related MCP Servers

trazabilidad-mcp
Code Analysis Software Architecture
lucadevv
F
license
Not graded
quality
B
maintenance
MCP server that exposes code tracing capabilities including journey flows, HTTP seams, and findings from indexed projects, allowing AI assistants to query software architecture.
Updated 3 months ago (2026-06-10 17:23 UTC)
-
OpenAPI Sync MCP
Developer Tools Code Analysis
jhlee0409
A
license
Not graded
quality
C
maintenance
High-performance MCP server for OpenAPI specifications that parses specs, diffs versions, tracks dependencies, and generates code (TypeScript, Rust, Python).
Updated 7 months ago (2026-01-30 19:32 UTC)
6 npm
2
MIT
RepoMind-MCP
Code Analysis Developer Tools Software Architecture
doridoor
F
license
A
quality
B
maintenance
MCP server for repository mapping, dependency analysis, and architecture diagram generation for JavaScript, TypeScript, and Python projects.
Updated a month ago (2026-08-08 12:54 UTC)
4
7 npm
-
Knossos MCP
Software Architecture Code Analysis
AraneaDev
A
license
Not graded
quality
A
maintenance
Local-first MCP server that scans a repository once and answers architecture questions from an evidence-backed graph, enabling dependency analysis, impact analysis, and codebase exploration without re-reading the source tree.
Updated a day ago (2026-09-13 13:48 UTC)
3
MIT