Loading ToolBench
Model Context Protocol (MCP) server exposing MESH-API's core functions and extensions as MCP tools, enabling external AI agents and services to interact with Meshtastic and MeshCore mesh networks—sending/receiving messages, querying nodes, running commands, and invoking installed extensions.
Server defines 9 tools with reasonable naming (verb_noun pattern) and mostly complete schemas. However, descriptions vary significantly in quality, some are detailed (mesh_send_message, mesh_ai_query) while others are generic (mesh_list_commands, mesh_run_command). Parameter descriptions are present but often lack constraints (e.g., no min/max for 'limit' in mesh_get_messages). Error handling is minimal, no recovery guidance or actionable error messages visible in schemas. Output schemas are not documented. Tool #9 (meshtastic_mesh) is inferred from TypeScript source, not the primary Python MCP server, creating ambiguity about which is canonical.
Ask the MESH-API-configured AI provider a question and get its response text (the same AI used by the mesh chatbot).
Get the most recent mesh messages (chat log) across both networks, newest last. Useful to read what is happening on the mesh.
List available channels for each network (Meshtastic channel names and MeshCore channels / group chats).
List all slash commands available on this MESH-API node (built-in, custom, and extension-provided).
List known nodes across both mesh networks, optionally filtered by network. Returns id, names, and network for each node.
Get the connection status of both radios (Meshtastic and MeshCore), including which are enabled/connected and basic stats.
Output schemas not documented. Tools return unstructured responses (e.g., 'Get the most recent mesh messages') without specifying field names, types, or structure. LLMs cannot plan downstream calls or extract data reliably.
Parameter constraints missing. 'limit' in mesh_get_messages has no min/max (description says 'default 20, max 100' but not in schema). 'message' in mesh_send_message lacks length constraints. LLMs may pass invalid values.
No error handling guidance. Schemas lack error response documentation. If mesh_send_message fails (invalid node_id, network down), LLM has no recovery path. No actionable error messages defined.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Run a MESH-API slash command exactly as if a mesh user sent it (e.g. '/ping', '/weather 90210'). Returns the command response.
Send a text message over the mesh. Choose network (meshtastic, meshcore, both, or auto), and either broadcast on a channel index or direct-message a node by id.
Interact with a Meshtastic LoRa mesh network via MESH-API. Actions: list_nodes, get_messages, send_message, get_status, get_commands.
Tool #9 (meshtastic_mesh) is inferred from TypeScript/OpenClaw source, not the primary Python MCP server. Unclear if this is the canonical tool or a separate plugin. Creates ambiguity about which tool set agents should use.
Generic descriptions for discovery tools. 'mesh_list_commands' and 'mesh_list_channels' lack context on when to call them or what structure they return. Descriptions under 60 chars invite LLM confusion.