Loading ToolBench
AI Growth OS — campaign-driven social engagement with UTM tracking, scheduling, and A/B experiments
The server defines 9 tools with basic descriptions and input schemas, but exhibits critical gaps in naming conventions, description quality, parameter documentation, and error handling. Tool names like 'gwanjong_setup', 'gwanjong_scout', 'gwanjong_strike' use a 'gwanjong_' prefix rather than action verbs (e.g., 'setup_platform', 'scout_discussions', 'post_comment'), violating the primary naming pattern from production baselines where 90% of A+ tools start with action verbs. Descriptions average ~100 characters and lack WHEN/WHY guidance expected by LLMs. Parameter descriptions are minimal, many lack detail on format, range, or constraints. No output schemas are documented. Error handling is absent; no tools explain what to do if something fails. Risk annotations (WRITE/READ_ONLY) exist but are not formalized in tool definitions. The server does not appear to implement tool annotations as defined in the current MCP spec (readOnlyHint, destructiveHint, idempotentHint). Overall, this is a D-grade server with basic structure but significant production-readiness gaps.
Approval queue management. action: list, get, approve, reject, retry, stats.
Asset library. action: save, search, list, use.
Campaign management. action: create, list, get, update, report.
Gather full context for a specific opportunity. Returns post, comments, and sentiment analysis.
Analytics and reporting. action: summary, conversions, trending, engagement.
Scheduled posting management. action: schedule, list, cancel, process_due.
Scout relevant discussions from developer communities. Returns top scored opportunities.
Tool names do not start with action verbs. All 9 tools use 'gwanjong_<noun>' pattern (gwanjong_setup, gwanjong_scout, gwanjong_strike) instead of verb-first naming (setup_platform, scout_discussions, post_engagement). Baseline: 90% of A+ tools start with action verbs (get_, create_, update_, delete_, search_, list_, send_). This violates pattern:tool and makes it hard for LLMs to infer intent from the name alone.
Descriptions are too short and lack WHEN/WHY guidance. Average description ~100 chars (baseline: 194 chars). Examples: 'Scout relevant discussions from developer communities. Returns top scored opportunities.' lacks guidance on when to use gwanjong_scout vs gwanjong_draft, or what preprocessing is needed. Pattern:tool-description requires: WHAT does it do, WHEN to use it, prerequisites.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Platform onboarding. action: check(status), guide(instructions), save(store keys+test).
Execute: comment, post, or upvote. Uses context cached from draft.
Parameter descriptions are incomplete or missing actionable constraints. E.g., gwanjong_setup 'action' param says 'check|guide|save' but does not explain what each action returns or when to use each. gwanjong_campaign 'data' param lists required fields inline ('requires name, objective, topics, platforms, icp, cta, kpi_target, status, start_date, end_date') but provides no format guidance (date format? ICP type?). Parameter descriptions should state format, range, and constraints directly per pattern:tool-description.
No output schemas are documented for any tool. LLMs cannot plan multi-step workflows without knowing what fields each tool returns. E.g., gwanjong_scout says it 'Returns top scored opportunities' but does not specify the structure: does it return [{'id': ..., 'title': ..., 'platform': ...}]? What does gwanjong_strike return after posting, the posted_id, timestamp, permalink? Pattern:tool and pattern:response-shaper require documented output schemas.
No error handling guidance. Tools declare WRITE risk but provide no recovery instructions. E.g., if gwanjong_strike fails to post due to rate limit or permission error, what should the agent do? Retry? Try a different platform? Wait? Pattern:recovery-guide and pattern:error-classification require errors to tell the LLM what to do next, categorize retryability, and provide actionable guidance.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present in tool definitions. Metadata lists 'Risk: WRITE/READ_ONLY' informally, but the MCP spec (current 2026-07-28) expects these as formal tool properties. This makes it harder for MCP clients to apply permission checks or retry logic automatically. All WRITE tools should have destructiveHint or at least idempotentHint documented.
Mutually exclusive and dependent parameters not documented. E.g., gwanjong_campaign 'data' param likely requires different fields for 'create' vs 'update' actions, but this dependency is not stated in parameter descriptions. gwanjong_assets has overlapping 'asset_id' (for use) and 'data' (for search), when is each required? Pattern:tool-description requires documenting parameter dependencies so LLMs do not pass conflicting inputs.
No pagination or limit enforcement documented. gwanjong_scout takes a 'limit' param but does not state min/max bounds (1 - 100?). gwanjong_insights returns 'trending' but does not specify max results. Pattern:paginated-result and mxe:enforce-result-limits require tools to cap results and accept page/offset/limit parameters to prevent context window exhaustion.
Ambiguous tool composition and chaining. No documentation on what gwanjong_draft returns that gwanjong_strike needs. Does gwanjong_draft cache context client-side, or does strike fetch it separately? Do gwanjong_campaign, gwanjong_scheduler, and gwanjong_strike reference the same opportunity IDs and data model? If gwanjong_scout returns 'opportunity_id', must a user call gwanjong_draft before gwanjong_strike, or can strike work directly? Pattern:tool-chain requires output from tool A to contain references tool B needs.