@teambit/cli-mcp-server 0.0.17 → 0.0.19

package/README.docs.mdx

@@ -18,7 +18,7 @@ This server acts as a bridge between MCP clients (such as VS Code, AI tools, or
 The Bit CLI MCP Server is included with Bit. If you have Bit installed, you can run the server using:
 
 ```
-bit mcp-server
+bit mcp-server start
 ```
 
 ## Usage
@@ -26,16 +26,13 @@ bit mcp-server
 ### Command-Line Options
 
 ```
-bit mcp-server [options]
+bit mcp-server start [options]
 ```
 
 Options:
 
-- `-e, --extended`: Enable the full set of Bit CLI commands as MCP tools
-- `--consumer-project`: For non-Bit workspaces that only consume Bit component packages. Enables only "schema", "show", and "remote-search" tools and automatically adds the "--remote" flag to relevant commands.
-- `--include-only <commands>`: Specify a subset of commands to expose as MCP tools (comma-separated list)
+- `--consumer-project`: For non-Bit workspaces that only consume Bit component packages. Enables only "bit_remote_search" and "bit_remote_component_details" tools and automatically adds the "--remote" flag to relevant commands.
 - `--include-additional <commands>`: Add specific commands to the available tools (comma-separated list)
-- `--exclude <commands>`: Prevent specific commands from being exposed (comma-separated list)
 
 ### Integrating with IDEs
 
@@ -67,11 +64,8 @@ This command automatically configures the MCP server settings in your chosen edi
 #### Configuration Options
 
 - `--global`: Apply configuration globally (user settings) instead of workspace settings
-- `--extended`: Configure with extended mode enabled
 - `--consumer-project`: Configure for consumer projects
-- `--include-only <commands>`: Specify subset of commands to expose
 - `--include-additional <commands>`: Add specific commands to the available tools
-- `--exclude <commands>`: Prevent specific commands from being exposed
 
 #### Examples
 
@@ -79,11 +73,11 @@ This command automatically configures the MCP server settings in your chosen edi
 # Basic VS Code setup (workspace level)
 bit mcp-server setup
 
-# Global setup for Cursor with extended mode
-bit mcp-server setup cursor --global --extended
+# Global setup for Cursor
+bit mcp-server setup cursor --global
 
-# Setup for Windsurf with consumer project mode
-bit mcp-server setup windsurf --consumer-project
+# Setup with consumer project mode
+bit mcp-server setup --consumer-project
 ```
 
 #### Manual Configuration
@@ -99,7 +93,7 @@ If you need to manually configure the settings, here's a basic example for VS Co
     "servers": {
       "bit-cli": {
         "command": "bit",
-        "args": ["mcp-server"]
+        "args": ["mcp-server", "start"]
       }
     }
   }
@@ -112,7 +106,7 @@ If you need to manually configure the settings, here's a basic example for VS Co
 import { McpClient } from '@modelcontextprotocol/sdk/client';
 
 async function example() {
-  const client = await McpClient.spawn('bit', ['mcp-server']);
+  const client = await McpClient.spawn('bit', ['mcp-server', 'start']);
 
   // Call a Bit CLI tool via MCP
   const result = await client.callTool('bit_status', { cwd: '/path/to/workspace' });
@@ -125,7 +119,7 @@ async function example() {
 
 ## Available Tools
 
-The Bit CLI MCP Server operates in three modes and provides several specialized tools:
+The Bit CLI MCP Server operates in two modes and provides several specialized tools:
 
 ### Default Mode
 
@@ -147,29 +141,16 @@ In default mode, the server exposes a minimal set of essential tools focused on
 
 This mode is designed for applications or projects that are not Bit workspaces but need to consume or work with Bit components as packages. It provides a minimal set of tools focused on component discovery and information:
 
-- `bit_schema`: Retrieves component API schema from remote scopes (automatically adds `--remote` flag)
-- `bit_show`: Displays component information from remote scopes (automatically adds `--remote` flag)
+- `bit_remote_search`: Search for components in remote scopes
+- `bit_remote_component_details`: Get detailed information about a remote component including basic info and its public API schema (combines the functionality of show and schema commands)
 
 In this mode:
 
 1. You don't need a Bit workspace initialization
-2. The `--remote` flag is automatically added to `show` and `schema` commands
-3. The `cwd` parameter is still required but can be any directory (not necessarily a Bit workspace)
-4. You can still add additional tools with the `--include-additional` flag
-
-### Extended Mode (--extended)
-
-When started with the `--extended` flag, the server exposes nearly all Bit CLI commands as MCP tools, including:
-
-- All lane sub-commands (remove, alias, rename, diff, change-scope, import, fetch, eject, history, etc.)
-- Development tools (build, lint, format)
-- Package management (uninstall, update)
-- Component operations (recover, fork, rename)
-- Workspace management (ws-config, stash, aspect)
-- Analysis tools (insight, deps, why)
-- And many more
-
-> **Note:** When using extended mode, some AI models (particularly Gemini and ChatGPT) may struggle with the high number of available tools and respond with "400 Bad Request" or "500 Server Error" errors. This is not due to any issue with specific tools, but rather with how these models handle large tool sets. Claude Sonnet tends to handle extended mode better. If you encounter these errors, try using default mode or selectively adding only the tools you need via the `--include-additional` flag.
+2. Only these 2 tools are available (no workspace-specific tools)
+3. The `--remote` flag is automatically added to component detail queries
+4. The `cwd` parameter is still required but can be any directory (not necessarily a Bit workspace)
+5. You can still add additional tools with the `--include-additional` flag
 
 ## Tool Parameters
 
@@ -187,21 +168,56 @@ Example tool call for `bit_status`:
 
 ## Custom Tool Selection
 
-To customize the available tools beyond the default set or extended mode:
+To customize the available tools:
 
 ```
-# Include only specific tools
-bit mcp-server --include-only "status,show,tag,snap,import,export"
-
 # Add specific tools to the available tools
-bit mcp-server --include-additional "build,lint,format,create,schema"
+bit mcp-server start --include-additional "build,lint,format,create,schema"
 
 # For consumer projects (non-Bit workspaces)
-bit mcp-server --consumer-project
+bit mcp-server start --consumer-project
 
 # Add specific tools to the consumer project set
-bit mcp-server --consumer-project --include-additional "deps,get,preview"
+bit mcp-server start --consumer-project --include-additional "deps,get,preview"
+```
+
+### Writing AI Assistant Rules
+
+The MCP server provides a `rules` command to create instruction files for AI assistants:
+
+```bash
+bit mcp-server rules [vscode|cursor|windsurf] [options]
+```
+
+This command creates rules/instructions markdown files that provide guidance to AI assistants on how to effectively use the Bit MCP server and follow best practices when working with Bit components.
+
+#### Supported Editors
+
+- **VS Code**: `bit mcp-server rules vscode` (or just `bit mcp-server rules`)
+- **Cursor**: `bit mcp-server rules cursor`
+- **Windsurf**: `bit mcp-server rules windsurf`
+
+#### Configuration Options
+
+- `--global`: Write rules to global configuration (default: workspace-specific)
+- `--print`: Print rules content to screen instead of writing to file
+- `--consumer-project`: Generate rules for consumer projects that only use Bit components as packages
+
+#### Examples
+
+```bash
+# Basic VS Code rules (workspace level)
+bit mcp-server rules
+
+# Global rules for Cursor
+bit mcp-server rules cursor --global
+
+# Consumer project rules for VS Code
+bit mcp-server rules --consumer-project
+
+# Print rules content to screen for manual setup
+bit mcp-server rules --print
 
-# Exclude specific tools from being available
-bit mcp-server --extended --exclude "checkout,remove"
+# Print consumer project content for Windsurf (requires manual addition to .windsurfrules)
+bit mcp-server rules windsurf --print --consumer-project
 ```

package/bit-rules-consumer-template.md

@@ -0,0 +1,11 @@
+---
+applyTo: '**'
+---
+
+## How to Install Use and Bit Components
+
+- Bit Components are reusable pieces of code in the form of node packages.
+- Search for Bit Components using `bit_remote_search` tool.
+- Use `bit_show` only on Bit Components to get information like package name (to use when installing, e.g. `npm install <package-name>`), APIs and documentation (to use when using in code).
+- If a user is requesting functionality, you can search if there are available components that implement it using `bit_remote_search`.
+- Filter my search with my account name "ACCOUNT" to find components you have created or are a maintainer of.

package/bit-rules-template.md

@@ -0,0 +1,108 @@
+---
+applyTo: '**'
+---
+
+# Bit MCP Agent Instructions
+
+## Core Objectives
+
+- Your goal is to efficiently automate Bit workflows and help users manage and reuse components.
+- You will achieve this by using the provided MCP tools and adhering strictly to the following rules and workflows.
+
+## Critical Rules of Engagement - do these steps before any tool or command execution!!!
+
+1.  **Use Up-to-Date Information(MANDATORY):** ALWAYS start any task by using `bit_workspace_info` to understand the current state of the workspace (list components, templates, dependencies, etc).
+2.  **MCP Tools First:** You MUST use the provided MCP tools to interact with Bit. Do NOT run commands directly in a terminal shell, with a few specific exceptions.
+3.  **Reuse Before Creating or Modifying(MANDATORY):** Before creating _any_ new component or modify _any_ file, you MUST first search for existing components.
+    - Use `bit_workspace_info` to check for local and existing components.
+    - Use `bit_remote_search` to find components on the remote scope.
+    - Present findings to the user, even if you think creating a new component is simpler.
+4.  **Do not rely on cached knowledge:** Always run `bit_command_help` for command details.
+5.  **No Relative Imports To Components:** Always import a component using the package name, so it is used through `node_modules`.
+6.  **Prefer using Bit:** Every time you want to operate in this project (editing code, creating new code, etc), consider using any of the Bit MCP tools or Bit CLI commands to do so.
+7.  **Prioritize creating Bit components and composing over adding functionality to existing components:** New functionality should be a dependency, unless the user specifically asks for a new functionality added to an existing component.
+8.  **Use the `bit_commands_list` to understand available commands:** This will help you decide which command to use for a specific operation.
+9.  **User may use different terms to describe components:** Be flexible and understand that users may refer to components as "features", "apps", "modules", "pages" or "services". Always clarify with the user what they mean.
+
+## Tooling & Command Execution Hierarchy
+
+This is the decision-making process for executing any Bit operation.
+
+### Step 1: Choose the Correct Generic Execution Tool
+
+- If no dedicated tool exists, you must use one of the generic execution tools. Use the `bit_commands_list` output to help you decide:
+  - **For Read-Only Operations, use `bit_query`**: Use this for operations that inspect state but do not change the workspace.
+  - **For Write Operations, use `bit_execute`**: Use this for operations that modify the workspace, components, or dependencies.
+
+### Step 2: Check for Terminal Exceptions
+
+- The following commands have rich, interactive, or streaming output and should be run directly in the user's terminal. You should construct the command and advise the user to run it.
+  - `bit test`
+  - `bit build`
+  - `bit start` (long-running processes)
+  - `bit watch` (long-running processes)
+  - `bit lint`
+  - `bit check-types`
+  - `bit run` (long-running processes)
+
+## Core Workflows
+
+### Workflow: Error Diagnosis in a Bit Workspace
+
+- `bit_workspace_info` with the "warnings" option to detect errors. Output includes possible solutions, follow them.
+- Rerun `bit_workspace_info` to validate fixes. If error persists, use `bit_component_details` on relevant component(s) for more information.
+
+### Workflow: In-Component Code Issues
+
+- For code issues (compile, lint, test, type checking), run the relevant terminal command and pass the component ID (e.g. `bit test COMPONENT_ID`).
+- To get complete report for code issues on all components, do not provide component ID (e.g. `bit test`).
+- Adding `--log` CLI option gives more details on errors.
+
+### Workflow: Generating New Components, Feature or Apps
+
+- **Follow Critical Rule #3 Reuse Before Creating or Modifying.**
+- `bit_workspace_info` lists templates for new components.
+- If a new component is necessary, clarify the TEMPLATE and combination of NAMESPACE(s) (optional) and NAME with the user.
+- Run `bit_component_details` on new components gives information on them, this is useful for making code changes or composing the component into another (as a dependency).
+- After generating a new component, ask if to add implementation to the new component and remember to update all relevant files (e.g. `*.composition.*`, `*.docs.mdx`, `*.spec.*`).
+
+### Workflow: Adding Functionality (feature, page, module, function, etc) to Bit Components and Apps
+
+- **Follow Critical Rule #3 Reuse Before Creating.**
+- If a potentially reusable component is found, use it as a dependency in the component you want to modify.
+  **Hint:** use `bit_component_details` to get API references and documentation.
+  **Follow Critical Rule #5 No Relative Imports Between Components**.
+- Validate with user if they want the new functionality to be in a new component before generating any code in any component.
+  - If need to create a new component, clarify the TEMPLATE and combination of NAMESPACE(s) (optional) and NAME with the user.
+- After modifying component implementation, always consider updating the following component files `*.composition.*`, `*.docs.mdx`, `*.spec.*`.
+
+### Workflow: USE or DEVELOP a Component
+
+- Use `bit_component_details` to get the component location.
+- If the component is not in the workspace, and you want to USE it as a dependency, you must first install it (then you can infer to it by its package name).
+- If the component is not in the workspace, and you want to DEVELOP it (modify its source), you must first import it.
+
+### Workflow: Collaboration, Change Management and Version Control
+
+- Bit uses a concept called "Lanes" to manage changes across components, this is similar to Git branches.
+- Use `bit_workspace_info` to identify the current active lane.
+- You must not snap or export components directly to the `main` lane.
+- Use `bit_execute` for "Bit Lane" commands.
+- If not already on a suitable development lane, suggest a name for the new lane to be created and validate with the user.
+- The workspace automatically switches to a new lane once created.
+- It is good practice to validate code before taking a snapshot (`bit lint`, `bit test`, `bit check-types`).
+- Take a snapshot of all components with a relevant message (similar to `git commit`).
+- Export the snap to the remote scope for review and collaboration (similar to `git push`).
+
+## Glossary
+
+- **Bit Component:** An extensible, portable software container. Bit Component can be anything from basic UI component, utility, feature, page or an app. Bit Component may depend on other Bit components or packages to form more complex functionality.
+- **Workspace:** A Bit-initialized directory containing components.
+- **Scope:** A collaboration server for components that defines ownership.
+- **Application (App):** A Bit Component with its own runtime. It is usually composed from various features and components.
+- **Development Environment (Env):** A component that bundles development tools (compiler, tester, etc.).
+- **Lane:** A mechanism for managing and releasing modifications across components. `main` is the default lane. Lane is similar in concept to a Git Branch.
+
+## Pointers to remember:
+
+- For generating ESlint or TypeScript configuration files execute the command `bit workspace-config write --clean`

package/dist/README.docs.mdx

@@ -18,7 +18,7 @@ This server acts as a bridge between MCP clients (such as VS Code, AI tools, or
 The Bit CLI MCP Server is included with Bit. If you have Bit installed, you can run the server using:
 
 ```
-bit mcp-server
+bit mcp-server start
 ```
 
 ## Usage
@@ -26,16 +26,13 @@ bit mcp-server
 ### Command-Line Options
 
 ```
-bit mcp-server [options]
+bit mcp-server start [options]
 ```
 
 Options:
 
-- `-e, --extended`: Enable the full set of Bit CLI commands as MCP tools
-- `--consumer-project`: For non-Bit workspaces that only consume Bit component packages. Enables only "schema", "show", and "remote-search" tools and automatically adds the "--remote" flag to relevant commands.
-- `--include-only <commands>`: Specify a subset of commands to expose as MCP tools (comma-separated list)
+- `--consumer-project`: For non-Bit workspaces that only consume Bit component packages. Enables only "bit_remote_search" and "bit_remote_component_details" tools and automatically adds the "--remote" flag to relevant commands.
 - `--include-additional <commands>`: Add specific commands to the available tools (comma-separated list)
-- `--exclude <commands>`: Prevent specific commands from being exposed (comma-separated list)
 
 ### Integrating with IDEs
 
@@ -67,11 +64,8 @@ This command automatically configures the MCP server settings in your chosen edi
 #### Configuration Options
 
 - `--global`: Apply configuration globally (user settings) instead of workspace settings
-- `--extended`: Configure with extended mode enabled
 - `--consumer-project`: Configure for consumer projects
-- `--include-only <commands>`: Specify subset of commands to expose
 - `--include-additional <commands>`: Add specific commands to the available tools
-- `--exclude <commands>`: Prevent specific commands from being exposed
 
 #### Examples
 
@@ -79,11 +73,11 @@ This command automatically configures the MCP server settings in your chosen edi
 # Basic VS Code setup (workspace level)
 bit mcp-server setup
 
-# Global setup for Cursor with extended mode
-bit mcp-server setup cursor --global --extended
+# Global setup for Cursor
+bit mcp-server setup cursor --global
 
-# Setup for Windsurf with consumer project mode
-bit mcp-server setup windsurf --consumer-project
+# Setup with consumer project mode
+bit mcp-server setup --consumer-project
 ```
 
 #### Manual Configuration
@@ -99,7 +93,7 @@ If you need to manually configure the settings, here's a basic example for VS Co
     "servers": {
       "bit-cli": {
         "command": "bit",
-        "args": ["mcp-server"]
+        "args": ["mcp-server", "start"]
       }
     }
   }
