FluffOS MCP Server
This server provides driver-level validation and debugging for LPC development by exposing FluffOS CLI tools to AI assistants.
Core capabilities:
Validate LPC code - Use FluffOS's
symboltool to catch runtime compilation issues that static analysis misses, with structured error reporting directly from the driverDisassemble to bytecode - Convert LPC files to compiled bytecode using
lpccto examine function tables, instruction details, and debug performance or behavior issuesSearch documentation (optional) - Look up FluffOS documentation for efuns, applies, and concepts when
FLUFFOS_DOCS_DIRis configuredPath normalization - Automatically converts absolute file paths to mudlib-relative paths based on your FluffOS configuration
Use cases: Validate code before deployment, debug performance bottlenecks, understand how LPC constructs compile at the driver level, and learn LPC behavior through bytecode analysis.
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., "@FluffOS MCP Servervalidate this LPC file for runtime compilation issues"
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.
FluffOS MCP Server
Real driver validation for LPC development - An MCP server that wraps FluffOS CLI tools to provide actual driver-level validation and debugging.
This MCP server exposes FluffOS's powerful CLI utilities (symbol and lpcc) to AI assistants, enabling them to validate LPC code against the actual driver and examine compiled bytecode.
What This Enables
AI assistants can now:
Validate LPC files using the actual FluffOS driver (not just syntax checking)
Catch runtime compilation issues that static analysis misses
Examine compiled bytecode to debug performance or behavior issues
Understand how LPC code actually compiles
Related MCP server: LPC MCP Server
Tools
fluffos_validate: Validate an LPC file using FluffOS'ssymboltoolfluffos_disassemble: Disassemble LPC to bytecode usinglpccfluffos_doc_lookup: Search FluffOS documentation for efuns, applies, concepts, etc.fluffos_eval: Evaluate LPC statements against the live driver usinglpcshell(opt-in)
fluffos_validate, fluffos_disassemble, and fluffos_doc_lookup are read-only and idempotent — they never modify files, drivers, or running MUDs, and are safe for agents to auto-invoke.
fluffos_eval is not read-only: it boots the full runtime and executes the LPC you give it, so it can have side effects (writing files, mutating daemon/database state, firing events). It is registered only when FLUFFOS_ENABLE_EVAL is set, and should not be auto-invoked on untrusted input.
When to use which tool
I want to… | Use |
Check whether a file compiles against the driver |
|
See the bytecode a function compiles to |
|
Investigate why a pattern is slow |
|
Look up an efun signature or apply semantics |
|
Find out if an efun exists in this driver build |
|
Pre-commit / pre-deploy sanity check |
|
See the actual runtime value/behaviour of an expression |
|
Reproduce a runtime error interactively |
|
fluffos_doc_lookup is only registered when the server is started with FLUFFOS_DOCS_DIR set. fluffos_eval is only registered when FLUFFOS_ENABLE_EVAL is set.
Prerequisites
1. FluffOS Installation
You need FluffOS installed with the CLI tools available. The following binaries should exist:
symbol- For validating LPC fileslpcc- For disassembling to bytecodelpcshell- (Optional) Forfluffos_eval; required only whenFLUFFOS_ENABLE_EVALis set
2. Node.js
Node.js 16+ required:
node --version # Should be v16.0.0 or higherInstallation
You can install the server via npm:
npm install -g @gesslar/fluffos-mcpOr clone and install locally:
git clone https://github.com/gesslar/fluffos-mcp.git
cd fluffos-mcp
npm installConfiguration
The server requires these environment variables:
FLUFFOS_BIN_DIR- Directory containing FluffOS binaries (symbol,lpcc, and optionallylpcshell)MUD_RUNTIME_CONFIG_FILE- Path to your FluffOS config file (e.g.,/mud/lib/etc/config.test)FLUFFOS_DOCS_DIR- (Optional) Directory containing FluffOS documentation for doc lookupFLUFFOS_ENABLE_EVAL- (Optional) Set totrue(or1/yes/on, case-insensitive) to registerfluffos_eval, which executes live LPC vialpcshell. Off by default — any other value, includingfalse/0or leaving it unset, keeps the tool disabled because it is not read-only.FLUFFOS_EVAL_TIMEOUT_MS- (Optional) Wall-clock cap in milliseconds for a singlefluffos_evalrun before thelpcshellchild is killed. Defaults to30000(30s); ignored unlessfluffos_evalis enabled.FLUFFOS_EVAL_MAX_BYTES- (Optional) Maximum size in bytes of anfluffos_evalcodepayload; larger requests are rejected before anything is written to disk. Defaults to10485760(10 MiB); ignored unlessfluffos_evalis enabled.FLUFFOS_EVAL_MAX_CONCURRENT- (Optional) Maximum number offluffos_evalruns allowed in flight at once; further requests are rejected until a slot frees. Each run spawns a fulllpcshelldriver boot, so this bounds both temp-storage use and driver load. Defaults to4; ignored unlessfluffos_evalis enabled.
Setup for Different AI Tools
Warp (Terminal)
Add to your Warp MCP configuration:
Location: Settings → AI → Model Context Protocol
If installed via npm:
{
"fluffos": {
"command": "npx",
"args": ["@gesslar/fluffos-mcp"],
"env": {
"FLUFFOS_BIN_DIR": "/path/to/fluffos/bin",
"MUD_RUNTIME_CONFIG_FILE": "/mud/lib/etc/config.test",
"FLUFFOS_DOCS_DIR": "/path/to/fluffos/docs"
}
}
}If cloned locally:
{
"fluffos": {
"command": "node",
"args": ["/absolute/path/to/fluffos-mcp/index.js"],
"env": {
"FLUFFOS_BIN_DIR": "/path/to/fluffos/bin",
"MUD_RUNTIME_CONFIG_FILE": "/mud/lib/etc/config.test",
"FLUFFOS_DOCS_DIR": "/path/to/fluffos/docs"
}
}
}Important: Use absolute paths!
Restart Warp after adding the configuration.
Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or equivalent:
If installed via npm:
{
"mcpServers": {
"fluffos": {
"command": "npx",
"args": ["@gesslar/fluffos-mcp"],
"env": {
"FLUFFOS_BIN_DIR": "/path/to/fluffos/bin",
"MUD_RUNTIME_CONFIG_FILE": "/mud/lib/etc/config.test",
"FLUFFOS_DOCS_DIR": "/path/to/fluffos/docs"
}
}
}
}If cloned locally:
{
"mcpServers": {
"fluffos": {
"command": "node",
"args": ["/absolute/path/to/fluffos-mcp/index.js"],
"env": {
"FLUFFOS_BIN_DIR": "/path/to/fluffos/bin",
"MUD_RUNTIME_CONFIG_FILE": "/mud/lib/etc/config.test",
"FLUFFOS_DOCS_DIR": "/path/to/fluffos/docs"
}
}
}
}Restart Claude Desktop after configuration.
Enabling live LPC eval (optional)
The examples above register only the three read-only tools. To also expose
fluffos_eval — which boots the driver and executes LPC, so it can have
side effects — add FLUFFOS_ENABLE_EVAL to the env block alongside the
others:
"env": {
"FLUFFOS_BIN_DIR": "/path/to/fluffos/bin",
"MUD_RUNTIME_CONFIG_FILE": "/mud/lib/etc/config.test",
"FLUFFOS_ENABLE_EVAL": "true"
}Accepted "on" values are true, 1, yes, or on (case-insensitive). Any
other value — or omitting the variable entirely — leaves the tool disabled.
The lpcshell binary must exist in FLUFFOS_BIN_DIR for this to work.
Usage Examples
Once configured, you can ask your AI assistant:
"Validate this LPC file with the actual driver"
→ AI uses fluffos_validate to run symbol
"Show me the bytecode for this function"
→ AI uses fluffos_disassemble to run lpcc
"Why is this code slow?" → AI examines the disassembly to identify inefficient patterns
"What's the syntax for call_out?"
→ AI uses fluffos_doc_lookup to search documentation
"How do I use mappings?" → AI searches docs for mapping-related documentation
How It Works
AI Assistant
↓ (natural language)
MCP Protocol
↓ (tool calls: fluffos_validate, fluffos_disassemble)
This Server
↓ (spawns: symbol, lpcc)
FluffOS CLI Tools
↓ (validates/compiles with actual driver)
Your LPC CodeAI assistant sends MCP tool requests
Server spawns appropriate FluffOS CLI tool
CLI tool validates/disassembles using the driver
Server returns results to AI
AI understands your code at the driver level and can reference FluffOS documentation to explain how functions work!
Implementation Details
Architecture
The server is built using the Model Context Protocol SDK and follows a class-based architecture:
FluffOSMCPServer class: Main server implementation
MCP SDK Server: Handles protocol communication via stdio
Child process spawning: Executes FluffOS CLI tools
Path normalization: Converts absolute paths to mudlib-relative paths
Path Handling
The server intelligently handles file paths:
Parses
mudlib directoryfrom your FluffOS config fileNormalizes absolute paths to mudlib-relative paths
Passes normalized paths to FluffOS tools (which expect relative paths)
Example: /mud/ox/lib/std/object.c → std/object.c
Tool Implementation
fluffos_validate:
Spawns
symbol <config> <file>from the config directoryCaptures stdout/stderr
Returns success/failure with compilation errors
Exit code 0 = validation passed
fluffos_disassemble:
Spawns
lpcc <config> <file>from the config directoryReturns complete bytecode disassembly
Includes function tables, strings, and instruction-level detail
fluffos_doc_lookup (optional):
Runs
scripts/search_docs.shhelper scriptUses
grepto search markdown filesOnly available if
FLUFFOS_DOCS_DIRis set
fluffos_eval (optional):
Writes the submitted LPC statements to a temporary script file, then spawns
lpcshell <config> <tmpfile>The temp file is a plain OS file (read by
lpcshelldirectly, not through the driver's file system) and so does not need to live inside the mudlib jail — only the LPC statements execute in-jailBoots the full runtime and executes the code; captures stdout/stderr and exit code, then deletes the temp file
Only available if
FLUFFOS_ENABLE_EVALis set
Error Handling
Validates required environment variables on startup
Returns structured error responses via MCP
Gracefully handles missing config or tool execution failures
Non-zero exit codes are reported but don't crash the server
Complementary Tools
This server works great alongside:
lpc-mcp - Language server integration for code intelligence
VS Code with jlchmura's LPC extension - IDE support
Use them together for the complete LPC development experience!
Contributing
PRs welcome! This is a simple wrapper that can be extended with more FluffOS tools.
Credits
FluffOS Team - For the amazing driver and CLI tools
Model Context Protocol - Making this integration possible
License
@gesslar/fluffos-mcp is released under the 0BSD.
This package includes or depends on third-party components under their own licenses:
Dependency | License |
0BSD | |
MIT | |
MIT |
Available Tools
2 toolsfluffos_disassembleB
Disassemble an LPC file to show compiled bytecode using lpcc. Useful for debugging and understanding how code compiles.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Absolute path to the LPC file to disassemble |
TDQS
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 mentions the tool is 'useful for debugging and understanding how code compiles,' which gives some behavioral context about its purpose. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, what permissions are needed, whether it modifies the file, error handling, or output format details.
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 appropriately sized and front-loaded. The first sentence clearly states the core functionality, and the second sentence adds valuable context about when to use it. Both sentences earn their place with zero waste.
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 has 1 parameter with 100% schema coverage and no output schema, the description provides adequate but minimal context. It explains what the tool does and its use cases, but for a tool with no annotations and no output schema, it should ideally provide more behavioral details about what the disassembly output looks like or any limitations.
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 schema description coverage is 100%, with the single parameter 'file' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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: 'Disassemble an LPC file to show compiled bytecode using lpcc.' It specifies the verb (disassemble), resource (LPC file), and method (using lpcc). However, it doesn't explicitly differentiate from the sibling tool 'fluffos_validate', which appears to be a different operation.
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 implied usage context: 'Useful for debugging and understanding how code compiles.' This suggests when to use the tool, but doesn't explicitly state when not to use it or mention alternatives. No comparison to the sibling tool is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fluffos_validateA
Validate an LPC file using the FluffOS driver's symbol tool. Returns success/failure and any compilation errors.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Absolute path to the LPC file to validate |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the validation outcome ('success/failure and any compilation errors'), which is useful context beyond basic functionality. However, it doesn't address important behavioral aspects like error handling, performance characteristics, or whether this operation has 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 perfectly concise with two sentences that each earn their place: the first states the core functionality, and the second describes the return value. There's zero waste or redundancy, and it's appropriately front-loaded with the main 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 single-parameter validation tool with no annotations and no output schema, the description provides adequate but minimal information. It covers what the tool does and what it returns, but doesn't address potential complexities like what constitutes validation success versus failure, error message formats, or limitations of the validation process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'file' parameter. The description doesn't add any additional meaning about the parameter beyond what the schema provides, such as file format requirements or validation scope limitations. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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 specific action ('validate an LPC file') and resource ('using the FluffOS driver's symbol tool'), distinguishing it from the sibling tool 'fluffos_disassemble' which implies a different operation. It provides a complete verb+resource+scope statement.
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 is provided on when to use this tool versus alternatives. While the sibling tool name suggests a different function, the description doesn't explicitly state when to choose validation over disassembly or other potential options. There's no mention of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v1.0.0- First observed
fluffos_disassemble - First observed
fluffos_validate
TDQS
The two tools have clearly distinct purposes: disassemble focuses on showing compiled bytecode for debugging, while validate checks for compilation errors and success/failure. There is no overlap or ambiguity between these functions.
Both tools follow a consistent 'fluffos_verb' naming pattern (fluffos_disassemble and fluffos_validate), using the same prefix and verb-based structure. This makes them predictable and easy to identify.
With only 2 tools, the server feels thin for a FluffOS/LPC development environment. While disassembly and validation are useful, typical development workflows would benefit from additional tools like code execution, file management, or debugging support, making this set under-scoped.
The server covers only disassembly and validation, leaving significant gaps for a FluffOS development tool. Missing are core operations like running LPC code, editing files, managing projects, or advanced debugging features, which limits agents' ability to handle comprehensive development tasks.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
Architecture compiler for AI code. 11 tools, 92 actions, 872 Lean4 proofs, 100/100 self-cert.
Live browser debugging for AI assistants — DOM, console, network via MCP.
The Polar Signals MCP server enables AI assistants to connect directly with performance profiling data, allowing users to analyze application performance through natural language queries. Key capabilities include querying CPU performance and memory usage, exploring profiling metadata like profile types and labels, and providing AI-driven code optimization suggestions directly within development environments like Claude Code or Cursor.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceEnables AI agents to compile, execute, and check Almide code for syntax or compilation errors. It provides tools for generating ASTs and accessing language grammar resources.-
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to understand and query LPC codebases through natural language, using a language server for hover info, definitions, references, and diagnostics.132BSD Zero Clause
- FlicenseAqualityDmaintenanceCompile, validate, and explore TON smart contracts using the Tolk compiler from any MCP-compatible AI assistant.3-
- AlicenseNot gradedqualityDmaintenanceEnables verification of Lean 4 mathematical proofs via MCP tools, allowing AI clients to compile and check theorems with Mathlib.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gesslar/fluffos-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server