MLX Model Scout
Related Servers
Alternatives to MLX Model Scout
No user-submitted related servers found.
Related Servers
- AlicenseAqualityBmaintenanceEnables AI agents to search, compare, and right-size Hugging Face models, including estimating whether a model fits in available GPU VRAM before downloading it.5MIT
- AlicenseNot gradedqualityAmaintenanceVendor-neutral local LLM inference benchmark and hardware-config advisor for mlx and llama.cpp. Exposes an MCP tool that measures real tokens/second on your own hardware.16 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables agents to pull measured local-LLM benchmark data and hardware-aware model picks — ranked configs with decode tok/s, quant and backend details, hardware catalogues, and repo submissions for review. Answers questions like "what should I run on a Strix Halo for coding?" with sourced numbers rather than invented ones.43 npmMIT
- AlicenseNot gradedqualityBmaintenanceGives coding agents searchable access to MLX, MLX Data, and MLX LM documentation so they can check the docs before writing MLX code. Runs locally on Apple silicon with no account or API key, and works offline after the first search.MIT
- AlicenseAqualityAmaintenanceEnables local Laya-MLX typed decisions (classification, scoring, risk routing, and yes/no) for coding agents like Codex, Claude Code, DeepSeek Harness, and Pi via MCP, running entirely on Apple Silicon Macs.24MIT
- AlicenseAqualityAmaintenanceTell your AI agent what you want a model to do. It searches Hugging Face for each part of the job and tells you which parts already exist there: which are an exact fit, which to fine-tune, which to train, and which are just code. Every model it names is real, current, and sized for your hardware.3623 npm1MIT
TDQS
Scored across 11 tools
Most tools occupy clearly distinct roles (detect_hardware vs list_hardware_profiles, estimate_fit vs analyze_model, run/continue_recommendation), and descriptions spell out boundaries well. The one genuinely confusable pair is analyze_model vs analyze_model_card, which share a near-identical name and both operate on a model, though one is deterministic config parsing and the other an LLM card summary.
Every tool follows a snake_case verb_noun pattern (detect_hardware, scan_mlx_models, estimate_fit, save_report, run_benchmark), with the run/continue pair used deliberately for a resumable workflow. No mixed conventions or vague bare verbs.
11 tools is well within a healthy range and each maps to a step in the scout -> analyze -> recommend -> report pipeline. Nothing appears redundant, and the checkpoints reuse continue_recommendation rather than spawning per-stage tools.
The core lifecycle is covered end to end: hardware profiles, Hub scanning, model/card analysis, fit estimation, a checkpointed recommendation run, and report persistence. Gaps are the two explicitly MOCK tools (run_benchmark, download_model) that are dead ends for real benchmarking/acquisition, and there is no visibility into saved reports or run history.