LSP-Claw Detailed Instructions

August 13, 2026 ยท View on GitHub

LSP-Claw lets an AI agent work with Barracuda App Server (BAS) based tools such as Mako Server, Xedge, and Xedge32 through an MCP server. Instead of asking an AI agent, such as Codex, to edit random local files, you give it access to a controlled lab app where it can inspect examples, create files, run the lab, and debug server-side Lua/LSP code.

New to LSP-Claw? Watch the LSP-Claw introduction video for a high-level overview of what LSP-Claw is and how it fits into AI-assisted Mako/Xedge development.

LSP-Claw

LSP-Claw is especially useful for embedded systems. LSP-Claw can remotely start, stop, and replace the application being tested without restarting the device, RTOS, or hosting server. A monolithic RTOS device can keep running its core firmware while the MCP server restarts only the lab app.

Design a Device Interface

For device-management applications, use Light-Dashboard.

Use LSP-Claw to build a device management interface using
Light-Dashboard/custom. Check the runtime and lab, then ask what device, pages,
live data, commands, and visual style I need. Build and test the interface and
give me its URL.

If you use Mako Server, the recommended starting point is the Mako Server Development Package. This package is designed for Mako-based development and includes the tooling needed to use LSP-Claw in a ready-to-run Mako environment.

Use the standalone LSP-Claw ZIP or source build when you are integrating LSP-Claw into an existing Mako installation, an Xedge deployment, or an RTOS target that already has its own firmware and deployment workflow.

What MCP Means Here

MCP lets an AI agent use tools provided by another program. In this case:

  • LSP-Claw is the MCP server.
  • LSP-Claw runs as a Lua application powered by Mako, Mako with Xedge, or standalone Xedge on an RTOS.
  • Codex, Claude Code, Google Antigravity, or another assistant is the AI agent.
  • The lab is the Lua application area that the AI agent can inspect, edit, and run.

LSP-Claw supports multiple named labs in independent top-level directories. Each MCP session selects its own lab, so different people or agents using the same server token can work in different labs. With one lab, selection is automatic. With multiple labs, the agent presents the available names and asks which one to use. Labs provide workspace and runtime isolation, not separate authorization; the configured MCP token grants access to every lab.

Lab URLs are direct: a lab with base path lab1 runs at /lab1/, not under a /labs/ prefix. The first lab initially uses /; when a second lab is created, an automatically assigned root route changes to the first lab's name. When deletion leaves one stopped automatically routed lab, it returns to /. Explicit route choices are never changed silently.

Complete labs can be downloaded or uploaded as ZIP archives from the authenticated browser configuration page. AI agents can use prepareLabExport and prepareLabImport to obtain short-lived, one-time direct transfer URLs, so ZIP bytes do not pass through MCP JSON or model context. LSP-Claw creates fast stored/uncompressed ZIPs and accepts stored or compressed imports. Imports are fully validated and staged; they support only creation of a new named lab or explicitly confirmed replacement of a stopped lab, never file merging. See Lab Archives.

When the source and destination are different configured LSP-Claw MCP servers, the agent calls prepareLabTransfer on the source and importLabTransfer on the destination. The destination fetches the ZIP directly from the source after the user confirms the exact source origin. The two persistent MCP tokens remain separate and are never forwarded between servers.

This supports a hybrid workflow: develop and test the application with Mako, then transfer the complete lab to an Xedge server running on the target RTOS.

The following diagram illustrates how a developer can use an AI agent running on a local computer to develop, test, and debug software directly on an embedded device over the local network. The AI agent communicates with a cloud-based large language model (LLM) for reasoning and code generation, while the embedded device runs Mako Server/Xedge with an integrated MCP server that exposes device functionality and runtime feedback to the agent.

flowchart TB
    subgraph Cloud["Cloud"]
        LLM["LLM"]
    end

    subgraph Local["Local Network"]
        Agent["AI agent, e.g. Codex"]

        subgraph Device["Embedded Device / MCU"]
            RT["Mako Server / Xedge"]
            MCP["LSP-Claw running inside Mako/Xedge"]
        end
    end

    Agent <--> LLM
    Agent <--> MCP
    MCP <--> RT

Once connected, the AI agent can ask LSP-Claw questions such as what runtime is available, what files are in the lab, which examples may be useful, and what trace output appeared while testing.

