Integrates with Binary Ninja for binary analysis, allowing Cline to leverage Binary Ninja's reverse engineering capabilities to analyze and understand binary files through an MCP server bridge.
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., "@Binary Ninja Cline MCP Server analyze this binary and show me the main function"
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.
An MCP server for Cline that works with Binary Ninja (Personal License)
This repository contains an MCP server that allows Cline to analyze binaries using Binary Ninja. Note: Not all files will be used, there is also prototype of using headless Binary Ninja but my license is Personal so I can't test it.
Install the latest of Binary Ninja MCP Plugin https://github.com/fosdickio/binary_ninja_mcp
Open your binary and start the MCP server from within Binary Ninja.
Open a terminal and run python binary_ninja_mcp_http_server.py --port 8088
Open another terminal and run npm start
Open Cline and add the following tool:{ Example:
{
"mcpServers": {
"BN MCP": {
"command": "node",
"args": ["/home/matteius/binary_ninja_cline/bn_cline_mcp/binaryninja-mcp-bridge.js"],
"env": {
"BN_HTTP_SERVER": "http://localhost:8088"
},
"autoApprove": [],
"disabled": false,
"timeout": 30
}
}
}
Decompile a function to C
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| function | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Decompile') but doesn't reveal whether this is a read-only operation, if it requires specific permissions, what happens on failure, or any rate limits. For a tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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 extremely concise—a single sentence with zero waste. It's front-loaded with the core action and target, making it easy to scan. Every word earns its place, though this brevity contributes to gaps in other dimensions.
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 complexity of decompilation (a non-trivial operation), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what the output looks like (e.g., C code format), error conditions, or dependencies. For a tool with 2 required parameters and no structured guidance, this is inadequate.
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 schema description coverage is 0%, meaning neither parameter ('path' or 'function') has descriptions in the schema. The tool description adds no meaning beyond the parameter names—it doesn't explain what 'path' refers to (e.g., file path, binary path) or what 'function' represents (e.g., function name, address). With 2 undocumented parameters, the description fails to compensate for the coverage gap.
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 ('Decompile') and the target ('a function to C'), providing a specific verb+resource combination. It distinguishes from sibling tools like 'disassemble_function' by specifying decompilation to C rather than disassembly. However, it doesn't fully differentiate from 'list_functions' or 'get_binary_info' in terms of scope or output format.
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 guidance on when to use this tool versus alternatives like 'disassemble_function' or 'list_functions'. There's no mention of prerequisites, context, or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disassemble a function from a binary
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| function | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify if this is a read-only operation, what permissions are needed, how errors are handled, or what the output format looks like. The description is functional but incomplete for safe agent use.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of disassembling functions from binaries, no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool returns, error conditions, or behavioral constraints, leaving the agent with insufficient context for reliable use.
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 schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'a function from a binary' which hints at the 'function' parameter, but doesn't explain what 'path' refers to (e.g., file path, binary identifier) or provide any format details. This leaves significant gaps in parameter understanding.
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 ('disassemble') and target ('a function from a binary'), which is specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'decompile_function' or 'list_functions', which would be needed for a perfect score.
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 guidance on when to use this tool versus alternatives like 'decompile_function' or 'list_functions'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get binary metadata
| Name | Required | Description | Default |
|---|---|---|---|
| path | 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 of behavioral disclosure. 'Get binary metadata' implies a read-only operation, but it doesn't specify whether this requires file access permissions, what happens if the path is invalid, or if there are rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise with just three words, front-loaded with the core action. There's no wasted language, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
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 complexity (a tool with one parameter but no schema descriptions or annotations) and lack of output schema, the description is incomplete. It doesn't explain what metadata is returned, error conditions, or usage context. For a tool in a server with sibling analysis tools, more detail is needed to ensure proper agent selection.
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 schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'binary metadata' but doesn't explain the 'path' parameter's semantics, such as what format the path should be in (e.g., file path, URL) or what constitutes a valid binary. The description adds minimal value 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 'Get binary metadata' states a clear verb ('Get') and resource ('binary metadata'), but it's vague about what specific metadata is retrieved. It doesn't differentiate from sibling tools like 'list_functions' or 'disassemble_function', which might also provide metadata about binaries. The purpose is understandable but lacks specificity.
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 is provided on when to use this tool versus alternatives like 'list_functions' or 'disassemble_function'. The description doesn't mention prerequisites, exclusions, or context for usage. It's a basic statement of function without operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List functions in a binary
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List functions') but lacks details on traits such as whether it's read-only (likely, but not confirmed), performance characteristics (e.g., speed for large binaries), error handling (e.g., invalid path), or output format (e.g., list of names, addresses). This leaves significant gaps for an agent to understand how the tool behaves.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by conveying essential information concisely.
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 complexity (binary analysis tool), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral aspects like safety (read-only vs. destructive), output details (what 'list' returns), or error conditions. For a tool interacting with binaries, more context is needed to ensure proper usage by an agent.
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 1 parameter ('path') with 0% description coverage, so the description must compensate. However, it adds no meaning beyond the schema—it doesn't explain what 'path' refers to (e.g., file path to binary, URL), expected format, or constraints (e.g., must be local file). This fails to address the low schema coverage, resulting in inadequate parameter documentation.
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 ('List') and target resource ('functions in a binary'), making the purpose immediately understandable. It distinguishes itself from siblings like 'decompile_function' or 'disassemble_function' by focusing on listing rather than analyzing individual functions. However, it doesn't specify what kind of functions (e.g., exported, all, by section) or the format of the listing, keeping it from a perfect score.
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 is provided on when to use this tool versus alternatives. While the description implies it's for listing functions, it doesn't mention prerequisites (e.g., binary must be executable), exclusions (e.g., not for source code), or direct comparisons to siblings like 'get_binary_info' for broader metadata. Usage is implied but not clearly defined.
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: decompile_function produces C code, disassemble_function outputs assembly, get_binary_info retrieves metadata, and list_functions enumerates functions. There is no overlap in functionality, making tool selection unambiguous.
All tools follow a consistent verb_noun pattern with snake_case (e.g., decompile_function, disassemble_function). The naming is predictable and readable throughout the set.
With 4 tools, the count is reasonable for a binary analysis server, covering core operations like listing, disassembling, decompiling, and metadata retrieval. It might benefit from additional tools (e.g., for editing or searching), but it's well-scoped for basic tasks.
The tools cover fundamental read-only operations for binary analysis (list, disassemble, decompile, info), but there are notable gaps such as no tools for modifying binaries, searching for patterns, or handling symbols. This limits advanced workflows but supports basic inspection.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/opensensor/bn_cline_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
