MCP server

klarion-mcp exposes the analysis engine to a model the way the window exposes it to you. It speaks JSON-RPC 2.0 over stdio, one message per line, and is normally launched by an MCP client rather than run by hand.

Requires Klarion Pro or Team

Pointing a client at it

Most clients take a JSON block naming the command to run. The server needs no arguments and no configuration file:

mcp config

{  "mcpServers": {    "klarion": {      "command": "klarion-mcp",      "args": []    }  }}

That is the whole setup. The server holds no state between sessions and opens nothing until a tool asks it to.

Conventions worth knowing

Addresses go in loosely, come back as strings: An address may be given as a number, a "0x…" or decimal string, or a symbol or function name. It always comes back as a "0x…" string, because a JSON number cannot hold a 64-bit address exactly.
List tools are paginated: Anything list-shaped takes offset and limit and caps how much it returns in one call. Page through with the nextOffset that comes back rather than raising the limit and hoping.
An analysis error is a result, not a fault: A bad address or an unanalysed binary comes back as an ordinary tool result with isError set, so the model reads it as data about what to do differently instead of a broken transport.

an error result

{  "isError": true,  "code": "not_analysed",  "message": "This binary was opened with analyze=false.",  "notes": "Re-open it with analyze=true, or call open_binary again."}

What it will and will not do

No tool ever writes to the binary file on disk. Three of them change the analysis database: rename_function, set_comment and identify_functions when called with apply=true. Each announces that in capitals at the start of its own description, so a model sees it in tools/list before it decides to call.

run_script is the exception, and it is off by default. It executes arbitrary Lua the client supplies, which can read everything the read-only tools read and can also modify names, comments and types. Without the flag it is not registered at all and does not appear in tools/list:

opting in to scripting

{  "mcpServers": {    "klarion": {      "command": "klarion-mcp",      "args": ["--allow-scripting"]    }  }}

Even then the script sandbox still holds: Lua’s os and io libraries are never opened, so a script cannot reach the filesystem, spawn a process or open a socket, and a runaway loop is stopped on a wall-clock budget.

Tools

Twenty-two tools by default, twenty-three with --allow-scripting. Call open_binary first; every other tool takes the binaryId it returns.

Opening a binary

Call open_binary first. Every other tool takes the binaryId it hands back.

open_binary: Loads a file and returns a handle every other tool takes.

Finding your way around

address_info: What is this, and where am I, for one address.
list_functions: List or search recovered functions, paginated.
function_info: Everything the analysis model knows about one function.
list_segments: The segment table: units of mapping, not meaning.
list_sections: The section table: units of meaning, not mapping.
search_bytes: Find a byte pattern or a literal string in the image.

Reading code

disassemble: A window of instructions, or one whole function.
decompile: Pseudocode for one function, if a back end is available.
read_bytes: Raw memory read, with hex and an ASCII gutter.
xrefs: Cross-references to and from an address.
call_graph: What calls this function, and what it calls.

Symbols and data

list_imports: Imported symbols, flattened, paginated and searchable.
list_exports: Exported symbols, paginated and searchable.
list_strings: Recovered strings, paginated.
list_comments: Every annotation on the program, paginated.

C++ and library code

list_rtti_classes: The C++ class hierarchy recovered from the image.
rtti_class: One recovered class in full, vftable slots included.
load_signature_database: Opens a .sig file for identify_functions.
identify_functionswrites: Which recovered functions are known library code. Writes when called with apply=true.

Writing back

These change the analysis database. Each says so in capitals at the start of its own description, so a model reading tools/list sees it before it calls.

rename_functionwrites: Names an address, the same way the desktop interface does.
set_commentwrites: Attaches an analyst's note to an address.
run_scriptwrites: Executes Lua against an open binary. Not registered unless the server was started with --allow-scripting.

Prefer to drive it yourself?

The same engine is reachable from the command line and from Lua. An agent and a script see the same analysis model, so a project one renames is a project the other reads.

Scripting Editions