The following screenshot shows part of the Codex AI agent's user interface when running the SMQ example prompt in this tutorial. Codex not only created the web-app, but also tested it. The embedded Codex browser can be used to manually test the UI.

Codex Screenshot

Examples and Tutorials

Download or Build LSP-Claw

cd www
zip -D -q -u -r -9 ../lsp-claw.zip .

The test harnesses are for Windows.

Running LSP-Claw

Using Mako with or without Xedge

For Mako users, install the Mako Server Development Package first unless you already have a working Mako environment. It is the recommended package because it provides a complete Mako development setup for running and testing LSP-Claw.

When using Mako Server, you can optionally combine LSP-Claw with Xedge. Xedge supports executing .xlua files, which are small, self-contained applications that can be started or restarted automatically when the AI agent saves or updates the file. This lets the AI agent develop and test applications without restarting the entire lab application, so other .xlua applications running in the lab can continue uninterrupted.

Command Line Examples

mako # Starts LSP-Claw and Xedge when using the mako.zip developer edition.
mako -l::lsp-claw.zip # No Xedge, MCP URL http://localhost/mcp.lsp
mako -llsp-claw::lsp-claw.zip # No Xedge, MCP URL http://localhost/lsp-claw/mcp.lsp
mako -l::Xedge.zip -l::lsp-claw.zip # Include Xedge, MCP URL http://localhost/mcp.lsp
mako -l::Xedge.zip # Only Xedge, MCP URL http://localhost/lsp-claw/mcp.lsp

On the first Mako start, you may add -token to initialize MCP authentication. See Command-Line MCP Token.

In the last example, LSP-Claw is not loaded when Mako Server starts. Instead, LSP-Claw is installed as an Xedge application the first time Xedge runs. For this option, follow the same installation procedure used for the standalone Xedge/RTOS deployment described below.

See the Mako Server Getting Started Guide for more information on installing and running Mako Server.

Xedge Standalone (RTOS)

When Xedge is packaged in standalone mode, which is common for RTOS deployments, LSP-Claw must be installed as an Xedge application the first time Xedge starts.

Installing LSP-Claw

  1. Open the Xedge IDE in your browser.
  2. Click the menu button in the top-right corner.
  3. Select App Upload.
  4. Drag and drop lsp-claw.zip into the uploader.
  5. Click Save without enabling unpacking.

See the Xedge app installation video in the tutorial Xedge Application Deployment for more information.

lsp-claw.zip includes an Xedge .config file that automatically:

  • Starts the application.
  • Configures the application base URL as:
http://ip-address/lsp-claw/

The MCP server endpoint will therefore be:

http://ip-address/lsp-claw/mcp.lsp

Configure Tokens

LSP-Claw can use two optional tokens:

  • GITHUB_TOKEN: used by LSP-Claw when accessing the RealTimeLogic/LSP-Examples GitHub repository. This helps avoid GitHub API rate limits. See creating a personal access token for details.
  • MCP_AUTH_TOKEN: used to protect the LSP-Claw MCP endpoint. When this token is configured, AI agents must include it when connecting to mcp.lsp.

The GitHub token is for outbound GitHub access only. It does not authenticate MCP clients. The MCP authentication token is what protects the MCP server.

Web Token Configuration (Preferred)

The easiest way to configure either token is the LSP-Claw browser page:

http://localhost/lsp-claw-config.lsp

If LSP-Claw is installed under the packaged Xedge base URL, or if you are using the mako.zip Developer Edition, use:

http://localhost/lsp-claw/lsp-claw-config.lsp

Requests to the application root redirect to the lsp-claw-config.lsp page. The configuration page lets you set either token, both tokens, or neither token. It validates a GitHub token before saving and stores both tokens encrypted using key material derived from the host device. A valid GitHub token takes effect immediately without restarting LSP-Claw.

When an MCP token is configured, use it to sign in to this page. The resulting browser session does not authorize MCP requests; AI agents must still send the same token as an HTTP bearer token. LSP-Claw keeps this browser authorization separate from any Xedge or FuguHub login on the same server.

Both tokens are optional. Without a GitHub token, public examples remain available, but GitHub API requests may be rate limited. Without an MCP token, any client that can reach the MCP endpoint can use it.

