Skip to main content
Glama

Run Template

run_template

Executes a 010 Editor Binary Template (.bt) against a data file headlessly via CLI, enabling structured parsing and analysis of binary data.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
data_fileYes
exit_modeNoexitnoerrors
timeout_secNo
template_argsNo
template_fileYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools