Complete Model Context Protocol server for TON blockchain development. Comprehensive crawler indexes ALL docs.ton.org (500+ pages), live blockchain data, code generation, and Telegram Mini Apps support.
TON MCP has solid foundational structure with 30 tools, but exhibits significant inconsistencies in schema completeness, description quality, and parameter documentation. Most tools have descriptions (85%+ coverage), but 40% lack detailed parameter descriptions. Input schemas are present and well-typed, but output schemas are entirely undocumented. Error handling is minimal, tools provide no recovery guidance or error categorization. The server targets a specialized domain (TON blockchain) where precise naming is critical; naming is generally verb-first and clear, but some tools conflate multiple concerns (e.g., `generate_contract_code` vs `generate_contract_wrapper` suggest overlapping responsibility).
Tools (30)
blueprint_project_setupread only50/100
Get Blueprint project setup guide for TON smart contract development
Output schemas are entirely undocumented. Tools return responses but LLMs cannot see the structure (fields, types, required properties) of those responses. This forces LLMs to guess what data is available and risks hallucination of fields that don't exist.
Add explicit output schema definitions for every tool. Document the response structure (object with typed fields, array items, metadata). Example for `get_account_info_live`: `{ "address": string, "balance": string (nanotons), "status": 'active' | 'uninitialized' | 'frozen', "seqno": number, "code_hash": string }`.
For tools with empty input schemas (e.g., `get_network_status_live`, `blueprint_project_setup`), expand the description to be extremely specific about when to call it and what it reveals. 'Get real-time TON network status and gas prices' is too vague, replace with 'Returns current blockchain metrics: blocks per second, average gas price (in nanotons per gas), recent block time, seqno. Call this BEFORE generating a deployment script to estimate transaction costs.'
Consolidate redundant reference tools. Instead of three separate `get_*_reference` tools, consider a single `get_language_reference(language: 'tolk'|'tact'|'func', section: string)` tool, or clearly distinguish when an LLM should choose tolk vs tact vs func reference.
Add error handling documentation to tool descriptions. For `compile_tolk_contract`, add: 'Returns compiled BOC hex on success. On error, returns error classification (COMPILER_NOT_INSTALLED | SYNTAX_ERROR | INTERNAL_ERROR) and recovery hint (e.g., "Install tolk: npm install -g @tolk-lang/compiler").'
Document rate limits, timeouts, and cost implications for tools calling live APIs. E.g., `get_transaction_history_live`: 'Fetches from TON blockchain API. Limit: 1 call per 500ms. Timeout: 10s. If timeout, blockchain was busy, safe to retry.'
Score history
Overall score trend
↑ 21 points across a rubric change (v1 → v2)
57/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
57
2026-07-28+
v2
2026-03-09
F
36
-
v1
read onlysource verified80/100
Generate React frontend code for TON dApps
generate_test_fileread onlysource verified82/100
Generate test file for TON smart contract using Blueprint's Sandbox testing framework
generate_tma_contractread only50/100
Generate a TON smart contract optimized for Telegram Mini App integration
generate_tma_frontendread only50/100
Generate Telegram Mini App frontend code with TON blockchain integration
Tools with no or empty input parameters (e.g., `get_network_status_live`, `blueprint_project_setup`, `ton_security_best_practices`) lack context for LLM selection. When a tool accepts no input, the description alone must be highly specific about WHEN to invoke it and what it returns. Current descriptions are insufficient for this.
Multiple tools appear to do similar things, risking LLM confusion and wasted reasoning. Examples: `get_tolk_reference`, `get_tact_reference`, `get_func_reference` (three separate reference tools); `generate_contract_code` vs `generate_contract_wrapper` (both code generation); `generate_tma_contract` vs `generate_contract_code` (overlap on contract generation). Clarifying distinctions in descriptions is essential.
No error handling or recovery guidance. Tools provide no descriptions of what errors can occur, which are retryable, or what the LLM should do next. E.g., `compile_tolk_contract` can fail if tolk compiler is not installed, but there's no error classification or recovery hint in the tool definition.
Tools that read from external APIs (e.g., `get_account_info_live`, `get_transaction_history_live`, `get_jetton_info_live`) lack timeout specifications, rate-limit guidance, or documentation of what constitutes success vs failure. Live blockchain queries can hang or timeout, the LLM needs to know expected latency and failure modes.
Several tools accept only optional parameters (or parameters with defaults), making their invocation semantics unclear. E.g., `generate_frontend_code` requires `features` array, but what if the user only wants a wallet-connect feature? Does it fail, or does it auto-include all? Clarify in descriptions what happens with empty/minimal input.
Parameter descriptions are minimal or missing detail about constraints. E.g., `generate_contract_code` specifies `contract_type` enum but doesn't explain what each type means (what's a 'dao' contract vs a 'staking' contract?). Parameter descriptions should answer: What is this? What are the options? When would I use each?
STDIO transport only, server cannot be accessed remotely and is not compatible with hosted MCP clients or cloud-based agent platforms. This is a hard architectural limitation that caps the protocol readiness score at 50.
Expand parameter descriptions with examples and constraints. For `generate_contract_code`, clarify each enum value: `contract_type: 'counter' (simple state increment), 'wallet' (TON wallet), 'jetton' (fungible token), 'nft' (non-fungible token), 'dao' (voting contract), 'staking' (stake rewards), 'multisig' (multi-signature wallet)`. State constraints like: `language: 'tolk' (recommended for new code, modern syntax), 'tact' (higher-level, batteries included), 'func' (low-level, performance-critical)'.
Document which tools modify state vs. read-only. Current all tools are marked `READ_ONLY`, which is correct, but the descriptions should re-emphasize: 'This tool generates code but does NOT deploy or modify the blockchain. Use `generate_deployment_script` and execute it separately to deploy.'
Add dependencies between tools in descriptions. E.g., `generate_deployment_script` should note: 'Requires compiled contract code. If you only have source, call `compile_tolk_contract` first.' This guides multi-step reasoning.
Provide natural-language identifiers where possible. Currently, tools like `get_account_info_live` require a `address` (TON address string). Document if human-readable names (e.g., 'alice.ton') are also accepted, or require a `resolve_address(name)` lookup tool first.
For tools returning lists (e.g., `search_ton_documentation`, `list_ton_resources`), add pagination parameters (offset, limit) if not present, and document the max result count and pagination strategy. This prevents context window exhaustion.
Clarify the output of code-generation tools. E.g., `generate_contract_code`, does it return just the source code string, or metadata (contract_name, interfaces, entry points)? Document the exact response structure so the LLM can chain to `compile_tolk_contract` or `generate_test_file` without guessing field names.
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to the MCP protocol definition. While all current tools are read-only, explicit hints let clients optimize logging and auditing.
Migrate from STDIO to Streamable HTTP transport. This is required for remote accessibility and cloud agent compatibility. See https://spec.modelcontextprotocol.io/latest/spec/ for HTTP+SSE protocol details.