Reverse engineering is rarely confined to one tool. You have a debugger, a fuzzer, a YARA rule set, a sandbox, an internal threat-intel database, a notes folder full of past write-ups, a string-decoder script (or multiple of them).

Although Sidekick lives inside Binary Ninja, the work extends outside of it. So, Sidekick has two ways to bring the rest of your toolbox into play:

  1. MCP servers: stateful, external programs that expose tools the agent can call.
  2. Sidekick Library: named, parameterized scripts that can do whatever Python can do.

Both are first-class. Sidekick can call an MCP tool the same way it calls a built-in tool. It can also run Library scripts (subject to the same permission system as everything else).

Note: You can manually type /<library-item> in a chat to invoke a Library item. The slash command is a shortcut that schedules a tool call for Sidekick, useful when you want to be explicit.

Let’s quickly introduce each of these to see how they work, when to use which, and how they can work together to make Sidekick the locus of your reversing workflows.

MCP: Live Capability Extension

The Model Context Protocol is an open spec for letting agents talk to external tool servers over stdio. Sidekick is an MCP client. If a program speaks the protocol, Sidekick can load its tools.

The configuration file lives at $BN_USER_DIRECTORY/sidekick/config/mcp_tools_config.json and looks something like this:

{
  "version": "1.0",
  "servers": [
    {
      "name": "git",
      "tags": ["mcp.git"],
      "server_config": {
        "command": ["uvx", "mcp-server-git", "--repository", "/path/to/source"]
      },
      "tools": [
        { "name": "git_log" },
        { "name": "git_diff" }
      ]
    },
    {
      "name": "filesystem",
      "tags": ["mcp.filesystem"],
      "server_config": {
        "command": ["uvx", "mcp-server-filesystem", "/home/user/samples"]
      },
      "tools": [
        { "name": "read_file" },
        { "name": "list_directory", "alias": "list_dir" }
      ]
    }
  ]
}

That’s it. Restart Binary Ninja and those four tools show up alongside Sidekick’s built-ins. The agent can now use those tools to read source code from a git repo, diff revisions, and pull related files from a samples directory.

Note: You can also edit the MCP configuration via the UI: select Plugins -> Sidekick -> Configure MCP Servers... from the menu bar.

A few things worth noting:

  • Tool permissions still apply. MCP tools route through the same approval system as built-in tools. Pre-approve them by tag (e.g., mcp.git, mcp.filesystem) when you trust the server, or require per-call confirmation when you don’t.
  • MCP tools extend the Sidekick agent, not the built-in suggest/repair operations. MCP tools are available when Sidekick is reasoning in a conversation. Single-shot Suggest actions from the main menu are limited to their built-in toolset.

The full config schema, tagging model, and a worked example of writing your own server are in the MCP tools guide.

Sidekick Library: Simple, Direct Workflows

MCP is a good option when you have a long-running tool server, possibly written in another language, possibly already maintained by someone else. A simple Python script is an alternative lightweight option.

A library script is just Python. It can wrap a CLI tool, hit an internal API, run a YARA scan, parse a custom file format, or call out to anything else you’d reach for at a shell. It runs once, returns its output, and goes away. In effect, it’s a stateless alternative to standing up an MCP server: you trade persistent process and multi-tool-per-server for “I just want a callable named thing without too much fanfare.”

Library scripts can be run directly or run-and-fed-into-chat, and can be launched from the chat sidebar with a slash command. A script named “Recover Strings” becomes /recover-strings.

Accessing the Sidekick API

When you need to read or write Sidekick data structures — indexes, code maps, notebook entries, etc. — sidekick.api is readily accessible. For example, say you want to find every tail call in a binary and put it in an index for later reference. The script might look like this:

import sidekick.api as api
from binaryninja import MediumLevelILOperation

TAILCALL_OPS = {
    MediumLevelILOperation.MLIL_TAILCALL,
    MediumLevelILOperation.MLIL_TAILCALL_UNTYPED,
    MediumLevelILOperation.MLIL_TAILCALL_SSA,
    MediumLevelILOperation.MLIL_TAILCALL_UNTYPED_SSA,
}

api.get_index(bv, "tailcalls", create_if_missing=True)

tailcalls = [
    insn
    for func in bv.functions
    if func.mlil is not None
    for insn in func.mlil.instructions
    if insn.operation in TAILCALL_OPS
]

entries = api.add_index_objects(
    bv,
    "tailcalls",
    objects=tailcalls,
    prevent_duplicates=True,
)

print({"index": "tailcalls", "added": len(entries)})

That’s an example that uses the Sidekick API. A different Library script could just as easily shell out to any external tool, hit your team’s threat-intel REST API, run a YARA rule set against a buffer, or invoke a custom unpacker — none of which involves sidekick.api at all. The point is that Sidekick calls your “do this thing in Python script,” and what that thing does is up to you.

Let Sidekick Write the Script

Sidekick has an Automation specialist mode for writing scripts: ask Sidekick for a reusable workflow and it produces a Library item — a Python script, a local agent, a skill, or a small bundle.

Make me a Library script that lists every function over 100 basic blocks, semantic-searches each one for “cryptographic primitive”, and adds matches to an index called crypto-candidates.

The Automation specialist writes the entry point, declares its arguments, and hands you back a draft Library item. You review it, run it, and iterate if needed.

The same agent can write MCP servers when you describe what you want exposed. The boundary between “things Sidekick can do” and “things in your environment Sidekick should be able to do” is mostly a matter of how much you want to write yourself versus how much you want to ask for.

Putting it together

The two mechanisms do different jobs:

  • MCP is for persistent, multi-tool servers — possibly written in another language, possibly already maintained by someone else, possibly shared across teams. One config entry, many tools, a process that stays alive across calls.
  • Library Python is a simpler form: one named Python script, stateless. The agent can invoke it inline or you can launch it with a slash command, or click it in the sidebar. It can wrap whatever you want — including, when useful, calls back into Sidekick through sidekick.api.

Together, they provide each integration between Sidekick and the rest of your reversing toolbox.

If you want to try this on your own setup, the MCP tools guide, the Sidekick API reference, and the Library guide are the places to start. And if you don’t have Sidekick yet, grab a free trial.