nano-mcp-termux
Related Servers
Alternatives to nano-mcp-termux
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityBmaintenanceSDK-free MCP server framework with self-implemented protocol engine (MCP 2026-07-28 + legacy), 19 built-in plugins, OWASP MCP Top 10 security, and zero external dependencies.52 npm2MIT
- AlicenseAqualityDmaintenanceA Python-based MCP server for file operations, web search with fallback, and task management, designed for Termux and extensible via plugins.32GPL 3.0
- FlicenseNot gradedqualityDmaintenanceA Python MCP server that allows ChatGPT to execute commands on your local PC via a secure Cloudflare tunnel.-
- FlicenseNot gradedqualityDmaintenanceA minimal MCP server built from scratch with no SDK, providing shell, file read/write, and URL fetch tools over Streamable HTTP and WebSocket.-
- AlicenseNot gradedqualityDmaintenanceA simple MCP Server with shell execution capabilities that can be run locally with Ngrok tunneling or hosted in an Ubuntu 24 Docker container.4MIT
- AlicenseNot gradedqualityDmaintenanceUltra-lightweight MCP server for Bun with full protocol compliance. Enables building MCP servers with tools, resources, and prompts using minimal dependencies and heap footprint.46,312 npmMIT
TDQS
Scored across 4 tools
Each tool targets a distinct question: device hardware (device_status), server process state (server_health), one candidate path (resolve_path), and the runtime path environment (path_adapter). Descriptions explicitly state sibling boundaries and even tell the agent which tool to use instead, eliminating misselection.
All names are snake_case and self-describing, with a clear domain term per tool. The pattern is noun_noun for three tools (device_status, server_health, path_adapter) and verb_noun for one (resolve_path), a minor deviation that is still highly readable.
Four tools is on the small side but each covers a distinct, non-overlapping diagnostic concern, so nothing feels padded or redundant. The surface is tightly scoped to introspection rather than trying to be a general shell wrapper.
The stated domain — read-only device, server, and path introspection — is well covered, including Android-specific concerns like phantom processes and shared-storage aliases. Minor gaps remain (no general process/network/log inspection), but agents can work around these via other tools or shell commands.