The same page provides these lab-management controls:

  • The lab's direct base URL and current running or stopped state.
  • Start lab or Stop lab for each named lab.
  • Download ZIP for exporting a complete lab to the user's file system.
  • Upload and import ZIP for creating a named lab or completely replacing a stopped lab after explicit confirmation.

Protect a New Remote Installation

If the configuration page will be exposed to an untrusted network on first start, initialize the MCP token before opening the page. The GitHub token can still be added later through the UI. Mako provides two initialization methods.

Command-Line MCP Token

The optional -token argument initializes the encrypted MCP bearer token:

mako -l::lsp-claw.zip -token your-mcp-bearer-token

The token must contain 16 to 4096 bytes and cannot contain NUL, CR, or LF. Once an MCP token exists, later -token arguments are ignored and cannot replace it.

See Command-Line MCP Token for validation and storage details.

Environment MCP Token

Alternatively, set MCP_AUTH_TOKEN before the first Mako start. For Linux:

MCP_AUTH_TOKEN='your-mcp-bearer-token'
mako -l::lsp-claw.zip

For Windows:

set MCP_AUTH_TOKEN = 'your-mcp-bearer-token'
mako -l::lsp-claw.zip

LSP-Claw imports and encrypts the environment token. Remove the environment variable after the successful first start unless it is intentionally managed by the service environment; a value left in the environment takes precedence again on later starts.

Configure Your AI Agent

In the following examples, the MCP URL assumes that LSP-Claw is running as a root application. If you plan to develop web applications, configure a dedicated base URL as explained above to avoid URL conflicts with the lab app, which also runs as a root app. When LSP-Claw is installed as a packaged Xedge application, the MCP server URL is: http://ip-address/lsp-claw/mcp.lsp.

First make sure the LSP-Claw server is running and reachable from the machine running your AI agent. When LSP-Claw runs as a root application, the default endpoint is:

http://localhost/mcp.lsp

If LSP-Claw is running on another machine, replace localhost with that host name or IP address.

Start the LSP-Claw MCP server before starting the AI agent or opening a new AI session. Most AI agents discover MCP tools only at startup, so a server that is started later may not become visible until the AI agent is restarted.

Every AI agent has its own configuration format. As one concrete example, in Codex you can add the server to your Codex config.toml file. Common locations are:

Codex Example

Windows: C:\Users\<you>\.codex\config.toml

Add this section. If you already have an MCP server entry for this same URL, you can reuse that entry instead of adding a duplicate.

[mcp_servers.lsp_claw]
url = "http://localhost/mcp.lsp"
enabled = true
startup_timeout_sec = 10
tool_timeout_sec = 30

If LSP-Claw is configured with MCP_AUTH_TOKEN, add a bearer token environment variable to the same server entry:

[mcp_servers.lsp_claw]
url = "http://localhost/mcp.lsp"
enabled = true
startup_timeout_sec = 10
tool_timeout_sec = 30
bearer_token_env_var = "LSP_CLAW_MCP_TOKEN"

Then set LSP_CLAW_MCP_TOKEN to the same value as the LSP-Claw MCP_AUTH_TOKEN before starting Codex. LSP_CLAW_MCP_TOKEN configures the Codex client only; it does not set or change the token stored by LSP-Claw.

For a remote server, use the remote URL instead:

url = "http://192.168.1.50/mcp.lsp"

Develop on Mako, Transfer to Xedge/RTOS

A practical embedded workflow is to develop and test the application with Mako first, then move it to Xedge on the target RTOS. Install LSP-Claw on both systems and configure each one as a separate MCP server. The servers normally use different bearer tokens:

[mcp_servers.lsp_claw_mako]
url = "http://192.168.1.50/lsp-claw/mcp.lsp"
enabled = true
startup_timeout_sec = 10
tool_timeout_sec = 60
bearer_token_env_var = "LSP_CLAW_MAKO_TOKEN"

[mcp_servers.lsp_claw_xedge]
url = "http://192.168.1.51/lsp-claw/mcp.lsp"
enabled = true
startup_timeout_sec = 10
tool_timeout_sec = 60
bearer_token_env_var = "LSP_CLAW_XEDGE_TOKEN"

Set each environment variable to the token configured on that server. Codex coordinates the transfer, but LSP-Claw never forwards either persistent token to the other server.

The agent transfers the complete lab directly between the two servers. The ZIP does not pass through the model. The destination import creates a new lab or, after confirmation, replaces a stopped lab; it does not merge source files into an existing lab.