@@ -112,7 +106,7 @@ If you need to manually configure the settings, here's a basic example for VS Co
 import { McpClient } from '@modelcontextprotocol/sdk/client';
 
 async function example() {
-  const client = await McpClient.spawn('bit', ['mcp-server']);
+  const client = await McpClient.spawn('bit', ['mcp-server', 'start']);
 
   // Call a Bit CLI tool via MCP
   const result = await client.callTool('bit_status', { cwd: '/path/to/workspace' });
@@ -125,7 +119,7 @@ async function example() {
 
 ## Available Tools
 
-The Bit CLI MCP Server operates in three modes and provides several specialized tools:
+The Bit CLI MCP Server operates in two modes and provides several specialized tools:
 
 ### Default Mode
 
@@ -147,29 +141,16 @@ In default mode, the server exposes a minimal set of essential tools focused on
 
 This mode is designed for applications or projects that are not Bit workspaces but need to consume or work with Bit components as packages. It provides a minimal set of tools focused on component discovery and information:
 
-- `bit_schema`: Retrieves component API schema from remote scopes (automatically adds `--remote` flag)
-- `bit_show`: Displays component information from remote scopes (automatically adds `--remote` flag)
+- `bit_remote_search`: Search for components in remote scopes
+- `bit_remote_component_details`: Get detailed information about a remote component including basic info and its public API schema (combines the functionality of show and schema commands)
 
 In this mode:
 
 1. You don't need a Bit workspace initialization
-2. The `--remote` flag is automatically added to `show` and `schema` commands
-3. The `cwd` parameter is still required but can be any directory (not necessarily a Bit workspace)
-4. You can still add additional tools with the `--include-additional` flag
-
-### Extended Mode (--extended)
-
-When started with the `--extended` flag, the server exposes nearly all Bit CLI commands as MCP tools, including:
-
-- All lane sub-commands (remove, alias, rename, diff, change-scope, import, fetch, eject, history, etc.)
-- Development tools (build, lint, format)
-- Package management (uninstall, update)
-- Component operations (recover, fork, rename)
-- Workspace management (ws-config, stash, aspect)
-- Analysis tools (insight, deps, why)
-- And many more
-
-> **Note:** When using extended mode, some AI models (particularly Gemini and ChatGPT) may struggle with the high number of available tools and respond with "400 Bad Request" or "500 Server Error" errors. This is not due to any issue with specific tools, but rather with how these models handle large tool sets. Claude Sonnet tends to handle extended mode better. If you encounter these errors, try using default mode or selectively adding only the tools you need via the `--include-additional` flag.
+2. Only these 2 tools are available (no workspace-specific tools)
+3. The `--remote` flag is automatically added to component detail queries
+4. The `cwd` parameter is still required but can be any directory (not necessarily a Bit workspace)
+5. You can still add additional tools with the `--include-additional` flag
 
 ## Tool Parameters
 
@@ -187,21 +168,56 @@ Example tool call for `bit_status`:
 
 ## Custom Tool Selection
 
-To customize the available tools beyond the default set or extended mode:
+To customize the available tools:
 
 ```
-# Include only specific tools
-bit mcp-server --include-only "status,show,tag,snap,import,export"
-
 # Add specific tools to the available tools
-bit mcp-server --include-additional "build,lint,format,create,schema"
+bit mcp-server start --include-additional "build,lint,format,create,schema"
 
 # For consumer projects (non-Bit workspaces)
-bit mcp-server --consumer-project
+bit mcp-server start --consumer-project
 
 # Add specific tools to the consumer project set
-bit mcp-server --consumer-project --include-additional "deps,get,preview"
+bit mcp-server start --consumer-project --include-additional "deps,get,preview"
+```
+
+### Writing AI Assistant Rules
+
+The MCP server provides a `rules` command to create instruction files for AI assistants:
+
+```bash
+bit mcp-server rules [vscode|cursor|windsurf] [options]
+```
+
+This command creates rules/instructions markdown files that provide guidance to AI assistants on how to effectively use the Bit MCP server and follow best practices when working with Bit components.
+
+#### Supported Editors
+
+- **VS Code**: `bit mcp-server rules vscode` (or just `bit mcp-server rules`)
+- **Cursor**: `bit mcp-server rules cursor`
+- **Windsurf**: `bit mcp-server rules windsurf`
+
+#### Configuration Options
+
+- `--global`: Write rules to global configuration (default: workspace-specific)
+- `--print`: Print rules content to screen instead of writing to file
+- `--consumer-project`: Generate rules for consumer projects that only use Bit components as packages
+
+#### Examples
+
+```bash
+# Basic VS Code rules (workspace level)
+bit mcp-server rules
+
+# Global rules for Cursor
+bit mcp-server rules cursor --global
+
+# Consumer project rules for VS Code
+bit mcp-server rules --consumer-project
+
+# Print rules content to screen for manual setup
+bit mcp-server rules --print
 
-# Exclude specific tools from being available
-bit mcp-server --extended --exclude "checkout,remove"
+# Print consumer project content for Windsurf (requires manual addition to .windsurfrules)
+bit mcp-server rules windsurf --print --consumer-project
 ```

package/dist/bit-rules-consumer-template.md

@@ -0,0 +1,11 @@
+---
+applyTo: '**'
+---
+
+## How to Install Use and Bit Components
+
+- Bit Components are reusable pieces of code in the form of node packages.
+- Search for Bit Components using `bit_remote_search` tool.
+- Use `bit_show` only on Bit Components to get information like package name (to use when installing, e.g. `npm install <package-name>`), APIs and documentation (to use when using in code).
+- If a user is requesting functionality, you can search if there are available components that implement it using `bit_remote_search`.
+- Filter my search with my account name "ACCOUNT" to find components you have created or are a maintainer of.

package/dist/bit-rules-template.md

@@ -0,0 +1,108 @@
+---
+applyTo: '**'
+---
+
+# Bit MCP Agent Instructions
+
+## Core Objectives
+
+- Your goal is to efficiently automate Bit workflows and help users manage and reuse components.
+- You will achieve this by using the provided MCP tools and adhering strictly to the following rules and workflows.
+
+## Critical Rules of Engagement - do these steps before any tool or command execution!!!
+
+1.  **Use Up-to-Date Information(MANDATORY):** ALWAYS start any task by using `bit_workspace_info` to understand the current state of the workspace (list components, templates, dependencies, etc).
+2.  **MCP Tools First:** You MUST use the provided MCP tools to interact with Bit. Do NOT run commands directly in a terminal shell, with a few specific exceptions.
+3.  **Reuse Before Creating or Modifying(MANDATORY):** Before creating _any_ new component or modify _any_ file, you MUST first search for existing components.
+    - Use `bit_workspace_info` to check for local and existing components.
+    - Use `bit_remote_search` to find components on the remote scope.
+    - Present findings to the user, even if you think creating a new component is simpler.
+4.  **Do not rely on cached knowledge:** Always run `bit_command_help` for command details.
+5.  **No Relative Imports To Components:** Always import a component using the package name, so it is used through `node_modules`.
+6.  **Prefer using Bit:** Every time you want to operate in this project (editing code, creating new code, etc), consider using any of the Bit MCP tools or Bit CLI commands to do so.
+7.  **Prioritize creating Bit components and composing over adding functionality to existing components:** New functionality should be a dependency, unless the user specifically asks for a new functionality added to an existing component.
+8.  **Use the `bit_commands_list` to understand available commands:** This will help you decide which command to use for a specific operation.
+9.  **User may use different terms to describe components:** Be flexible and understand that users may refer to components as "features", "apps", "modules", "pages" or "services". Always clarify with the user what they mean.
+
+## Tooling & Command Execution Hierarchy
+
+This is the decision-making process for executing any Bit operation.
+
+### Step 1: Choose the Correct Generic Execution Tool
+
+- If no dedicated tool exists, you must use one of the generic execution tools. Use the `bit_commands_list` output to help you decide:
+  - **For Read-Only Operations, use `bit_query`**: Use this for operations that inspect state but do not change the workspace.
+  - **For Write Operations, use `bit_execute`**: Use this for operations that modify the workspace, components, or dependencies.
+
+### Step 2: Check for Terminal Exceptions
+
+- The following commands have rich, interactive, or streaming output and should be run directly in the user's terminal. You should construct the command and advise the user to run it.
+  - `bit test`
+  - `bit build`
+  - `bit start` (long-running processes)
+  - `bit watch` (long-running processes)
+  - `bit lint`
+  - `bit check-types`
+  - `bit run` (long-running processes)
+
+## Core Workflows
+
+### Workflow: Error Diagnosis in a Bit Workspace
+
+- `bit_workspace_info` with the "warnings" option to detect errors. Output includes possible solutions, follow them.
+- Rerun `bit_workspace_info` to validate fixes. If error persists, use `bit_component_details` on relevant component(s) for more information.
+
+### Workflow: In-Component Code Issues
+
+- For code issues (compile, lint, test, type checking), run the relevant terminal command and pass the component ID (e.g. `bit test COMPONENT_ID`).
+- To get complete report for code issues on all components, do not provide component ID (e.g. `bit test`).
+- Adding `--log` CLI option gives more details on errors.
+
+### Workflow: Generating New Components, Feature or Apps
+
+- **Follow Critical Rule #3 Reuse Before Creating or Modifying.**
+- `bit_workspace_info` lists templates for new components.
+- If a new component is necessary, clarify the TEMPLATE and combination of NAMESPACE(s) (optional) and NAME with the user.
+- Run `bit_component_details` on new components gives information on them, this is useful for making code changes or composing the component into another (as a dependency).
+- After generating a new component, ask if to add implementation to the new component and remember to update all relevant files (e.g. `*.composition.*`, `*.docs.mdx`, `*.spec.*`).
+
+### Workflow: Adding Functionality (feature, page, module, function, etc) to Bit Components and Apps
+
+- **Follow Critical Rule #3 Reuse Before Creating.**
+- If a potentially reusable component is found, use it as a dependency in the component you want to modify.
+  **Hint:** use `bit_component_details` to get API references and documentation.
+  **Follow Critical Rule #5 No Relative Imports Between Components**.
+- Validate with user if they want the new functionality to be in a new component before generating any code in any component.
+  - If need to create a new component, clarify the TEMPLATE and combination of NAMESPACE(s) (optional) and NAME with the user.
+- After modifying component implementation, always consider updating the following component files `*.composition.*`, `*.docs.mdx`, `*.spec.*`.
+
+### Workflow: USE or DEVELOP a Component
+
+- Use `bit_component_details` to get the component location.
+- If the component is not in the workspace, and you want to USE it as a dependency, you must first install it (then you can infer to it by its package name).
+- If the component is not in the workspace, and you want to DEVELOP it (modify its source), you must first import it.
+
+### Workflow: Collaboration, Change Management and Version Control
+
+- Bit uses a concept called "Lanes" to manage changes across components, this is similar to Git branches.
+- Use `bit_workspace_info` to identify the current active lane.
+- You must not snap or export components directly to the `main` lane.
+- Use `bit_execute` for "Bit Lane" commands.
+- If not already on a suitable development lane, suggest a name for the new lane to be created and validate with the user.
+- The workspace automatically switches to a new lane once created.
+- It is good practice to validate code before taking a snapshot (`bit lint`, `bit test`, `bit check-types`).
+- Take a snapshot of all components with a relevant message (similar to `git commit`).
+- Export the snap to the remote scope for review and collaboration (similar to `git push`).
+
+## Glossary
+
+- **Bit Component:** An extensible, portable software container. Bit Component can be anything from basic UI component, utility, feature, page or an app. Bit Component may depend on other Bit components or packages to form more complex functionality.
+- **Workspace:** A Bit-initialized directory containing components.
+- **Scope:** A collaboration server for components that defines ownership.
+- **Application (App):** A Bit Component with its own runtime. It is usually composed from various features and components.
+- **Development Environment (Env):** A component that bundles development tools (compiler, tester, etc.).
+- **Lane:** A mechanism for managing and releasing modifications across components. `main` is the default lane. Lane is similar in concept to a Git Branch.
+
+## Pointers to remember:
+
+- For generating ESlint or TypeScript configuration files execute the command `bit workspace-config write --clean`

package/dist/cli-mcp-server.main.runtime.d.ts

@@ -1,7 +1,7 @@
 import { CLIMain } from '@teambit/cli';
 import { Logger, LoggerMain } from '@teambit/logger';
 import { Http } from '@teambit/scope.network';
-import { SetupOptions } from './setup-utils';
+import { SetupOptions, RulesOptions } from './setup-utils';
 export declare class CliMcpServerMain {
     private cli;
     private logger;
@@ -32,10 +32,7 @@ export declare class CliMcpServerMain {
      */
     private callBitServerAPIWithRoute;
     runMcpServer(options: {
-        extended?: boolean;
-        includeOnly?: string;
         includeAdditional?: string;
-        exclude?: string;
         bitBin?: string;
         consumerProject?: boolean;
     }): Promise<void>;
@@ -54,6 +51,7 @@ export declare class CliMcpServerMain {
      */
     private extractOwnerFromWorkspace;
     private registerRemoteSearchTool;
+    private registerRemoteComponentDetailsTool;
     private registerWorkspaceInfoTool;
     private registerComponentDetailsTool;
     private registerCommandsListTool;
@@ -80,6 +78,8 @@ export declare class CliMcpServerMain {
     private safeBitCommandExecution;
     getEditorDisplayName(editor: string): string;
     setupEditor(editor: string, options: SetupOptions, workspaceDir?: string): Promise<void>;
+    writeRulesFile(editor: string, options: RulesOptions, workspaceDir?: string): Promise<void>;
+    getRulesContent(consumerProject?: boolean): Promise<string>;
     static slots: never[];
     static dependencies: import("@teambit/harmony").Aspect[];
     static runtime: import("@teambit/harmony").RuntimeDefinition;