Loading ToolBench
Extension host for DSH AI Hub that manages plugins, tools, and capabilities through HTTP API with authorization
17 tools with significant structural gaps. All tools have descriptions (good), but most lack explicit input schema validation and parameter-level descriptions. Agent Reach tools (1-3) have minimal schemas; vision tools (4-7) have better parameter coverage but no output schemas documented. WeCom tools (8-17) use a generic 'operation' + 'request_json' pattern that delegates schema responsibility to an external 'wecom-unified Skill', this breaks composability and makes validation opaque to the MCP layer. No tool declares error recovery guidance, output structure, or pagination. Naming is verb-noun compliant but generic (e.g., 'wecom_*_call' repeats 'call' across 10 tools, reducing clarity). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE vs READ_ONLY).
Perform a real connectivity probe for the Agent Reach public-web backend.
Read one public HTTP(S) source as Markdown through the AI Hub-authorized Agent Reach plug-in. Local and private-network URLs are rejected.
Search the public web for current information through the AI Hub-authorized Agent Reach plug-in. Returns Markdown with source URLs.
Compare two equal-size workspace images pixel by pixel and return bounded difference metrics.
Create a cropped PNG derived from one workspace image. The output remains inside the workspace.
Inspect dimensions, format, color space, channels, alpha, and orientation of one workspace image.
WeCom tools (8-17) delegate schema and validation to external 'wecom-unified Skill' via opaque 'request_json' string parameter. This breaks MCP composability, the MCP layer cannot validate inputs, LLMs cannot infer valid operations, and error recovery is impossible without reverse-engineering the Skill spec.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., does agent_reach_search return URLs? Does vision_understand return bounding boxes?). Baseline: 100% of A+ tools document return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Analyze one workspace image using a vision model with a user-provided prompt or a fixed operation (describe, ocr, detect, ground).
Create, list, search, inspect, update, or cancel WeCom schedules; query free time, buildings, and meeting rooms.
Search the WeCom directory through the official CLI before inviting named participants.
Search, read, create, append, overwrite, or rename WeCom Word documents through fixed official operations.
List, search, or inspect files in WeCom Drive through fixed official operations. Local file paths are never accepted.
Read the identity of the WeCom account currently authorized in Harness.
Search, read, or send WeCom mail through fixed official operations.
Create, list, search, inspect, update, or cancel online WeCom meetings and read meeting transcripts when authorized.
List the bot recent sessions or actively send a message to an authorized WeCom session. This tool does not receive inbound message content.
Read or update ranges, append rows, and create WeCom sheets through fixed official operations.
List, inspect, create, update, or finish WeCom todo items through fixed official operations.
No error handling guidance. Tools do not document what errors are retryable, user-fixable, or fatal. No recovery suggestions (e.g., 'If agent_reach_fetch fails, try agent_reach_search first'). Baseline: A+ tools include recovery guides.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels declared (READ_ONLY vs WRITE). LLMs cannot infer safety properties and may retry destructive operations or skip idempotent retries.
WeCom tool naming uses generic 'wecom_*_call' pattern (10 tools). This reduces clarity, LLMs cannot distinguish wecom_calendar_call from wecom_meeting_call by name alone. Baseline: 90% of A+ tools use specific verb_noun naming.