Restart the AI agent after changing its config, or start a new session so it loads the new MCP server.

Ask the agent to inspect both servers before transferring anything:

Use the Mako LSP-Claw server as the source and the Xedge LSP-Claw server as the
destination. Show me the source lab and destination state, then ask for
confirmation before transferring the complete lab to Xedge. Start and test the
transferred lab on Xedge and report any platform compatibility problems.

The agent uses prepareLabTransfer on Mako and importLabTransfer on Xedge. The destination fetches the archive directly after you confirm the source and target.

First Useful Prompt

A useful first prompt should tell the AI agent what you want, where it should work, and how careful it should be with existing lab files.

  • What you want to build.
  • Whether to target Mako or Xedge, or ask it to check first.
  • Whether to start from an example or from a blank lab app.
  • How it should test the result.
  • Whether it may overwrite existing lab files.

Starter Prompt

This prompt is for priming the AI agent to use LSP-Claw correctly before you ask it to build anything. It is not a command-line script. Use it at the start of a session, especially if you may later paste tutorial text or prompts that include setup commands intended for a human terminal.

Use LSP-Claw for this session.

First check the runtime and lab status. Tell me whether the lab is running on
Mako or Xedge, and list any existing lab files.

Work only through the LSP-Claw MCP tools and the lab app. Do not edit my local
workspace, run local shell commands, start Mako, stop Mako, or follow
command-line setup instructions unless I explicitly ask you to work outside
LSP-Claw.

I may paste prompts, examples, or tutorial text that include command-line
instructions such as cd, mako, or environment-variable setup. Treat those as
human setup notes, not as commands for you to execute. Use LSP-Claw to inspect,
modify, run, and debug the lab. If LSP-Claw tools are unavailable, stop and tell
me instead of falling back to local files.

The following prompt requires Xedge. It checks whether the AI agent can write a simple example and inspect the printed results.

Create a simple .xlua file that sets up a timer to print a message
every second for 5 seconds, then executes it. Inspect the printed
output and tell me what it is.

Manage Multiple Named Labs

Labs isolate files, runtime state, backups, and routes. They share the server's MCP authentication token, so they are separate workspaces rather than separate security domains. Each AI session selects its own active lab.

To inspect the choices without changing anything:

Use LSP-Claw to list all labs on this server. Show them as a numbered list with
their base URLs and running states. Do not select, start, stop, or modify a lab
until I choose one.

To work in a specific existing lab:

Use the lab named router-demo for this session. Show its status and files before
making changes. Do not start, stop, or modify any other lab.

To create a new independent lab:

Create a new lab named router-demo, select it for this session, and show me its
assigned URL. Do not copy or modify files in any existing lab.

Lab names are unique. When only one lab exists, LSP-Claw selects it automatically. When multiple labs exist and the prompt does not identify one, the agent should list them and ask instead of guessing.

Renaming or deleting a lab requires it to be stopped and requires explicit confirmation. Deleting a lab also deletes all of its backups.

Back Up a Lab

If a backup prompt does not include an exact backup name, the agent must ask for one before it performs the backup. For example:

Back up the lab named router-demo before I make more changes.

The expected next step is a question asking for the backup name. Answer with an exact name:

Use the backup name before-router-change.

You can also provide everything in the first prompt:

Back up the lab named router-demo as before-router-change. Do not clear or
modify the lab after creating the backup.

To restore, first ask for the available choices:

List the backups for the lab named router-demo as numbered choices. Do not
restore anything yet.

Then select and explicitly confirm replacement of the current lab:

Restore backup 1 into router-demo. I confirm that the current lab will be
replaced by the selected backup. Leave the restored lab stopped.

Change a Lab URL

Changing a lab's direct base path requires the lab to be stopped and requires explicit confirmation:

Stop the lab named router-demo and change its base path to demo. I confirm this
route change. Then show me the new absolute application URL, but do not start
the lab yet.

Export, Import, and Transfer Complete Labs

Complete-lab operations use ZIP snapshots rather than copying individual files through the model. LSP-Claw-generated ZIPs are stored without compression and preserve file timestamps. Imports accept stored or compressed ZIPs.

Download a Lab to the User's File System

An agent such as Codex can use the one-time export URL to save the ZIP directly when it has access to the requested destination path:

