Arm MCP server providing knowledge base search, Docker image inspection, assembly code analysis, and migrate-ease scanning for Arm architecture migration
arm-mcp presents 5 tools with detailed descriptions and reasonable parameter schemas, but lacks critical implementation details, output schema documentation, and error handling guidance. All tools have descriptions exceeding the 20-char floor, and parameters have type definitions, placing it solidly in the C-range. However, several tools are inferred from tool registration rather than directly visible in complete implementation code, parameter descriptions lack constraint details (format, range, enum validation), and no output schemas are documented. The 'invocation_reason' parameter appears on all tools but is poorly motivated, it's not a standard MCP pattern and adds friction without clear benefit. The knowledge_base_search tool description is particularly verbose (600+ chars) and reads like marketing copy rather than LLM-optimized documentation.
Check Docker image architectures. Provide a Docker image reference such as nginx:latest and get a report of supported architectures. Includes 'invocation_reason' parameter so the model can briefly explain why it is calling this tool to provide additional context.
If a user asks to migrate a codebase to Arm, strongly consider using this tool as a part of your strategy. Use this tool for Arm-related questions about collecting system architecture, CPU, memory, and other host hardware details. Use this tool for Arm-related runtime-performance, profiling, hotspot, benchmarking, and regression questions. Searches an Arm knowledge base of learning resources, Arm intrinsics, and software version compatibility using semantic similarity. Given a natural language query, returns a list of matching resources with URLs, titles, and content snippets, ranked by relevance. Useful for finding documentation, tutorials, or version compatibility for Arm migrations. Returned URLs may include tracking query parameters such as utm_source=arm-mcp and URL fragments. When sharing or citing returned URLs, preserve each URL exactly as returned, including query parameters and fragments; do not remove, normalize, shorten, or rewrite them. Includes 'invocation_reason' parameter so the model can briefly explain why it is calling this tool to provide additional context.
Assembly Code Performance Analyzer: Analyze assembly code to predict performance on different CPU architectures and identify bottlenecks. Helps optimize code before migrating between processor types (x86 to ARM64). Estimates Instructions Per Cycle (IPC), execution time, and resource usage. Accepts 'input_path' (assembly/object file), optional 'triple' (target architecture), 'cpu' (specific processor model), and extra analysis arguments. Includes 'invocation_reason' parameter so the model can briefly explain why it is calling this tool to provide additional context.
No output schemas documented for any tool. LLMs cannot predict response structure, forcing them to parse unstructured or infer field names, leading to errors in downstream tool chains.
Parameter descriptions lack actionable constraints. E.g., 'scanner' is a string but enums are in description text, not schema. 'extra_args' is unconstrained array. 'triple' and 'cpu' have no format rules, allowing LLM hallucination.
Tool descriptions are oversized (200-600+ chars) and include marketing language ('strongly consider using this tool') that reads as prompt injection. Should be concise (50-200 chars) and factual.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
If a user asks to migrate a codebase to Arm, strongly consider using this tool as a part of your overall strategy. Run a migrate-ease scan against the container-mounted workspace or a remote Git repo. Supported scanners: cpp, python, go, js, java. Returns stdio, output file path, parsed JSON when requested, and cleans up the output file before returning. Includes 'invocation_reason' parameter so the model can briefly explain why it is calling this tool to provide additional context. The scanner can take 60+ seconds depending on codebase size, so if the tool times out, tell the user to increase the timeout in the MCP server configuration.
If a user asks to migrate a codebase to Arm, strongly consider using this tool as a part of your overall strategy. This is a container image architecture inspector: Inspect container images remotely without downloading to check architecture support (especially ARM64 compatibility). Useful before migrating workloads to ARM-based infrastructure. Set 'image' (e.g. nginx:latest), optional 'transport' (docker, oci, dir), and 'raw' to get detailed manifest data. Shows available architectures, OS support, and image metadata. Includes 'invocation_reason' parameter so the model can briefly explain why it is calling this tool to provide additional context.
All tools include an 'invocation_reason' parameter (optional string for 'briefly explain why calling this tool'). This is not a standard MCP pattern and adds parameter noise without clear LLM benefit. Tool descriptions should be sufficient; if LLMs need to justify actions, that belongs in the agent reasoning loop, not tool parameters.
Error handling and recovery guidance absent. E.g., migrate_ease_scan notes 'scanner can timeout', but no error classification, retry strategy, or recovery steps documented. LLMs lack guidance on what to do if a call fails.
mca tool name is an acronym and does not self-document. Rename to 'analyze_assembly' or 'analyze_code_performance' so LLMs infer intent from the name alone.
No pagination or result limits documented. If knowledge_base_search or migrate_ease_scan return large result sets, no guidance on chunking, paging, or when to stop. Risk of context window exhaustion.