Click on "Install 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., "@CarlaMCP Run an aggressive cut-in from the right at 120 km/h with 1.2s TTC"
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.
Natural language → executable autonomous-vehicle scenarios in the CARLA simulator, exposed to any LLM through the Model Context Protocol.
Built on the tool-based architecture of IROSA, validated against CARLOS for containerized deployment.
A prompt like "an aggressive cut-in from the right at highway speed in heavy rain at night" becomes a validated, reproducible scenario that runs in CARLA — and can be saved as a spec for replay.
NL prompt ─▶ LLM picks tools ─▶ validated ScenarioManifest ─┬─▶ execute in CARLA ─▶ ScenarioResult
(Pydantic primitives) │
└─▶ save .json spec ─▶ replay / reuseThree layers, each independently testable:
Layer | Package | Responsibility |
Primitives |
| Pydantic models with LLM-facing descriptions, range constraints, and cross-field validators. The LLM never writes raw simulator code. |
Executors |
| Translate validated primitives into |
Server |
| The MCP server exposing tools to the model. |
Related MCP server: HUTB Simulator MCP Server
CarlaMCP/
├── carlamcp/
│ ├── config.py # connection + simulation/spawn constants
│ ├── enums.py # CARLAMap, Side, WeatherCondition
│ ├── results.py # ScenarioResult
│ ├── carla_client.py # CARLA binding import + get_client()
│ ├── world.py # map / actor / sync-mode / find_ego helpers
│ ├── storage.py # save / load scenario specs (export & replay)
│ ├── primitives/ # one file per primitive + the manifest
│ │ ├── cut_in.py pedestrian.py weather.py manifest.py
│ ├── executors/ # one executor per primitive + the orchestrator
│ │ ├── cut_in.py pedestrian.py weather.py manifest.py
│ └── server.py # FastMCP server + tools + main()
├── tests/ # pytest suite, runs WITHOUT a simulator
│ ├── fakes.py conftest.py test_executor.py test_primitives.py
├── pyproject.toml requirements.txt .gitignore LICENSE README.md~/carla/CarlaUE4.sh -RenderOffScreen -quality-level=Low &cd CarlaMCP
pip install -e ".[dev]" # package + test deps (no simulator needed)
pip install -e ".[carla,dev]" # also installs the carla==0.9.15 bindingpython -c "from carlamcp.carla_client import get_client; print(get_client().get_server_version())"python -m carlamcp.server # or just: carlamcpAdd to your claude_desktop_config.json (use the absolute path to your clone):
{
"mcpServers": {
"carlamcp": {
"command": "python",
"args": ["-m", "carlamcp.server"],
"cwd": "<path-to-your-CarlaMCP-clone>"
}
}
}Restart Claude Desktop; the CarlaMCP tools will appear.
Once connected, talk to the model:
"Check if CARLA is running" → get_status
"Run an aggressive cut-in from the right at 120 km/h with 1.2s TTC" → run_scenario
"Pedestrian crosses 25 m ahead, occluded by a parked car, in heavy fog"
"Set the weather to rain_night at intensity 0.8" → set_weather
"Validate this manifest before running it: {...}" → validate_scenario
Tool | Purpose |
| Check the simulator is reachable. |
| List supported towns and their characteristics. |
| Build + validate + execute a scenario (optional |
| Apply a weather preset only. |
| Validate a manifest JSON without running it. |
| Validate and persist a manifest for later. |
| Load a saved spec and execute it. |
Primitive | Key parameters | Default map |
|
| Town04 (motorway) |
|
| Town03 (urban) |
|
| Any |
Any scenario can be persisted as a validated JSON spec and re-run later — useful for regression sets, sharing, and scenario inpainting / augmentation pipelines:
run_scenario("...", cut_in_speed_kmh=120, cut_in_ttc_s=1.2, cut_in_side="right",
save_as="rainy_cutin") # writes scenarios/rainy_cutin.json
replay_scenario("rainy_cutin") # re-executes the exact same specThe export layer (carlamcp/storage.py) is deliberately decoupled from
execution, so generated specs can be consumed by downstream tooling without a
running simulator. See Roadmap → OpenSCENARIO export.
The suite runs entirely offline — tests/conftest.py injects a fake carla
module so the executor logic (spawn geometry, velocities, ordering, error paths,
collision metric) is verified without a GPU or a running simulator. This makes
it CI-friendly.
pip install -e ".[dev]"
pytest -qtests/test_executor.py doubles as the canonical example of the project's
Google-style (Sphinx Napoleon)
docstring convention used across every module.
CARLA runs on Unreal Engine (C++), so it's a fair question. For CarlaMCP, C++
buys nothing: the carla PyPI package is a thin binding over the C++
LibCarla client, and everything done here (spawning actors, weather, the
traffic manager) is fully exposed in Python with negligible overhead at these
tick rates. C++ only becomes worthwhile for work that lives inside the CarlaUE4
server build — custom Unreal sensors/actors/map assets, per-frame
high-bandwidth sensor processing where the GIL is the bottleneck, or C++
ScenarioRunner extensions. None of those are on the roadmap, so CarlaMCP stays
pure Python.
Phase 1 — Validated primitives + MCP server + CARLA execution
Phase 2 — Modular package, offline test suite, scenario export/replay
Phase 3 — CARLOS Docker integration (docker-compose.yml)
Phase 4 — CSR/ISR/TCR evaluation harness
Phase 5 — OpenSCENARIO export for the CARLOS replay pipeline
Paper — IEEE IV / ITSC submission
IROSA — tool-based LLM architecture for robot skill adaptation (DLR/TUM)
CARLOS — containerized CARLA simulation framework (ika RWTH Aachen)
SUMO-MCP — MCP for traffic simulation (adjacent domain)
MIT.
Check whether the CARLA server is reachable and return version info.
Always call this first before running scenarios.
Returns:
dict: carla_available/ready flags plus version info or an error
hint describing how to start the simulator.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return value (carla_available/ready flags plus version info or error hint) and implies read-only behavior. With no annotations, this is good but could mention no side effects.
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?
Three sentences with zero wasted words: purpose, usage tip, and return description. Front-loaded and efficient.
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 simple status-check tool with no output schema and no annotations, the description covers purpose, usage context, and return format completely.
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?
No parameters exist and schema coverage is 100%, so no additional parameter info needed. Baseline 4 applies; description correctly omits any.
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?
Description specifies exact action: checking CARLA server reachability and returning version info. Clearly distinguishes from sibling tools that deal with maps, scenarios, and weather.
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?
Explicitly states 'Always call this first before running scenarios,' providing clear when-to-use guidance. No alternatives needed as it's a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the CARLA maps supported by CarlaMCP.
Returns:
dict: A maps mapping of map name to a short description of its
characteristics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 return format (a dict with 'maps' mapping), which is helpful and goes beyond a bare statement. However, it does not mention side effects or permissions, though for a read-only list this is less critical.
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 brief but includes a Python-style return format that may be less intuitive. It is not excessively long, but the structure could be more streamlined for an AI agent. Every sentence serves a purpose, but the return documentation could be clearer.
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 simple list tool with zero parameters and no output schema, the description provides complete context: what it does and what it returns. No essential information 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?
There are zero parameters and schema coverage is 100%, so the description need not add parameter details. Baseline is 4 according to rubric, and the description correctly omits parameter info.
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?
Description clearly states it lists CARLA maps supported by CarlaMCP. Specific verb 'List' and resource 'CARLA maps', making the purpose unambiguous. No siblings overlap, so differentiation is naturally clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose statement but does not explicitly state when to use or exclude alternatives. Given no parameters and no competing tools for listing, guidance is minimal but acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a previously saved scenario spec and execute it.
Args:
path (str): Saved scenario name or path (e.g. "demo" or
"scenarios/demo.json").
Returns:
dict: The execution result, or {"error": ...} if the spec could not
be loaded.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that execution may fail with an error and specifies the return format, but with no annotations provided, it does not fully disclose potential side effects or safety profile (e.g., whether it modifies state).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded summary and structured Args/Returns sections, each sentence earning its place without redundancy.
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 simple single parameter and lack of output schema, the description covers the main purpose, parameter usage with examples, and expected return value, but could mention prerequisites or result structure in more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the single parameter 'path' by providing an example and clarifying it can be a name or file path, which goes well beyond the schema's bare 'string' type.
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 'Load a previously saved scenario spec and execute it,' using specific verbs and resource, and the tool name 'replay_scenario' implies replaying a saved one, distinguishing it from siblings like 'run_scenario' and 'save_scenario'.
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 clear context for when to use the tool (to load and execute a saved scenario) and implies usage via the parameter description, but does not explicitly exclude alternatives or provide when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate and execute a CARLA scenario from natural language.
Builds a validated :class:ScenarioManifest from flat parameters and runs
it. At least one of the cut_in_*, pedestrian_*, or weather_*
groups must be provided. Optionally persists the validated spec for replay.
Args:
nl_prompt (str): The natural-language description of the scenario.
cut_in_speed_kmh (Optional[float]): See :func:_build_manifest.
cut_in_ttc_s (Optional[float]): See :func:_build_manifest.
cut_in_side (Optional[str]): See :func:_build_manifest.
cut_in_ego_speed_kmh (float): See :func:_build_manifest.
cut_in_map (str): See :func:_build_manifest.
pedestrian_gap_s (Optional[float]): See :func:_build_manifest.
pedestrian_distance_m (Optional[float]): See :func:_build_manifest.
pedestrian_occluded (bool): See :func:_build_manifest.
weather_condition (Optional[str]): See :func:_build_manifest.
weather_intensity (Optional[float]): See :func:_build_manifest.
save_as (Optional[str]): If given, save the validated spec under this
name for later replay.
Returns:
dict: The execution result, or an error/hint payload if
validation failed.
Examples: Aggressive cut-in from the right at 120 km/h::
run_scenario("...", cut_in_speed_kmh=120, cut_in_ttc_s=1.2,
cut_in_side="right")
Occluded pedestrian crossing 30 m ahead::
run_scenario("...", pedestrian_gap_s=1.5, pedestrian_distance_m=30,
pedestrian_occluded=True)
| Name | Required | Description | Default |
|---|---|---|---|
| nl_prompt | Yes | ||
| cut_in_speed_kmh | No | ||
| cut_in_ttc_s | No | ||
| cut_in_side | No | ||
| cut_in_ego_speed_kmh | No | ||
| cut_in_map | No | Town04 | |
| pedestrian_gap_s | No | ||
| pedestrian_distance_m | No | ||
| pedestrian_occluded | No | ||
| weather_condition | No | ||
| weather_intensity | No | ||
| save_as | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses building, running, and optional persistence, and returns error/hint on validation failure. Missing details on execution side effects (e.g., simulation impact, resource usage, or destructiveness).
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?
Well-structured with summary, task, Args, Returns, and Examples. Front-loaded with purpose. However, the Args section is repetitive with 'See :func:`_build_manifest`' for multiple parameters, reducing conciseness.
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 12 parameters and no output schema, the description covers required groups, basic return format, and examples. Lacks details on success response structure or possible error states beyond validation, and does not explain how this tool interacts with the simulation environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds value with Args section and examples showing parameter grouping. However, many Args just reference '_build_manifest' without actual semantics, and no enum constraints are described despite their presence.
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 'Generate and execute a CARLA scenario from natural language,' specifies building a validated ScenarioManifest and running it, and distinguishes from siblings like validate_scenario and replay_scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly requires at least one parameter group (cut_in_*, pedestrian_*, weather_*), provides option to persist for replay, and implies execution vs. validation or replay. However, it does not explicitly state when to use this tool over siblings like validate_scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and persist a scenario manifest for later replay.
Args:
manifest_json (str): JSON string of a :class:ScenarioManifest.
name (str): Short name to save under (stored as scenarios/<name>.json).
Returns:
dict: {"saved": True, "path": ...} on success, or
{"saved": False, "error": ...} if validation failed.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_json | Yes | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses validation and persistence, return dict structure, and storage path. However, it does not mention whether overwriting existing files occurs, permissions required, or detailed error scenarios.
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?
Description is concise: one sentence for purpose, then structured Args and Returns. No wasted words. Every sentence adds value.
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?
Covers purpose, parameter details, and return values. Lacks information on overwrite behavior, validation criteria beyond 'valid', and relationship with validate_scenario sibling. Missing details for a save tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema only provides 'string' type for both parameters. Description adds meaning: manifest_json is a JSON string of a ScenarioManifest, and name is stored under 'scenarios/<name>.json'. This is helpful and compensates for 0% schema coverage.
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 it validates and persists a scenario manifest for later replay. It distinguishes from sibling tools like validate_scenario (which likely only validates) and replay_scenario, but could be more explicit about the unique combination of validation and persistence.
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?
No explicit guidance on when to use this tool versus alternatives like validate_scenario or run_scenario. The purpose implies saving, but there is no 'use this when...' or 'instead of...' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a weather condition to the world without spawning agents.
Args:
condition (str): One of clear, rain, fog, night,
rain_night.
intensity (float): Severity from 0.0 (minimal) to 1.0 (maximum).
Returns: dict: The execution result.
| Name | Required | Description | Default |
|---|---|---|---|
| condition | Yes | ||
| intensity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses that it does not spawn agents and returns a dict execution result. However, it does not cover potential side effects, authorization needs, or persistence of the weather condition.
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 a clear purpose sentence followed by Args and Returns sections. It is concise but includes necessary details; a slightly shorter format could improve conciseness.
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 simplicity (2 parameters, no output schema), the description covers purpose and parameters adequately. However, it does not explain error handling, out-of-range behavior, or the exact structure of the execution result dict.
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?
With 0% schema description coverage, the description fully compensates by enumerating valid condition values ('clear', 'rain', etc.) and specifying intensity as a float from 0.0 to 1.0, enabling correct parameter selection.
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 action ('Apply a weather condition') and the resource ('to the world') with a distinguishing scope ('without spawning agents'), differentiating it from sibling tools that likely involve agents.
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 lists valid conditions and intensity range, implicitly guiding usage, but lacks explicit when-to-use or when-not-to-use guidance compared to sibling tools. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a scenario manifest JSON without executing it.
Args:
manifest_json (str): JSON string of a :class:ScenarioManifest.
Returns:
dict: {"valid": True, "manifest": ..., "primitives": [...]} on
success, or {"valid": False, "error": ...} on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_json | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses behavior (validation only, no execution) and specifies exact return format for success and failure, adding significant behavioral context.
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 minimal and well-structured with Args and Returns sections, containing only necessary information without redundancy.
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 single-parameter validation tool without output schema, the description adequately covers parameter and return details, though could mention scope of validation (e.g., structural vs semantic).
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?
With 0% schema description coverage, the description adds essential meaning by explaining manifest_json is a JSON string of a ScenarioManifest, going beyond the schema's type-only specification.
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 validates a scenario manifest JSON without executing it. This specific verb-resource combination distinguishes it from sibling tools like run_scenario and replay_scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies validation use case by stating 'without executing it,' but does not explicitly mention when to choose this tool over alternatives or provide exclusion criteria.
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. Dates show when Glama detected each change.
v0.1.0get_statuslist_mapsreplay_scenariorun_scenariosave_scenarioset_weathervalidate_scenarioEach tool has a clearly defined purpose with no overlap: server status, map listing, scenario generation from NL, replay, save, weather control, and validation. The pair run_scenario and replay_scenario are distinguished by input source (NL vs. saved spec).
All tools follow the verb_noun snake_case convention (get_status, list_maps, run_scenario, etc.), making the API predictable and easy to navigate.
Seven tools cover the essential operations for a CARLA simulation server: status check, map exploration, scenario lifecycle (create, save, replay, validate), and weather control. The count is well-scoped without redundancy.
The tool surface covers the core workflow (scenario generation, execution, replay, weather). Minor gaps include no tool to list or delete saved scenarios, but agents can work around by using the file system or naming conventions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MERCATOR Verify: evidence-backed verification and decision support for autonomous agents.
Task and planning workspace for humans collaborating with AI agents
Video scene understanding for AI agents via the Primate Vision API.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/codebymov/CARLA-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