Download the complete lab named router-demo as a ZIP to
C:\Users\me\Downloads\router-demo.zip. Use LSP-Claw's complete-lab export; do
not read and copy the files individually or place ZIP bytes in the chat.

If the agent cannot write to the user's file system, open lsp-claw-config.lsp in a browser and click Download ZIP for that lab.

Import a ZIP as a New Lab

The destination lab name must be provided by the user:

Import C:\Users\me\Downloads\router-demo.zip into LSP-Claw as a new lab named
router-demo-copy. Do not replace or merge with an existing lab. After import,
show its assigned URL and leave it stopped.

To replace an existing lab, it must be stopped and the prompt must explicitly confirm complete replacement:

Stop the lab named router-demo-copy, then completely replace it from
C:\Users\me\Downloads\router-demo.zip. I confirm complete replacement of
router-demo-copy. Do not merge old and new files.

Transfer Directly Between Two LSP-Claw Servers

When both servers are configured as separate MCP entities, ask the agent to use the direct ZIP transfer instead of relaying files:

Copy the complete lab named router-demo from lsp_claw_1 to a new lab named
router-demo-copy on lsp_claw_2. Use LSP-Claw's direct server-to-server ZIP
transfer, not per-file copying. Show me the exact source origin reported by the
destination and wait for my confirmation before it fetches the ZIP.

The destination intentionally stops at a confirmation gate. After checking the reported origin, continue with a separate response such as:

Yes, http://192.168.1.50 is the expected source origin. Continue the transfer.

The source snapshot and transfer ticket are short-lived and single-use. If the transfer expires or fails, the agent must prepare a new snapshot rather than reusing the previous ticket.

Start from an Example

When you ask the AI agent to build something with LSP-Claw, you can choose one of two paths:

Starting from an example is useful when your goal resembles an existing pattern, such as a dashboard, form, AJAX endpoint, REST API, WebSocket app, or SMQ app. The AI agent can look through the examples, recommend a starting point, and copy only the part that should run in the lab.

Use LSP-Claw to build a device management interface from
Light-Dashboard/custom. Check the lab, ask what pages, data, commands, and
visual style I need, and ask before replacing existing files.

The suggested example may not always be the best fit. Use critical thinking and ask the AI agent to explain why an example is a good starting point before it copies anything.

Examples are accelerators, not a requirement. If your request is already small and specific, such as a single form or one JSON endpoint, it may be clearer to build from scratch.

For larger work, it can also help to keep a local project directory with the Barracuda App Server's AGENTS.md file. This gives the AI agent stable project guidance while LSP-Claw handles the running lab app.

After the AI agent recommends an example, you can continue with:

Back up the selected lab, then clean it. Ask me for the exact backup name before
doing anything.

You can also ask it to clean all files or copy new files without deleting the current lab.

Build a Small LSP Page

Use this when you already know what you want and do not need an example.

Use LSP-Claw to build a new LSP app from scratch. Create a
single index.lsp page that shows a hit counter. Keep it small and compatible
with BAS/Lua. Start the lab, open the page, and fix any server-side errors.
Tell me how to navigate to it.

For simple tutorial-sized apps, this direct approach is often better than starting from a larger example.

If this is the only lab and it retains the default root route, the application URL is http://localhost/. With multiple labs, use the labApp.appUrl returned by startLab, such as http://localhost/lab1/.

If you are running standalone Xedge or Xedge through Mako Server, navigate to http://localhost/rtl/ to open Xedge. Expand the app named for the selected lab (for example, $lab1) and click index.lsp to view the code. The Xedge UI running in the browser is unaware of server-side changes, so refresh it to see changes made by LSP-Claw.

HTML Form Tutorial

This pattern is the easiest way to understand browser-to-server interaction: the browser submits a normal form, and the LSP page handles the request.

Clear the lab and build an LSP app with index.lsp containing an HTML
form for a simulated LED. On GET, show the current LED state. On
POST, read the submitted form value and update the state. On the
server side, print the status with trace(). Start the lab
and test both turning the LED on and off.

The AI agent should automatically test the app. If something does not work, ask the AI agent to debug it:

The form is loading, but the state is not changing. Use LSP-Claw trace
output to find the problem by instrumenting the code, fix it, and
remove any temporary debug output before finishing.

