io.github.jean-johnson-zwix/arm-code-mcp

Health-check — returns "pong: <message>". Example: ping(message="hello") → "pong: hello".

Parse the text output of `perf report --stdio` and return the top hot symbols. Use this tool when a user pastes `perf report --stdio` output and wants to know which functions are consuming the most CPU cycles on their Arm64 system. Args: perf_report_text: Raw stdout of `perf report --stdio` or similar. top_n: Maximum number of hot symbols to return (default 10). min_overhead_pct: Filter out symbols below this overhead percentage (default 0.5). Returns: { "summary": {"total_samples": int, "total_events": int | None, "command": str | None}, "hot_symbols": [ {"overhead_pct": 12.34, "samples": 1234, "command": "...", "module": "...", "symbol": "..."}, ... ], "warnings": [...] } Example: analyze_perf_output(perf_report_text=text, top_n=5, min_overhead_pct=1.0) returns the 5 hottest symbols above 1% overhead.

Suggest NEON SIMD intrinsics for an operation description, ranked by semantic similarity. Use this tool when a user asks which NEON intrinsic to use for a hot loop, wants to vectorize an operation on Arm64, or mentions intrinsic names like vmlaq_f32. Args: operation_description: Natural-language description of the operation (e.g., "vectorized 32-bit float multiply-accumulate" or "vmlaq_f32"). target_arch: Target Arm architecture — "armv8-a" (default), "armv8.2-a", or "armv9-a". top_k: Number of suggestions to return (default 5). Returns: { "matches": [ {"intrinsic": "vmlaq_f32", "signature": "...", "header": "<arm_neon.h>", "min_arch": "armv8-a", "description": "...", "score": 0.83}, ... ], "notes": "Filtered to armv8-a. KB contains N entries (M compatible)." } Example: suggest_neon_intrinsic("32-bit float fused multiply-add") returns vfmaq_f32 at rank 1.

Scan a dependency manifest for known arm64 compatibility issues. Use this tool when a user wants to know whether their Python dependencies will install on an Arm64 server (AWS Graviton, Google Axion, Ampere Altra, Raspberry Pi 5), or when they ask why a package fails on arm64. Args: file_content: Raw text of the dependency manifest. file_type: One of "requirements.txt", "pyproject.toml", or "Dockerfile". Returns: { "checked": ["numpy", "tensorflow", ...], "issues": [ {"package": "tensorflow", "severity": "warning", "message": "Official TensorFlow PyPI wheels are x86-only..."} ], "summary": "Checked 5 package(s): 1 warning(s)." } Severity levels: "error" = no arm64 wheel at all (e.g. GPU-only packages); "warning" = arm64 wheel exists but requires workaround; "info" = wheel available but version constraint or system lib note applies. Example: check_arm64_deps(content, "requirements.txt") flags cupy (error), tensorflow (warning), and reports numpy arm64 wheel availability (info).