Loading ToolBench
Your friendly AI assistant for Windows desktop automation and Microsoft 365 integration. One-click setup for VS Code agent mode.
This MCP server exhibits critical gaps in definition quality. Tools are defined with names that lack clear action verbs (e.g., 'clippy.fleet-status', 'clippy.agent-catalog' instead of 'get_fleet_status', 'list_agents'). Descriptions are present but generic and often under 100 characters, failing to explain WHEN to use each tool or what dependencies exist. Input schemas are visible for most tools (e.g., 'clippy.commander.submit' has prompt and mode params with enums), but several tools like 'clippy.fleet-status' and 'clippy.agent-catalog' have empty input schemas ({}), indicating no parameters, unusual for data retrieval tools and suggests incomplete design. Most critically, parameter descriptions are minimal or absent in the schema definitions shown. Output schemas are completely undocumented, we cannot see what fields are returned, making it impossible for an LLM to chain tools or extract required data. Error handling guidance is absent from all tool descriptions. The server lacks composition guidance (e.g., how to use 'session-inspector' to then call 'commander.submit'). Tool names use a dot-notation namespace prefix ('clippy.') rather than verb_noun convention, which is non-standard for MCP tools.
List available agents and their capabilities in the Clippy ecosystem
Broadcast a message to multiple sessions identified by sessionIds
Submit a prompt to the Commander orchestration engine in the specified mode (Agent, Plan, or Swarm)
Retrieve the current status and state of the Clippy fleet
Link or unlink a session to/from a named group
Inspect and retrieve details about a specific session (read-only operation)
Empty input schemas on discovery tools (fleet-status, agent-catalog). Both declare {} as input, yet likely require parameters for filtering or pagination. Empty schemas signal incomplete tool definitions and prevent LLMs from understanding what can be passed.
Output schemas completely undocumented. The tool specifications shown do not include what fields are returned, data types, or structure. Without documented outputs, LLMs cannot reliably chain tools or extract downstream parameters. Example: 'clippy.agent-catalog' returns agents, are they objects with id/name/capabilities? Unknown.
Tool names do not follow verb_noun convention. Names like 'clippy.fleet-status' and 'clippy.agent-catalog' are ambiguous, 'fleet-status' sounds like a noun phrase, not an action. Should be 'get_fleet_status' or 'list_agents'. Naming is non-standard and makes LLM selection harder.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Parameter descriptions are minimal or missing from schema definitions. Example: 'clippy.link-group' has an 'op' enum parameter with description 'The operation: link or unlink', but no explanation of what it means to 'link' or 'unlink' a session to a group, or why you'd do it. LLMs cannot infer context.
No error handling guidance in descriptions. Descriptions do not explain what can go wrong, how to recover, or what inputs are invalid. Example: 'Submit a prompt to the Commander' does not mention what happens if the mode is invalid, if the session does not exist, or what the prompt format must be.
Tool descriptions are generic and under 100 characters (baseline for A+ is 194 chars, p10=34, p90=392). Example: 'Retrieve the current status and state of the Clippy fleet' (60 chars) does not explain what 'fleet' means, when to call this vs other tools, or what data is returned. Too brief to guide LLM selection.
No composition guidance. Descriptions do not explain dependencies or chains. Example: 'session-inspector' is read-only, but how does it relate to 'link-group' or 'commander.submit'? Are they used in sequence? A description like 'Use this to retrieve session details before linking to a group' would guide LLM planning.