If you are new to LSP, open the file and study the design. The AI agent should create a standard server-rendered page with a submit button. You can then ask the AI agent to use JavaScript instead.

AJAX Example

In index.lsp, remove the submit button and update the UI to use
JavaScript to automatically send the state to the server when the user
clicks the UI.

GPIO Example

If you are running LSP-Claw on an ESP32 using Xedge32, try the following prompt.

I have an LED connected to GPIO 1. In index.lsp, use the ESP32 GPIO
API to turn the LED on and off when the user clicks the UI.

Small REST API Tutorial

The GitHub repo includes a REST module. The following prompt should download and use this module.

Back up and clear the lab.
Use LSP-Claw to build a small REST API based on the REST example and
the REST module. If the lab already contains files, stop and ask
before copying anything. Start the lab and test:
- GET /api/users
- POST /api/users with a JSON body containing name and email
- GET /api/users/{id}
- PUT /api/users/{id} with a JSON body containing name and email
- DELETE /api/users/{id}
Return JSON and appropriate HTTP status codes.
Create an index.html using the fetch API to test the REST API.

Timer-Driven Status Page

Use this for background status updates, simulated sensor readings, or periodic maintenance.

Back up and clear the lab.
Create a lab app with .preload and index.lsp. In .preload, start a timer that
updates a simulated temperature value once per second. index.lsp should display
the latest value. Start the lab and confirm the value changes over time.

Important constraint:

Do not create a busy loop. Use the BAS timer API for repeated work.

Using SMQ WebSockets

When we tested the above prompt, the AI agent created an index.lsp page that polled the server for updates with <meta http-equiv="refresh" content="2">.

You can update the code to use WebSockets instead, but an even better solution is to use the SMQ protocol.

Remove the polling code and use the SMQ protocol to update the UI
instead. Install an SMQ broker in the .preload script and redirect
connection requests from index.lsp to the broker in the .preload
script. Create an SMQ client using the SMQ broker API and publish
the timer updates from this server-side client using the topic
/temperature/

Real-Time Browser Updates

Use LSP-Claw to build a real-time device dashboard from
Light-Dashboard/custom. Add a page that shows a simulated sensor value updating
once per second and a device command control. Preserve the dashboard's HTMX and
SMQ design, then start and test the lab.

Debugging

When the app does not behave correctly, the most useful feedback is the server trace output. Ask the AI agent to use it directly:

The app is not behaving correctly. Use BAS trace output to debug it.
Add temporary trace messages only if they help. Run the page again, inspect the
trace output, fix the bug, and remove temporary traces that are no longer useful.

Do not ask the AI agent to trace sensitive data such as:

  • Tokens or passwords.
  • Authorization headers or cookies.
  • Large request bodies.
  • Private user data.

Remote Server Usage

If LSP-Claw is running on another machine, make that explicit in the prompt. This prevents the AI agent from assuming it can use local filesystem paths or a local console.

The LSP-Claw MCP server is running on a remote BAS host. Use only LSP-Claw MCP
tools to inspect, modify, run, and debug the lab app. Do not assume you can use
local files from my computer. Check the lab first, make the requested changes,
start the lab, and use trace output for debugging.

Finishing Checklist

Ask the AI agent to finish with a short report:

When finished, summarize:
- Files created or changed.
- Runtime detected.
- How you tested the app.
- Any trace findings that mattered.
- Any remaining limitations.
- Whether temporary debug traces were removed or intentionally kept.

Troubleshooting Setup

If your AI agent cannot see LSP-Claw:

  • Confirm the LSP-Claw server is running.
  • Check that http://localhost/mcp.lsp is reachable from the same machine running the AI agent, or use the remote host URL if the server is not local. It may not render a normal web page; the important part is that the server responds. A 204 No Content response is still a valid sign that the endpoint is alive.
  • Confirm the server entry is present in your AI agent configuration. For the Codex example above, that is the [mcp_servers.lsp_claw] section in your .codex/config.toml file.
  • Start the LSP-Claw MCP server before starting the AI agent.
  • Restart the AI agent after editing the config or after starting a server that was not running when the AI agent first opened.
  • Ask the AI agent to check the runtime and lab status before asking it to build anything.

If the endpoint responds but the AI agent still cannot see LSP-Claw tools, the AI agent probably discovered its MCP servers before LSP-Claw was available. Restart the AI agent or open a new session.