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., "@cellc-mcp check my new Cell contract for type errors"
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 wrapping the cellc CellScript compiler so a local agentic model can
write CKB Cell contracts in a write → check → explain → inspect loop.
python -m venv .venv && . .venv/bin/activate
pip install -e .Related MCP server: Ceedling MCP Server
A built cellc binary. Build it once:
cd ~/CellScript && cargo install --path .
(Needs a sibling ckb-sdk-rust checkout at tag v5.1.0 per CellScript AGENTS.md.)
CELLC_BIN — path to the cellc binary (else found on PATH)
CELLSCRIPT_REPO — CellScript checkout for examples/reference (default ~/CellScript)
CELLC_TIMEOUT — per-call timeout seconds (default 30)
{
"mcpServers": {
"cellc": {
"command": "cellc-mcp",
"env": { "CELLSCRIPT_REPO": "/home/phill/CellScript" }
}
}
}cellc_check — type-check; terse diagnostics (max 5; full=true for all)
cellc_explain — explain an error code (E####)
cellc_metadata — compiler metadata summary (full=true for schema-30 JSON)
cellc_constraints — verifier obligations + runtime-error registry
cellc_language_reference — the full language surface, in-context
cellc_list_examples / cellc_get_example — example contracts for grounding
python -m pytest -v # offline unit tests
python -m pytest -m needs_cellc -v # integration (needs cellc)
Type-check a CellScript contract. Returns ok + diagnostics (terse, max 5; full=true for all).
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| path | No | ||
| source | No | ||
| target_profile | No |
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 that diagnostics are terse (max 5) unless full=true, which is a key behavioral trait. It does not mention side effects, but for a type-checking tool, read-only behavior is implied. No contradictions.
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, well-structured sentence. It front-loads the main action and immediately provides a key detail about diagnostics. Every word contributes value; there is no filler or repetition.
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 4 parameters, no output schema, and no annotations, the description is too brief. It does not explain the meaning of 'ok', the structure of diagnostics, or how parameters like 'path' and 'source' are used. The agent is left with significant gaps.
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 description only mentions the 'full' parameter ('full=true for all'), leaving 'path', 'source', and 'target_profile' completely unexplained. With 0% schema description coverage, the description fails to compensate for the missing parameter semantics.
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: 'Type-check a CellScript contract.' This is a specific verb-resource pair that distinguishes it from sibling tools like cellc_constraints or cellc_explain. The mention of return values ('ok + diagnostics') adds further clarity.
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 explicit guidance on when to use this tool versus alternatives. It does not state prerequisites, exclusions, or scenarios where a sibling tool would be more appropriate. The agent must infer usage solely from the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifier obligations + runtime-error registry for a contract. Summary by default.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| path | No | ||
| source | No | ||
| target_profile | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool retrieves data (obligations and errors) and that summary is default, but it does not mention whether it is read-only, if it requires special permissions, or if there are rate limits. Basic behavior is implied but not thoroughly explained.
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 very short (one sentence), which is concise and front-loaded with the main purpose. However, it is too brief and lacks structure such as usage hints or parameter info. Every part earns its place, but more content is needed for effective communication.
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 4 parameters, no schema descriptions, no annotations, and no output schema, the description is severely lacking. It does not explain return values, parameter roles, or when to use the tool. The description is insufficient for an agent to select and invoke the tool correctly without additional context.
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 0%, meaning no parameter descriptions exist. The description adds no meaning to any of the four parameters (full, path, source, target_profile). It does not explain how these parameters affect the output or what values are expected.
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 that the tool retrieves verifier obligations and runtime-error registry for a contract, and mentions that summary is the default mode. This distinguishes it from siblings like cellc_check or cellc_explain, which likely focus on different aspects. However, it lacks an explicit verb like 'get' or 'list', which slightly reduces clarity.
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 the sibling tools. There is no mention of when-not-to-use or alternatives. The only hint is 'Summary by default', but this is more about behavior than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a CellScript error code (e.g. E0014) with description and fix hint.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
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 output includes a description and fix hint, but does not disclose any potential side effects, authentication requirements, or return format. For a read-only explanation tool this is acceptable but minimal.
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 sentence, front-loaded with the verb 'Explain', and contains no unnecessary words. It is 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?
Given the tool's simplicity (one parameter, no output schema), the description covers its purpose and input format adequately. It could mention the return value explicitly, but the purpose is clear.
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 0%, so the description compensates by giving an example format (E0014) for the 'code' parameter. This adds significant meaning beyond the schema's 'string' type.
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 explains a CellScript error code with a description and fix hint, and provides a concrete example (E0014). It is distinct from sibling tools like cellc_check or cellc_constraints.
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 error codes but does not explicitly state when to use this tool versus alternatives. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one example .cell contract's source for few-shot grounding.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It indicates a read operation returning source. However, no details on error behavior (e.g., invalid name), rate limits, or auth requirements. Adequate but minimal for a simple tool.
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?
A single concise sentence with no wasted words. However, it could include a brief note about the 'name' parameter without losing 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 1 parameter (undocumented), no output schema, and sibling tools, the description is incomplete. It doesn't explain how to find valid names (e.g., using cellc_list_examples) or what the returned source looks like. Agent may be confused without additional context.
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 0% (no parameter descriptions in schema or description). The description does not explain what 'name' refers to (e.g., example name, contract filename). Since schema provides only type/required, description should compensate but fails to add meaning.
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 ('Return'), resource ('example .cell contract's source'), and purpose ('few-shot grounding'). It distinguishes from sibling tools like cellc_list_examples (which lists) and cellc_explain (which explains).
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?
Usage is implied for few-shot grounding, but no explicit guidance on when to use this vs. alternatives. With siblings like cellc_list_examples, the description should specify that this returns full source for a specific example, while cellc_list_examples only lists names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full CellScript language surface (keywords, effects, worked example).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions the output (language surface) but does not disclose whether the tool is read-only, has any side effects, or requires permissions. For a static reference tool, this is adequate but lacks explicit safety guarantees.
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 sentence that is front-loaded with the key purpose. Every word contributes meaning, with no unnecessary content.
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 tool with no parameters and an output schema (context indicates it exists), the description sufficiently states the content of the reference. It could optionally mention that it is read-only, but the description is otherwise complete for a simple look-up operation.
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 no parameters and schema description coverage is 100%, so the baseline is 3. The description does not add any parameter information, which is acceptable since there are none.
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 it provides 'the full CellScript language surface' including keywords, effects, and a worked example. This clearly distinguishes it from sibling tools like cellc_check or cellc_constraints, which likely perform specific operations rather than serving as a reference.
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 that this tool should be used when one needs the language reference, but it does not explicitly state when to use it versus alternatives. No guidance on when not to use it or specific scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bundled example .cell contracts with one-line summaries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It states the tool lists examples with summaries, which implies a read-only operation, but does not explicitly confirm safety or lack of side effects. This is adequate but minimal.
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, front-loaded sentence with no waste. Every word contributes to understanding the tool's 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?
Given zero parameters and an output schema, the description sufficiently explains what the tool does and the nature of its output (list of contracts with summaries). It is complete for this simple tool.
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?
There are no parameters, and schema coverage is 100% trivially. The description adds value by explaining the output format (one-line summaries), which is extra context 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 uses a specific verb 'List' and a clear resource 'bundled example .cell contracts', and the sibling tool 'cellc_get_example' suggests the distinction between listing and getting a specific example, making purpose unambiguous.
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 gives no explicit guidance on when to use this tool versus alternatives like 'cellc_get_example' or 'cellc_explain'. The usage is implied but not stated, and there are no exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compiler-emitted metadata: resources, actions, effects, obligations. Summary by default.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| path | No | ||
| source | No | ||
| target_profile | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states 'compiler-emitted metadata' and 'summary by default', but does not reveal whether the tool is read-only, any side effects, required permissions, or error behavior. This is insufficient for an agent to safely invoke the tool.
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 sentence, which is concise. It front-loads the core topic ('Compiler-emitted metadata'). However, it is too brief to be fully effective; it sacrifices necessary detail for brevity, making it less useful despite being short.
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 4 parameters, no output schema, and no annotations, the description is severely incomplete. It lacks details on parameter semantics, return format, usage context, and any constraints. An agent cannot reliably invoke this tool based on the provided information.
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 0%, so the description must compensate for missing parameter documentation. However, the description does not explain the purpose of any of the four parameters (full, path, source, target_profile). The only hint is 'summary by default', which vaguely relates to the 'full' boolean parameter, but agents cannot infer correct usage.
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 'compiler-emitted metadata: resources, actions, effects, obligations' and mentions 'summary by default'. This specifies the verb (retrieve metadata) and resource (compiler-emitted metadata), and the phrase 'by default' hints at a default behavior, distinguishing it from siblings like cellc_check or cellc_explain.
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 does not provide explicit guidance on when to use this tool vs alternatives. It only implies that 'summary by default' is suitable for quick overviews, but fails to mention when to use other parameters or how to choose between siblings such as cellc_check or cellc_explain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: type-checking (cellc_check), verifier obligations (cellc_constraints), error explanation (cellc_explain), examples (cellc_get_example, cellc_list_examples), language reference (cellc_language_reference), and metadata (cellc_metadata). No overlap in functionality.
All tools start with 'cellc_' prefix, but the naming pattern is inconsistent: some use verbs (cellc_check, cellc_explain, cellc_get_example, cellc_list_examples) while others are nouns (cellc_constraints, cellc_language_reference, cellc_metadata). This mixed convention reduces predictability.
With 7 tools covering essential aspects of CellScript contract development (checking, constraints, error help, examples, language reference, metadata), the count is well-scoped and appropriate for the domain.
The tool set covers key workflows: type-checking, error resolution, language reference, and example retrieval. Minor gaps exist (e.g., no tool to fetch a specific example by name or compile a contract), but the core development cycle is supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Architecture compiler for AI code. 11 tools, 92 actions, 872 Lean4 proofs, 100/100 self-cert.
Create, test and play AI-native games through server-authoritative contracts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/toastmanAu/cellc-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
