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., "@project-explorer-mcp Show me the directory tree of my project"
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.
MCP server toolkit for analyzing the structure of a Python project.
{
"mcpServers": {
"project-explorer": {
"command": "uv",
"args": [
"--directory",
"path/to/project-explorer-mcp",
"run",
"project-explorer-mcp"
]
}
}
}All tools are enabled by default: dir_tree, python_outline, markdown_outline, openapi_list_operations, openapi_get_operation_details
Related MCP server: MCP Codebase Symbols Server
The server can be configured using environment variables with the prefix PROJECT_EXPLORER_MCP__:
PROJECT_EXPLORER_MCP__DEFAULT_OUTPUT_FORMAT: Set the default output format for all tools (json or markdown). Default is markdown.
Example:
export PROJECT_EXPLORER_MCP__DEFAULT_OUTPUT_FORMAT=jsonAll tools support two output formats:
markdown (default): Returns structured markdown text that is more token-efficient for AI models to understand
json: Returns structured JSON data for programmatic processing
You can override the default format per tool call using the output_format parameter.
Description: Returns a file and folder tree with depth limitation.
Parameters:
root_path: str — path to the root of the tree
max_depth: int — maximum traversal depth (default: 1)
output_format: str | None — output format: json or markdown (default: server setting)
Output Example (markdown format):
## Directory Tree: /path/to/project
tests/test_sample.py tests/test_sample.md tests/test_dir_tree.md
Output Example (json format):
{
"root": "/path/to/project/tests",
"tree": [
{
"name": "test_dir_tree.md",
"type": "file"
},
{
"name": "test_sample.md",
"type": "file"
},
{
"name": "test_sample.py",
"type": "file"
}
]
}Description: Returns an outline for each Python file (imports, classes, functions, docstrings).
Parameters:
paths: list[str] — list of paths to Python files
output_format: str | None — output format: json or markdown (default: server setting)
Output Example (markdown format):
## tests/test_sample.py
**Module docstring:**
Module for outline test.
The module contains an example class and function.
### Imports
- `os` (line 3)
- `sys` (line 4)
### Classes
#### `Example` (line 7)
Example class.
**Methods:**
- `method` (line 9)
- Class method.
### Functions
#### `func` (line 15)
Example function.Output Example (json format):
{'tests/test_sample.py': {'docstring': 'Module for outline test.\n\nThe module contains an example class and function.', 'imports': [{'name': 'os', 'line': 3}, {'name': 'sys', 'line': 4}], 'classes': [{'name': 'Example', 'line': 7, 'docstring': 'Example class.', 'methods': [{'name': 'method', 'line': 9, 'docstring': 'Class method.'}]}], 'functions': [{'name': 'func', 'line': 15, 'docstring': 'Example function.'}]}}Description: Returns an outline for each Markdown file (headings, levels, line).
Parameters:
paths: list[str] — list of paths to Markdown files
output_format: str | None — output format: json or markdown (default: server setting)
Output Example (markdown format):
## tests/test_sample.md
### Document Structure
- **H1:** Heading 1 (line 1)
- **H2:** Heading 2 (line 3)
- **H3:** Heading 3 (line 5)
- **H2:** Second H2 (line 9)Output Example (json format):
{'tests/test_sample.md': [{'level': 1, 'text': 'Heading 1', 'line': 1}, {'level': 2, 'text': 'Heading 2', 'line': 3}, {'level': 3, 'text': 'Heading 3', 'line': 5}, {'level': 2, 'text': 'Second H2', 'line': 9}]}Description: Lists all operations from an OpenAPI specification file.
Parameters:
spec_path: str — absolute path to the OpenAPI JSON or YAML file
output_format: str | None — output format: json or markdown (default: server setting)
Output Example (markdown format):
# OpenAPI Operations
| Method | Path | Operation ID | Summary |
| ------ | -------- | ------------ | ----------------- |
| GET | `/users` | listUsers | List all users |
| POST | `/users` | createUser | Create a new user |Output Example (json format):
{
"operations": [
{
"method": "GET",
"path": "/users",
"operation_id": "listUsers",
"summary": "List users"
}
],
"count": 1,
"error": null
}Description: Gets detailed information for specific OpenAPI operations.
Parameters:
spec_path: str — absolute path to the OpenAPI JSON or YAML file
selectors: list[str] — list of selectors (operationId, "METHOD /path", or path)
expand_refs: bool — whether to resolve $ref references (default: false)
format_output: str | None — output format: json or markdown (default: server setting)
Output Example (markdown format):
# OpenAPI Operation Details
## GET /users
**Operation ID:** listUsers
**Summary:** List all users
**Description:**
Get a list of all users
### Responses
#### 200
Successful response
**Content Types:**
- `application/json`: `{'type': 'array', 'items': {'type': 'object'}}`
---Output Example (json format):
{
"details": [
{
"method": "GET",
"path": "/users",
"operation_id": "listUsers",
"summary": "List users",
"description": "Retrieve a list of users",
"parameters": [
{
"name": "limit",
"in": "query",
"required": false,
"schema": {"type": "integer"},
"description": "Maximum number of results"
}
],
"responses": {
"200": {
"description": "Success",
"content": {
"application/json": {"type": "array", "items": {"type": "object"}}
}
}
}
}
],
"count": 1,
"error": null
}Returns a compact file and folder tree with depth limitation.
Agent usage guidelines: - Use this tool when you need to get a quick overview of the file and folder structure of a project or directory. - Use when you need to display or analyze the hierarchy of files and folders up to a certain depth. - Do not use for reading file contents or for non-existent/relative paths.
Path requirements: - The path must not contain URL-encoding (e.g., '%'). - The path must be absolute. - The path must exist on disk. Example paths: - Windows: "C:\Users\User\project" - Linux: "/home/user/project"
Args: root_path (str): Absolute path to the root directory. max_depth (int): Maximum nesting depth. Default is 1. output_format (str | None): Output format ('json' or 'markdown'). Defaults to server setting (markdown by default).
Returns: str | dict: File and folder tree in the requested format or error dict.
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | ||
| root_path | Yes | ||
| output_format | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 explains the depth limitation, output format options, and path requirements (absolute, no URL-encoding, must exist). It also notes that an error dict is returned on failure, which is transparent. However, it doesn't explicitly state that this is a read-only operation with no side effects, though that is implied by the nature of the tool.
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 well-structured with clear sections (description, usage guidelines, path requirements, example paths, args, returns). Each sentence adds value and there is no irrelevant information. It is appropriately sized for a tool with multiple parameters and usage constraints, front-loading the core purpose.
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 (3 params, one required) and the presence of an output schema, the description is complete. It covers purpose, usage guidelines, path constraints, parameter semantics, and return behavior. The mention of error handling and output formats rounds out the context, so agents have all necessary information for correct invocation.
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%, but the description compensates thoroughly with an Args section explaining each parameter: root_path (absolute path), max_depth (nesting depth, default 1), and output_format (json/markdown, default derived from server). It provides example paths for both Windows and Linux, adding meaning beyond the schema's basic type definitions.
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 returns a compact file and folder tree with depth limitation. It specifies the resource (file/folder tree) and distinguishes it from siblings like python_outline and markdown_outline, which focus on source code outlines rather than directory structure.
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 explicit agent usage guidelines: when to use (quick overview, hierarchy analysis) and when not to use (reading file contents, non-existent/relative paths). This covers both positive use cases and exclusions, making it clear how to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns an outline for each Markdown file: headings, levels, line.
Agent usage guidelines: - Use this tool when you need to extract or display the structure of Markdown documents, such as for navigation, summary, or documentation analysis. - Use when you need to list headings, their levels, and line numbers in Markdown files. - Do not use for non-Markdown files or for reading the full content of the file.
Path requirements: - Paths must not contain URL-encoding (e.g., '%'). - Paths must be absolute. - Paths must exist on disk. Example paths: - Windows: "C:\Users\User\project\README.md" - Linux: "/home/user/project/README.md"
Args: paths (list[str]): List of absolute paths to Markdown files. output_format (str | None): Output format ('json' or 'markdown'). Defaults to server setting (markdown by default).
Returns: dict | str: Outline for each file in the requested format.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | ||
| output_format | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 adds critical context such as path requirements (absolute, no URL-encoding, must exist) and output format defaults. While it doesn't mention error handling or side effects, the read-only nature is implied and the provided constraints are valuable.
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 well-structured with separate sections for the core one-liner, usage guidelines, path requirements, example paths, args, and returns. It is somewhat lengthy but every section adds needed information; the example paths are a minor addition but not wasteful.
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 purpose, usage boundaries, parameter semantics, path constraints, and return format. It doesn't detail the exact structure of the returned outline, but the 'Returns' line gives a minimal overview. For a relatively simple file-reading tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully with an Args section that explains each parameter: paths (list of absolute Markdown paths) and output_format (valid values 'json' or 'markdown', default behavior). This goes well beyond the bare schema, including allowed values and defaults.
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 returns an outline for each Markdown file, listing headings, levels, and line numbers. It uses a specific verb and resource, and the inclusion of 'Markdown' distinguishes it from sibling tools like python_outline and dir_tree.
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?
Explicit agent usage guidelines are provided, stating when to use the tool (extract/display Markdown structure, navigation, summary, documentation analysis) and when not to use it (non-Markdown files or reading full content). This gives clear exclusions and context without explicitly naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for specific OpenAPI operations.
Agent usage guidelines: - Use this tool when you need detailed information about specific API operations. - Use selectors to target specific operations by operationId, method+path, or path. - Set expand_refs=True to resolve schema references for full schema details. - Choose format_output="json" for structured data, "markdown" for formatted output.
Path requirements: - The path must not contain URL-encoding (e.g., '%'). - The path must be absolute. - The path must exist on disk and be a valid OpenAPI JSON or YAML file.
Args: spec_path (str): Absolute path to the OpenAPI JSON or YAML file. selectors (list[str]): List of selectors. Each selector can be: - operationId (exact match) - "METHOD /path" (e.g. "GET /users/{id}") - just a path (e.g. "/users/{id}") to match all methods on that path expand_refs (bool): Whether to resolve local $ref references in schemas. Defaults to False. format_output (str | None): Output format ('json' or 'markdown'). Defaults to server setting.
Returns: dict | str: For format_output="json": Dictionary containing operation details and metadata. - details: list of detailed operation records - count: number of matching operations - error: error message if any, None otherwise For format_output="markdown": formatted markdown string
| Name | Required | Description | Default |
|---|---|---|---|
| selectors | Yes | ||
| spec_path | Yes | ||
| expand_refs | No | ||
| format_output | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behavioral traits: path must be absolute, unencoded, exist, and be a valid OpenAPI file; expand_refs behavior for resolving refs; format_output options; and return structure including error handling. This is more than enough for a read-only file inspection tool, though it does not elaborate on edge cases like empty results or permission issues.
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 well-structured with clear sections: purpose, usage guidelines, path requirements, args, returns. It is substantial yet every sentence provides necessary information for correct use. The front-loaded purpose and usage guidelines make it easy to scan, and the detailed parameter explanations are justified given the tool's complexity.
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 all essential aspects: what it does, when to use it, path constraints, parameter semantics, and return format (including error field). Despite having an output schema, the description still fully explains the return values and error handling, making it self-contained. No important context for selecting or invoking this tool is missing.
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 does so comprehensively: spec_path is defined as the absolute path, selectors are explained with examples, expand_refs has a clear default and effect, and format_output options are listed. This adds significant meaning beyond the raw schema, which only lists types and defaults.
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: 'Get detailed information for specific OpenAPI operations.' This is a specific verb+resource pair that distinguishes it from siblings like openapi_list_operations, which presumably lists operations. The mention of selectors (operationId, method+path, path) further clarifies its targeting of specific 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?
The 'Agent usage guidelines' section explicitly states when to use the tool: 'Use this tool when you need detailed information about specific API operations.' It explains how to use selectors and adjust expand_refs/format_output. However, it does not explicitly mention when not to use it or directly contrast with sibling tools like openapi_list_operations, so it lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List operations from an OpenAPI specification file.
Agent usage guidelines: - Use this tool when you need to explore the available API operations in an OpenAPI spec. - Use when you want to see endpoints, methods, and summaries without detailed schemas. - Do not use for getting detailed parameter or response information.
Path requirements: - The path must not contain URL-encoding (e.g., '%'). - The path must be absolute. - The path must exist on disk and be a valid OpenAPI JSON or YAML file.
Args: spec_path (str): Absolute path to the OpenAPI JSON or YAML file. output_format (str | None): Output format ('json' or 'markdown'). Defaults to server setting. filter_by_tag (str | None): Filter operations by tag. Only operations with this tag will be included. filter_by_method (str | None): Filter operations by HTTP method (e.g., 'GET', 'POST'). filter_by_path (str | None): Filter operations by path containing this substring (case-insensitive). limit (int): Maximum number of operations to return. Defaults to 50. offset (int): Number of operations to skip from the start. Defaults to 0.
Examples: - To get operations related to users: {"spec_path": "/path/to/spec.json", "filter_by_path": "user"} - To get all GET operations: {"spec_path": "/path/to/spec.json", "filter_by_method": "GET"} - To get operations with a specific tag: {"spec_path": "/path/to/spec.json", "filter_by_tag": "users"} - To paginate through results: {"spec_path": "/path/to/spec.json", "limit": 20, "offset": 40}
Returns: dict | str: For format_output="json": Dictionary containing operations list and metadata. - operations: list of operation dicts with method, path, operation_id, summary, tags - count: number of operations returned (after filtering and pagination) - total_count: total number of operations matching filters (before pagination) - error: error message if any, None otherwise For format_output="markdown": formatted markdown string
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| spec_path | Yes | ||
| filter_by_tag | No | ||
| output_format | No | ||
| filter_by_path | No | ||
| filter_by_method | No |
| Name | Required | Description |
|---|---|---|
| result | 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 of behavioral disclosure. It thoroughly describes behavior: filtering, pagination, output formats, return structure (operations, count, total_count, error), and path requirements (absolute, no URL-encoding, must exist and be valid). This goes well beyond a simple summary.
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?
Though the description is long, it is well-structured with sections (Agent usage guidelines, Path requirements, Args, Examples, Returns). Each section provides essential information without redundancy. The main purpose is front-loaded, and all content earns its place.
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 has 7 parameters, no annotations, and no output schema. The description covers all aspects comprehensively: purpose, usage, parameter semantics, examples, return format, and edge cases. It is fully self-contained 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%, but the description compensates with an Args section that explains every parameter in plain language, including defaults and example values. The examples further illustrate usage with realistic JSON inputs, making the parameter semantics completely clear.
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 opens with 'List operations from an OpenAPI specification file', which clearly specifies the verb (list) and resource (operations in an OpenAPI spec). It distinguishes itself from siblings by explicitly noting it's for exploring endpoints, methods, and summaries without detailed schemas, which contrasts with sibling 'openapi_get_operation_details'.
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 explicit usage guidance with bullet points: 'Use this tool when...' and 'Do not use for...'. It clearly states the scenarios for use (exploring available operations) and the exclusion (detailed parameter/response information), which implicitly points to the sibling getting details tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns an outline for each Python file: imports, classes, functions, docstrings.
Agent usage guidelines: - Use this tool when you need to understand the structure of Python code files, such as for code review, navigation, or documentation generation. - Use when you need to extract or display the list of imports, classes, functions, and their docstrings from Python files. - Do not use for non-Python files or for reading file contents in detail.
Path requirements: - Paths must not contain URL-encoding (e.g., '%'). - Paths must be absolute. - Paths must exist on disk. Example paths: - Windows: "C:\Users\User\project\main.py" - Linux: "/home/user/project/main.py"
Args: paths (list[str]): List of absolute paths to Python files. output_format (str | None): Output format ('json' or 'markdown'). Defaults to server setting (markdown by default). Returns: dict | str: Outline for each file in the requested format.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | ||
| output_format | No |
| Name | Required | Description |
|---|---|---|
| result | 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 the read-only nature (returns an outline), the output format options, path constraints, and that it does not read file contents in detail. However, it does not describe error behavior for invalid paths, though it states paths must exist.
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 well-structured with clear sections (Agent usage guidelines, Path requirements, Args, Returns). It is front-loaded with the main purpose and every sentence adds value, including examples and constraints. No fluff or repetition.
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 tool with 2 parameters, no annotations, and an output schema, the description is complete. It covers purpose, usage context, parameter semantics, path prerequisites, and return format. The presence of an output schema reduces the need to explain return structure, and the description covers all other aspects adequately.
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%, but the description compensates fully. It explains both parameters: 'paths' as a list of absolute paths, and 'output_format' with allowed values ('json' or 'markdown') and default behavior. It even provides example paths for Windows and Linux.
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 'Returns an outline for each Python file: imports, classes, functions, docstrings' with a specific verb and resource. It clearly distinguishes itself from siblings like dir_tree by focusing on Python file structure rather than directory trees.
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?
Explicit guidance is provided: 'Use this tool when you need to understand the structure of Python code files' and 'Do not use for non-Python files or for reading file contents in detail.' Path requirements and examples are also given, fully explaining when and how to use the tool.
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.1.0dir_treemarkdown_outlineopenapi_get_operation_detailsopenapi_list_operationspython_outlineScored across 5 tools
Each tool targets a distinct resource: directory tree, Python code structure, Markdown structure, and OpenAPI operations (list vs. details). There is no overlap in purpose, and the descriptions clearly specify when to use each tool.
Most tools follow a descriptive prefix (dir, python, markdown, openapi), but the verb placement differs: 'python_outline' and 'markdown_outline' are noun-phrases, while 'openapi_list_operations' and 'openapi_get_operation_details' use verb + object. This is readable and somewhat predictable, but not perfectly consistent.
With 5 tools, the server is well-scoped for a project explorer, covering directory trees, Python and Markdown outlines, and OpenAPI exploration. Each tool serves a distinct purpose without redundancy.
The server provides good coverage of structural exploration for a project, including directory hierarchy, Python and Markdown outlines, and OpenAPI operations with both listing and detailed views. It lacks support for other file types (e.g., JavaScript, JSON), but this appears to be an intentional scope limitation.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Security + bug + perf + refactor audit for Python. Returns 0-10 score + MD report.
