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., "@MCP Server for Alloy Modeling Language create a model for a file system with users and permissions"
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.
This is an MCP server that can let you run a local Alloy-Language server. You can use it to allow an LLM-powered agent to generate and execute Alloy modeling code.
Alloy is an open source language and analyzer for software modeling. It has been used in a wide range of applications, from finding holes in security mechanisms to designing telephone switching networks. This site provides language documentation, tool downloads, and a repository of links to case studies and applications. As the open source community grows, this site will also provide access to extensions of the Alloy Analyzer, and tools built on top of it and on top of Kodkod, its model finding engine. (alloytools.org)
This MCP server uses the alloy-lang npm package which bundles the language binary for easy use from nodejs.
npm install
npm run buildRelated MCP server: OpenKer Modeler MCP Server
Run the server using stdio transport:
npm startOr use the built binary directly:
node build/index.js# Build TypeScript
npm run build
# Build and run
npm run dev
# Lint code
npm run lint
# Fix linting issues
npm run lint:fix
# Run tests
npm testexecute_alloy: Execute Alloy modeling language code and return structured JSON results
Input: code (string) - The Alloy code to execute
Output: JSON with instances, values, and solver results
alloy://docs: Basic Alloy language documentation and syntax reference
alloy://examples: Example Alloy models (graphs, file systems, state machines)
create_alloy_model: Generate an Alloy model based on a system description
Input: description (string) - Description of the system to model
sig Node {
edges: set Node
}
// No self-loops
fact { all n: Node | n not in n.edges }
// Find a graph with a cycle
run { some n: Node | n in n.^edges } for 5Execute Alloy modeling language code and return structured JSON results
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The Alloy modeling language code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions execution and returning JSON results but fails to describe critical traits like error handling, execution time, resource usage, or security implications. For a code execution tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and outcome, making it easy to parse. Every part of the sentence contributes essential information, earning a perfect score for 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 complexity of code execution and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'structured JSON results' entail, potential errors, or execution limits. For a tool that could have varied outputs and behaviors, more context is needed to ensure reliable agent usage.
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 input schema has 100% description coverage, with the 'code' parameter fully documented. The description adds minimal value beyond the schema by implying the code is executed, but it doesn't provide additional details like syntax examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't significantly enhance 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's purpose: 'Execute Alloy modeling language code and return structured JSON results.' It specifies the verb ('execute'), resource ('Alloy modeling language code'), and outcome ('return structured JSON results'), making it easy to understand what the tool does. However, with no sibling tools mentioned, there's no opportunity to distinguish from alternatives, preventing a perfect score.
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 no guidance on when to use this tool, such as typical use cases, prerequisites, or limitations. It lacks any context about alternatives or exclusions, leaving the agent with minimal direction beyond the basic purpose. This absence of usage guidelines reduces its effectiveness in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools, making disambiguation perfect.
The single tool follows a clear verb_noun pattern (execute_alloy), and with no other tools, consistency is inherently perfect.
One tool is too few for a modeling language server, as it lacks essential operations like model validation, instance generation, or visualization, making the scope feel incomplete.
The tool surface is severely incomplete; it only allows code execution without supporting core Alloy workflows such as checking assertions, generating examples, or analyzing models, leading to significant gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
33 tools that make AI write, implement, and verify intent against explicit, testable constraints.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/awwaiid/mcp-server-alloy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
