Skip to main content
Glama
SemClone

mcp-semclone

by SemClone
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

scan_binary

Scan binary files (APK, EXE, DLL, SO, JAR) to detect open source components, extract license information, and identify security issues with adjustable analysis depth.

Instructions

Scan binary files for OSS components and licenses using BinarySniffer.

This tool analyzes compiled binaries, executables, libraries, and archives (APK, EXE, DLL, SO, JAR, etc.) to detect open source components, extract license information, and identify security issues.

Use this tool when:

  • Analyzing mobile apps (APK, IPA)

  • Scanning executables (EXE, ELF binaries)

  • Examining shared libraries (DLL, SO, DYLIB)

  • Analyzing Java archives (JAR, WAR, EAR)

  • Scanning firmware or embedded binaries

  • Generating SBOM for binary distributions

Args: path: Path to binary file or directory to analyze analysis_mode: Analysis depth - "fast" (quick scan), "standard" (balanced), or "deep" (thorough analysis, slower) generate_sbom: If True, generate SBOM in CycloneDX format check_licenses: If True, perform detailed license analysis check_compatibility: If True, check license compatibility and show warnings confidence_threshold: Minimum confidence level (0.0-1.0) for component detection output_format: Output format - "json", "table", "csv" (default: json)

Returns: Dictionary containing: - components: List of detected OSS components with licenses - licenses: Summary of all licenses found - compatibility_warnings: License compatibility issues (if check_compatibility=True) - sbom: CycloneDX SBOM (if generate_sbom=True) - metadata: Scan statistics and file information

Examples: # Scan an Android APK scan_binary("app.apk")

# Deep analysis with SBOM generation
scan_binary("firmware.bin", analysis_mode="deep", generate_sbom=True)

# Check license compatibility
scan_binary("library.so", check_compatibility=True)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
analysis_modeNostandard
generate_sbomNo
output_formatNojson
check_licensesNo
check_compatibilityNo
confidence_thresholdNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the tool's behavior: analyzes compiled binaries, detects components, extracts licenses, identifies security issues. Notes that deep mode is slower and requires more thorough analysis. No side effects or modifications are implied, but does not explicitly state it is read-only. Sufficient given no annotations.

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?

Well-structured with summary, usage list, Args, Returns, and Examples. Each section adds value, but the 'Use this tool when' list slightly overlaps with the file-type examples. Still efficient and front-loaded with key purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, one required, and presence of many sibling tools, the description covers all necessary aspects: tool purpose, target file types, parameter details, return structure, and examples. No output schema provided but return dictionary is described adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates fully with a detailed 'Args' section explaining all 7 parameters, including defaults, possible values (fast/standard/deep), numeric range for confidence_threshold, and boolean toggles. Examples illustrate usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Scan binary files for OSS components and licenses using BinarySniffer', with specific verb and resource. Lists many file types and distinguishes from siblings like scan_directory or check_package which handle non-binary or package-level analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'Use this tool when' list covering multiple scenarios (mobile apps, executables, libraries, firmware, SBOM generation). However, it does not mention when to avoid using it or suggest alternative sibling tools for specific subtasks (e.g., using generate_sbom alone).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SemClone/mcp-semclone'

If you have feedback or need assistance with the MCP directory API, please join our Discord server