Loading ToolBench
A Model Context Protocol server for Ionic and Capacitor
This MCP server has 42 tools with severe quality issues across naming, descriptions, parameter documentation, and schema completeness. Most tools (39 of 42) have EMPTY input schemas `{}`, meaning they accept no parameters despite performing operations that clearly require configuration. Tool descriptions are either missing entirely or extremely minimal (under 20 chars). Parameter naming conventions are inconsistent. No input validation guidance, no output schema documentation, and no error recovery hints. The server exposes CLI commands (ionic_start, capacitor_build, etc.) with zero documentation of what they do, when to use them, or what parameters they accept. This violates core patterns: tool-description, constrained-input, response-shaper, and recovery-guide. While tool names mostly follow verb_noun convention (minor positive), the complete absence of parameter schemas and descriptions for 95% of tools makes this unsuitable for production agent use.
39 of 42 tools have empty input schemas `{}` with no parameters. These tools appear to wrap CLI commands but provide zero parameter documentation, making it impossible for LLMs to configure their behavior. Tools like `ionic_start`, `ionic_build`, `capacitor_add` should accept parameters for app name, platform, flags, etc., but are defined as parameter-less.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 29 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
41 of 42 tools are missing descriptions entirely or have descriptions under 20 characters. Tool descriptions must explain WHAT the tool does, WHEN to use it vs similar tools, and any prerequisites. Without descriptions, LLMs cannot determine when or why to select each tool. Example: `ionic_start` has no description, an LLM cannot know whether this starts a dev server, scaffolds a new project, or initializes a configuration.
No output schemas are documented in the visible source code. Tools like `get_all_capacitor_plugins` return list results but LLMs have no documented schema for the returned objects (e.g., what fields do plugin objects contain?). Without output documentation, LLMs cannot plan downstream tool calls or extract the right data.
CLI wrapper tools (ionic_*, capacitor_*) provide no error recovery guidance. When a tool fails (e.g., `ionic_build` fails due to missing platform), the error response likely contains raw CLI output without actionable guidance. Errors should state: what went wrong, why, and what the LLM should try next.
No pagination support evident in any tool returning lists. Tools like `get_all_capacitor_plugins`, `get_all_capacitor_community_plugins`, `get_all_capgo_plugins` return full lists with no limit, offset, or cursor parameters. Large result sets waste context and risk timeout. Tools should accept page/limit and return next_cursor.
CLI-wrapping tools lack parameter documentation. Tools like `capacitor_add` and `ionic_generate` wrap CLI commands that accept many flags and options, but the tool definition shows `Input: {}`, LLMs have no way to know what parameters are accepted or their effects.
Destructive operations (ionic_build, capacitor_sync, ionic_start, capacitor_add) lack confirmation patterns or dry-run support. These operations modify the file system and could have unintended consequences. No mechanism to preview changes before execution.