Click on "Deploy 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., "@010editor-mcp run Brother_DJF.bt on D:/samples/file.djf and report any parse 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 for SweetScape 010 Editor — run Binary Templates (.bt) and Scripts (.1sc) headlessly from an agent.
Requires a local 010 Editor install (this project does not redistribute 010 Editor).
Tool | Purpose |
| Locate |
|
|
| Same for |
CLI reference: Command Line Parameters.
Template/script basename is passed to -template: / -script:.
Working directory is the parent of that .bt / .1sc (010 also searches its configured Templates/Scripts dirs).
Prefer exit_mode=exitnoerrors so compile/run failures return a non-zero exit code.
Override the binary with EDITOR010_EXE (full path).
010 Editor does not concatenate adjacent C string literals. Keep SPrintf format strings as a single literal.
Related MCP server: Binary Ninja Headless MCP
# clone
git clone https://github.com/b1tninja/010editor-mcp.git
cd 010editor-mcp
uv syncOr:
pip install -e .Stdio MCP (example Cursor mcp.json):
{
"mcpServers": {
"010editor": {
"command": "uv",
"args": ["--directory", "D:/code/010editor-mcp", "run", "010editor-mcp"],
"env": {
"EDITOR010_EXE": "C:\\Program Files\\010 Editor\\010Editor.exe"
}
}
}
}After pip install -e .:
{
"mcpServers": {
"010editor": {
"command": "010editor-mcp"
}
}
}# from a directory that contains Brother_DJF.bt
& "C:\Program Files\010 Editor\010Editor.exe" `
"D:\path\to\file.djf" `
-template:Brother_DJF.bt `
-noui -nowarnings -exitnoerrors
echo $LASTEXITCODE010editor-reference — Binary Template / scripting docs skill
pfp — Python interpreter for a subset of .bt (no 010 license needed; incomplete vs full 010)
MIT — see LICENSE. 010 Editor is a commercial product of SweetScape Software; you need your own license to use this MCP against a real install.
Report whether 010 Editor is installed and which binary would be used.
Override discovery with env EDITOR010_EXE (full path to 010Editor.exe / 010editor). Also accepts ZERO10_EXE or 010EDITOR_EXE.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: 'Report' signals a read-only diagnostic, and it discloses the discovery mechanism plus the three environment variables that override it. It does not say what happens when no binary is found (error vs. negative result), which is the main remaining gap.
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?
Two short sentences, front-loaded with the core behavior; the env-var override detail is compressed into a single tight line with no 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?
A simple zero-parameter read tool with an output schema, so return-value detail is not needed. Discovery and override are covered; only the failure/no-install behavior is unstated, which is minor against the existing output schema.
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?
Zero parameters, so the baseline is 4. The description goes beyond the empty schema by documenting the out-of-band configuration surface (EDITOR010_EXE, ZERO10_EXE, 010EDITOR_EXE), which an agent would otherwise not know about.
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?
States a specific verb and resource: reports whether 010 Editor is installed and which binary discovery would resolve to. This is clearly distinct from the run_template/run_script siblings, though the description never names them explicitly.
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 only implied — an agent can infer this is a pre-flight/health-check tool to call before running scripts, but there is no explicit 'use this when...' clause or a statement of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a 010 Editor Script (.1sc), optionally on a data file.
Uses: 010editor [data] -script:.1sc -noui -nowarnings -<exit_mode> Cwd is the script's parent directory.
Scripts can call RunTemplate("foo.bt") and Exit(n) for custom codes.
| Name | Required | Description | Default |
|---|---|---|---|
| data_file | No | ||
| exit_mode | No | exitnoerrors | |
| script_args | No | ||
| script_file | Yes | ||
| timeout_sec | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, and it does disclose genuinely useful behavior: the exact command line, -noui/-nowarnings flags, that cwd is the script's parent directory, and that Exit(n) yields custom codes. However, it never states return format, safety/destructiveness, or failure semantics for executing arbitrary script code.
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?
Front-loaded with the core action, followed by compact usage detail. Every line is relevant; only the command-line line borders on redundant with the schema but adds exit_mode semantics.
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?
An output schema exists, so return values needn't be explained. For a 5-param execution tool, the description covers the key runtime context (cwd, CLI invocation, exit handling) that the bare schema cannot convey, leaving only script_args/timeout_sec light.
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 must compensate. It maps the data file and script file and hints at exit_mode via the -<exit_mode> flag, but says nothing about script_args or timeout_sec (both non-obvious with defaults like 120s).
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?
States a specific verb+resource (run a 010 Editor .1sc script, optionally on a data file) and distinguishes itself implicitly from run_template by noting scripts can call RunTemplate. Clear, though the sibling distinction is only implied.
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 explicit guidance on when to use run_script vs run_template, or on prerequisites/permissions for executing arbitrary scripts. The RunTemplate mention hints at the relationship but is a runtime detail, not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Binary Template (.bt) on a data file via 010 Editor CLI.
Uses: 010editor -template:.bt -noui -nowarnings -<exit_mode> Working directory is the template's parent folder so -template: resolves.
| Name | Required | Description | Default |
|---|---|---|---|
| data_file | Yes | ||
| exit_mode | No | exitnoerrors | |
| timeout_sec | No | ||
| template_args | No | ||
| template_file | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the concrete CLI invocation with -noui/-nowarnings and the meaningful working-directory resolution rule, which is real behavioral value. It omits whether the data file is mutated by the template, what permissions/Auth are needed, and how failures/timeouts surface.
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?
Two compact sentences plus the exact command form; the core action is front-loaded and nothing is padded. The invocation line, while useful, is the only slightly verbose element and it earns its place by explaining template resolution.
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?
This is an execution tool that shells out to a binary-processing CLI with five undocumented parameters and no annotations to lean on; the description says nothing about mutation of the data file, timeout behavior, or failure modes. The existing output schema removes the need to describe return values, but the input-side gaps remain large.
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% across five parameters, and the description only clarifies two indirectly: template_file (resolved via cwd) and exit_mode (the trailing CLI flag). data_file, timeout_sec, and template_args — including the null-default and array shape of the latter — receive no explanation anywhere.
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?
States a specific verb and resource — 'Run a Binary Template (.bt) on a data file via 010 Editor CLI' — which is far more precise than the title alone. It does not, however, differentiate itself from the sibling 'run_script', which is the most plausible confusion point.
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 only implied by the resource type: an agent can infer this is the tool for .bt templates, but nothing states when to prefer it over run_script or editor_status, nor are any preconditions (010 Editor installed, template path validity) called out.
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.
v0.1.0editor_statusrun_scriptrun_templateScored across 3 tools
The three tools have clearly distinct purposes: checking editor availability, running a Binary Template, and running a 010 Editor Script. There is no meaningful overlap between status reporting and execution.
Names are consistently snake_case and mostly follow verb_noun (run_template, run_script). editor_status is a noun phrase rather than a verb, a minor deviation but still clear and predictable.
Three tools is well-scoped for a focused CLI wrapper around 010 Editor. Each tool earns its place and there is no redundancy.
The surface covers the core lifecycle: verify installation, run templates, and run scripts. Minor gaps exist around discovering available templates/scripts or structured output handling, but agents can work around these via paths and script exit codes.
Run and manage H Company's Computer-Use Agents from any MCP client.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Official VirusTotal MCP server: threat reports, file and URL submissions, and analysis recovery.
Anonymous public tools for ZacharyR0th. See the published agent boundary before use.