Provides tools for compiling Tolk smart contracts for the TON blockchain, including syntax validation, compilation with options (optimization, stack comments), and exploration of contract examples and reference documentation.
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., "@tolk-mcp-server compile a simple counter contract"
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 for the Tolk smart contract compiler. Compile, validate, and explore TON smart contracts from any MCP-compatible AI assistant (Claude Desktop, Cursor, Windsurf, etc.).
Tools:
get_compiler_version — Returns the Tolk compiler version
compile_tolk — Compiles Tolk source code to Fift + BoC with full compiler options (optimization level, stack comments, experimental flags)
check_tolk_syntax — Quick syntax validation without full output
Resources:
tolk://reference — Tolk language quick reference (syntax, types, differences from FunC)
tolk://examples/hello-world — Counter contract example
tolk://examples/wallet — Wallet contract example
tolk://examples/jetton — Jetton (token) contract skeleton
Prompts:
write_smart_contract — Guided prompt for writing a new TON smart contract
review_smart_contract — Guided prompt for security review and optimization analysis
Related MCP server: iz-tolk-mcp
Add to claude_desktop_config.json:
{
"mcpServers": {
"tolk": {
"command": "npx",
"args": ["-y", "tolk-mcp-server"]
}
}
}Add to your MCP settings:
{
"tolk": {
"command": "npx",
"args": ["-y", "tolk-mcp-server"]
}
}git clone https://github.com/oxgeneral/tolk-mcp-server.git
cd tolk-mcp-server
npm install
npm run build
npm start> Use the compile_tolk tool to compile this contract:
fun onInternalMessage(myBalance: int, msgValue: int, msgFull: cell, msgBody: slice) {
}
get fun hello(): int {
return 42;
}The tool returns:
Fift assembly code
BoC (Bag of Cells) in base64 — ready for deployment
Code hash — unique identifier of the compiled code
Warnings (if any)
> Use check_tolk_syntax to validate my contract before deployingReturns OK + code hash, or a detailed error with line/column info.
Pass all files in the sources parameter:
{
"entrypointFileName": "main.tolk",
"sources": {
"main.tolk": "import \"./utils.tolk\";\nfun onInternalMessage(...) { ... }",
"utils.tolk": "fun helper(): int { return 1; }"
}
}Standard library imports (@stdlib/*) are resolved automatically by the compiler.
Option | Type | Default | Description |
| 0-2 | 2 | 0 = none, 1 = basic, 2 = full |
| bool | false | Add stack layout comments to Fift output |
| string | "" | Space-separated experimental compiler flags |
Node.js >= 18
No external dependencies beyond npm packages
npm install
npm run dev # Run with tsx (hot reload)
npm run build # Compile TypeScript
npm test # Run testsMIT
Validates Tolk smart contract source code without returning the full compiled output. Returns either "OK" with the code hash, or a detailed error message. Faster feedback loop for iterative development.
| Name | Required | Description | Default |
|---|---|---|---|
| sources | No | Object mapping filename → source code content | |
| entrypointFileName | Yes | The main .tolk file to check (e.g., "main.tolk") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and discloses the return contract: either an OK with a code hash or a detailed error message. It also states what the tool does not do (return full compiled output), adding transparency, though it does not explicitly mention side-effect-freeness.
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 composed of three compact sentences, each serving a clear purpose: what it does, what it returns, and when to use it. There is no redundant or irrelevant text.
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 two well-documented parameters and no output schema, the description sufficiently covers purpose, behavior, and use case. The sibling tools provide additional context, and nothing critical 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?
The input schema provides 100% description coverage for both parameters (sources object and required entrypointFileName), meeting the baseline. The tool description itself adds no parameter-specific details, which is acceptable given the schema's clarity.
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 uses a specific verb ('Validates') with the resource ('Tolk smart contract source code') and explicitly contrasts with full compilation, distinguishing itself from sibling compile_tolk. It clearly states the tool's primary function.
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 states that it validates without returning full compiled output and emphasizes a faster feedback loop, which clearly implies use during iterative development when full compilation is not needed. It does not explicitly name alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compiles Tolk smart contract source code using @ton/tolk-js. Provide source files as a map of filename→content. The entrypoint file must be included. Standard library imports (@stdlib/*) are resolved automatically. Returns compiled Fift code, BoC (Bag of Cells) in base64, and the code hash.
| Name | Required | Description | Default |
|---|---|---|---|
| sources | No | Object mapping filename → source code content. Must include the entrypoint file. Example: {"main.tolk": "fun main(): int { return 0; }"} | |
| optimizationLevel | No | Optimization level 0-2 (default: 2). 0 = no optimization, 2 = full optimization | |
| withStackComments | No | Include stack layout comments in Fift output (default: false). Useful for debugging | |
| entrypointFileName | Yes | The main .tolk file to compile (e.g., "main.tolk") | |
| experimentalOptions | No | Space-separated experimental compiler flags (advanced usage) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses the return values (Fift code, BoC base64, code hash) and automatic stdlib import resolution, which is useful. However, it omits details about error behavior, potential side effects, or limitations, leaving moderate 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 two concise sentences, front-loaded with the main verb and purpose. Every sentence provides essential 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?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description covers the input format, entrypoint requirement, stdlib handling, and return values comprehensively. It lacks explicit mention of error handling or constraints, but the overall context is well-provided.
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?
All parameters are documented in the schema (100% coverage), providing a baseline of 3. The description adds meaningful context by explaining the sources map format and explicitly requiring the entrypoint file to be included in sources, which goes beyond the schema descriptions.
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 explicitly states 'Compiles Tolk smart contract source code using @ton/tolk-js', which clearly identifies the verb and resource. It naturally distinguishes from sibling tools like check_tolk_syntax and get_compiler_version by focusing on the compilation action.
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 for compilation and provides some input expectations (sources map, entrypoint inclusion), but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. Sibling tools are not referenced in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the version string of the Tolk compiler (WASM build from @ton/tolk-js). Use this to verify the compiler is available and check its version before compiling.
| 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 value (version string) and that it can verify compiler availability, but it does not detail error behavior (e.g., what happens if the compiler is unavailable) or explicitly state the absence of side effects. This is adequate for a zero-parameter read-only getter, but not rich.
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 at two sentences, front-loaded with the primary action, and every sentence earns its place. It avoids redundancy and clearly conveys the tool's purpose and usage.
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 version-check tool with zero parameters and no output schema, the description is complete: it states what it returns, when to use it, and its relation to compilation. It provides all necessary context without over-explaining.
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 and the schema is empty, so the description does not need to elaborate on parameter meanings. The baseline for zero-parameter tools is 4, and the description adequately explains the tool's purpose without needing parameter details.
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 function: 'Returns the version string of the Tolk compiler (WASM build from @ton/tolk-js).' This is a specific verb+resource statement that distinguishes it from the sibling tools (compile_tolk, check_tolk_syntax) by focusing solely on version retrieval.
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 explicit usage context: 'Use this to verify the compiler is available and check its version before compiling.' This tells the agent when to invoke it (before compiling), though it does not explicitly name alternatives or exclusion scenarios. Still, the guidance is clear enough for a simple version-check tool.
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.
v1.0.0check_tolk_syntaxcompile_tolkget_compiler_versionEach tool has a clearly distinct purpose: getting the compiler version, compiling to Fift/BoC, and checking syntax without full compilation. No overlap or ambiguity between them.
All tool names follow the consistent verb_noun pattern: get_compiler_version, compile_tolk, check_tolk_syntax. The style is uniform and predictable.
Three tools is well-scoped for a compiler-specific MCP server. Each tool covers a distinct aspect of the compilation workflow without unnecessary bloat or missing essentials.
The server covers the core compilation lifecycle: version check, syntax validation, and full compile with output artifacts. Minor gaps like a list of available stdlib functions exist, but they are not critical for the primary purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
OpenAI-compatible LLM MCP (7 tools); chat via balance key or x402 USDC on Base
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
The OpenZeppelin Cairo Contracts MCP server generates secure smart contracts in the Cairo language for Starknet environments based on OpenZeppelin templates. It brings OpenZeppelin's proven security and style rules directly into AI-driven development workflows to create safe, production-ready contracts. Key capabilities include providing templates for ERC-20, ERC-721, ERC-1155, Multisig, Governor, and Vesting contracts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/oxgeneral/tolk-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
