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., "@anylogicPLE-mcp Create a queueing model for a coffee shop with 2 baristas."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that generates AnyLogic simulation models from natural-language prompts in Claude Code.
Describe a queueing system, factory, or ER in plain language → get a .alp file that opens and runs in AnyLogic PLE (the free edition). Models are validated automatically against PLE limits.
The goal of this project is to shorten the AnyLogic learning curve by giving you a working simulation model as a starting point. Run the simulation, observe the results, study how the model is built, and use it as a reference when building your next model from scratch.
Unlike most tools that focus on a single modeling approach, AnyLogic supports three paradigms in one environment — discrete event, agent-based, and system dynamics — covering virtually any industrial engineering problem you can think of, from factory floors to hospital ERs to supply chains. On top of that, the free PLE edition makes it accessible to anyone learning simulation, and the block-based Process Modeling Library maps naturally to code generation.
Disclaimer: This project is not affiliated with or endorsed by AnyLogic. AnyLogic is a trademark of The AnyLogic Company. Generated models are subject to AnyLogic PLE's terms of use.
If you are an industrial engineer, this tool lets you prototype a queuing or process model in natural language and have something running within minutes — skipping the initial friction of block wiring and XML quirks, and getting straight to the questions that matter: utilization rates, bottlenecks, throughput.
The current version handles discrete event / queueing models well. Resource-constrained models (shift schedules, breakdowns, Seize/Release blocks) are not yet supported — that is where contributions are most welcome. Whether you want to add new block types, new templates, or improve the XML generation, your input is genuinely valuable and very much encouraged.
Related MCP server: FlexSim MCP Server
You type this in Claude Code:
Create a 3-stage CNC job shop model "CNCJobShop":
- Jobs arrive every 15 minutes (exponential)
- Roughing: 2 machines, triangular(8,12,18) min
- Semi-finish: 1 machine, triangular(8,12,16) min
- Finishing: 1 machine, triangular(5,8,12) min
Give me the .alp file.Claude calls the MCP tools, builds the .alp XML, saves the file to your output folder, and tells you which stage is the bottleneck. Open the file in AnyLogic PLE and click Run.
Python 3.10+
Claude Code (VS Code extension or CLI)
AnyLogic PLE 8.9.8 — free, to open and run generated models
pip install -e .Find the entry point path — you need it in the next step:
where anylogic-mcp # Windows
which anylogic-mcp # macOS / Linux.mcp.json in your working directoryCreate a file named .mcp.json in the folder you open in VS Code:
{
"mcpServers": {
"anylogic": {
"command": "/path/to/anylogic-mcp",
"args": [],
"env": {
"ALP_OUTPUT_DIR": "/path/where/alp/files/are/saved"
}
}
}
}Windows: use double backslashes in JSON paths:
"C:\\Users\\YourName\\AppData\\Local\\Programs\\Python\\Python312\\Scripts\\anylogic-mcp.exe"See WINDOWS_SETUP.md for a full step-by-step walkthrough.
Ctrl+Shift+P → Developer: Reload Window → click Allow when prompted to approve the anylogic server.
Verify the connection:
What are the AnyLogic PLE limits?Tool | What it does |
| Build and validate a model; returns a model ID |
| Write the |
| Re-check a stored model against PLE limits |
| Return all PLE restrictions |
| Upload to AnyLogic Cloud (requires API key) |
Template | Entity | Default config | Traffic intensity ρ |
| Truck | 3 loading docks | 0.75 |
| Customer | 1 server | 0.60 |
| Part | 2 machines in series (A→B) | 0.83 |
| Patient | triage + 3-doctor treatment | 0.88 |
Custom models (any entity name, any block chain, any parameters) are fully supported. See EXAMPLES.md for prompts covering manufacturing, service systems, and healthcare.
Block |
| Notes |
|
| Always use |
|
| Time unit: minutes; |
| — | Auto-inserted before every |
| — |
Critical gotcha:
exponential(10)means 10 arrivals per minute, not one per 10 minutes. A warehouse with trucks arriving every 20 minutes needsexponential(1.0/20.0).
Limit | Value |
Agent types | 10 |
Blocks per agent | 200 |
Dynamic agents | 50,000 |
Simulation time | 5 h (unlimited when using Process Modeling Library — all generated models use it) |
Launch AnyLogic PLE 8.9.8
File → Open → select the .alp file from ALP_OUTPUT_DIR
Click the green Run button
model_builder.py produces AnyLogic 8.9.8-compatible .alp XML. The block ItemNames
(e.g. Source = 1412336242928, Queue = 1412336242932) were extracted from a
ground-truth AnyLogic file — they must be exact or the model tree crashes on load.
Key invariants baked into the generator:
A Queue is auto-inserted before every Delay to buffer when server capacity is full
Queue capacity is set to 100,000 (default in AnyLogic is 100, which causes OOM on long runs)
interarrivalTime is always emitted in rate form: exponential(1.0/mean) not exponential(mean)
Parameter name is delayTime (not delay); time unit is MINUTE
TimePlot chart lives inside Main/Presentation/Level/Presentation, not in SimulationExperiment
├── src/anylogic_mcp/
│ ├── server.py # MCP server and tool handlers
│ ├── model_builder.py # .alp XML generator (core logic)
│ ├── ple_validator.py # PLE limit checker
│ └── cloud_client.py # AnyLogic Cloud upload (optional)
├── tests/
│ ├── test_model_builder.py # XML structure, parameters, chart correctness
│ └── test_ple_validator.py # PLE limit enforcement
└── pyproject.tomlRun the tests:
# Windows
set PYTHONPATH=src && python -m pytest tests/ -v
# macOS / Linux
PYTHONPATH=src pytest tests/ -vPull requests are welcome. The most useful additions:
New block types — Service, Seize/Release/ResourcePool for resource-constrained models.
The ItemNames are already in _ITEM_NAMES in model_builder.py; what's needed is the
parameter XML and connector wiring.
New templates — supply chain, logistics, pedestrian flow.
Fluid Library support — bulk/continuous flow (tanks, pipes) requires a different XML structure; the block ItemNames would need to be extracted from a ground-truth Fluid model.
Test coverage — every new block type needs XML invariant tests matching the pattern
in test_model_builder.py.
Set ANYLOGIC_API_KEY in the env block of .mcp.json:
"env": {
"ALP_OUTPUT_DIR": "...",
"ANYLOGIC_API_KEY": "your_key_here"
}Get a key at: https://cloud.anylogic.com/settings/api-keys
MIT — see LICENSE.
This project is not affiliated with or endorsed by AnyLogic. AnyLogic is a trademark of The AnyLogic Company. Generated models are subject to AnyLogic PLE's terms of use.
Create an AnyLogic simulation model that complies with PLE (Personal Learning Edition) limits. The model will be validated against PLE restrictions: max 10 agent types, max 200 blocks per agent, max 50,000 dynamic agents. Use this to create models that can be downloaded and run in free AnyLogic PLE.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the simulation model | |
| description | Yes | Brief description of what the model simulates | |
| model_type | No | Type of model to create (uses pre-built templates) | custom |
| template_params | No | Parameters for template models (e.g., num_docks, arrival_rate) | |
| agent_types | No | Custom agent types (for 'custom' model_type) | |
| auto_simplify | No | Automatically simplify model if it exceeds PLE limits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses PLE restrictions (max agent types, blocks, dynamic agents) but omits success/failure behavior, return values, side effects, or error handling.
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?
Two concise sentences: first states purpose and PLE compliance, second details restrictions and usage. No redundant information, front-loaded with key action.
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?
With no output schema and complex nested parameters, the description covers creation purpose and constraints but lacks return value details, error scenarios, or post-creation steps. Adequate for basic use but not fully complete for an AI agent.
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 100%, baseline is 3. The description adds value by explaining PLE limits and validation context not present in schema, such as max 10 agent types and auto-simplify behavior, improving parameter understanding.
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 creates an AnyLogic simulation model complying with PLE limits. It distinguishes from sibling tools like download, validate, get limits, and upload.
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 says 'Use this to create models that can be downloaded and run in free AnyLogic PLE,' indicating appropriate context. It does not explicitly exclude cases or name alternatives, but the context signals provide clear sibling tool differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get download information for running model in AnyLogic PLE locally. Returns the model file and instructions for opening in free AnyLogic PLE software.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | Local model ID (before upload) or cloud model ID (after upload) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It does not mention read-only nature, error handling, or side effects. Merely states it returns a file and instructions.
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?
Single sentence with no redundancy. Front-loaded with the core purpose and immediate return 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?
Adequate for a simple tool with one parameter: covers purpose and output. Lacks usage context and error condition hints.
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?
Input schema already provides a clear description for the single parameter. The tool description does not add additional meaning beyond what the schema states.
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 provides download information for running a model locally in AnyLogic PLE, distinguishing it from sibling tools like creation, validation, and upload.
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 guidance on when to use this tool versus alternatives. No prerequisites or context for usage (e.g., after upload or before local execution).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about AnyLogic PLE (Personal Learning Edition) limitations. Useful for understanding what restrictions apply when creating models.
| 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 full burden for behavioral disclosure. It only says 'Get information,' which implies read-only, but it does not explicitly state that the tool is non-destructive, requires no authentication, or has any 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?
The description is two sentences long, front-loads the purpose, and contains no unnecessary 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?
Despite low complexity (0 params, no output schema), the description is vague about what 'information' is returned (e.g., list of limits, numeric values, etc.). An agent would benefit from knowing the output structure.
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 tool has zero parameters, so the baseline is 4. The description adds no parameter meaning, but that is acceptable since the schema is fully covered.
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 'Get information about AnyLogic PLE limitations' clearly states the verb and resource, distinguishing it from sibling tools (create, download, upload, validate) that perform different actions. However, it adds little beyond the tool name itself.
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 notes it is 'useful for understanding what restrictions apply when creating models,' implying when to use it, but it does not explicitly state when not to use it or compare it to alternatives like anylogic_validate_ple.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a PLE-compliant model to AnyLogic Cloud. Requires ANYLOGIC_API_KEY to be set. The model will be available for running simulations in the cloud, and source files can be downloaded for use in local AnyLogic PLE.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | ID of the model to upload | |
| enable_source_download | No | Allow downloading model source files (.alp) | |
| make_public | No | Make model publicly accessible |
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 outcome (model available for simulations and source download) and the API key requirement, but lacks details on side effects like overwriting, error handling, or idempotency.
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?
Two concise sentences with no fluff. The key information is front-loaded, and every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters and no output schema, the description covers the main function, prerequisite, and outcome. However, it could mention potential errors or if the operation is idempotent. Overall fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds marginal value by stating that source files can be downloaded, which relates to enable_source_download, but does not significantly enhance understanding beyond the schema.
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 action (upload), resource (PLE-compliant model), and target (AnyLogic Cloud). It distinctly differentiates from sibling tools like create_model_ple and download_for_ple by specifying cloud upload.
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 mentions the requirement for ANYLOGIC_API_KEY, giving a prerequisite, but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. Usage is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a model definition complies with AnyLogic PLE (Personal Learning Edition) limits. Returns detailed information about limit usage and any violations.
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | ID of the model to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates the tool returns detailed information and is a check (likely read-only), but does not explicitly state side effects, authorization needs, or whether it modifies anything. This is a minimal disclosure.
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?
One sentence covering what the tool does and what it returns. No wasted words. Front-loaded with purpose. Highly 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 tool with one parameter and no output schema, the description covers basic purpose and return type. However, it lacks specificity about the checks (e.g., which limits) and whether the operation is safe. Adequate but could be more informative.
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 100% (single parameter with description 'ID of the model to validate'). The tool description adds no further semantic information beyond the schema, so baseline score of 3 applies. It does not clarify format or provenance of the model ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking compliance with AnyLogic PLE limits. It uses a specific verb ('Check if... complies') and identifies the resource ('model definition'). It distinguishes itself from siblings like get_ple_limits (which just returns limits) and create_model_ple (which creates models).
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 the tool is used for validation but does not explicitly state when to use it versus alternatives like get_ple_limits or after creation. No exclusions or when-not-to-use guidance is provided, leaving the agent to infer context.
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.0anylogic_create_model_pleanylogic_download_for_pleanylogic_get_ple_limitsanylogic_upload_to_cloudanylogic_validate_pleEach tool has a clearly distinct purpose: create, validate, get limits, download, and upload. No overlap in functionality.
All tools follow a consistent `anylogic_verb_noun` snake_case pattern, e.g., `anylogic_create_model_ple`, `anylogic_validate_ple`.
With 5 tools, the server is well-scoped for managing PLE-compliant AnyLogic models without being overwhelming or too sparse.
Covers creation, validation, limits, download, and upload. Missing update/delete functionality, but core lifecycle is present for the PLE context.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deploy sims to any screen. Control your displays with Claude.
Deploy sims to any screen. Control your displays with Claude.
Conversational what-if simulation: build, diagnose and compare Petri-net models; CC0 catalog.
Build and manage AI-native customer support agents from Claude or any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/umbaman/anylogicPLE-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
