Loading ToolBench
MCP server that exposes Yocoolab feedback threads, design selections, and activity events as tools for Claude Code and other MCP-compatible clients.
This server has significant gaps in definition quality. While it exposes 20 tools across diverse domains (threads, design selection, analytics, activity monitoring), most lack adequate parameter descriptions, output schema documentation, and error handling guidance. Tool names follow verb_noun convention well, but parameter specs are incomplete. No tool annotations (readOnlyHint/destructiveHint) are declared. Many tools accept vague string parameters without enum constraints or validation rules in descriptions. Output schemas are not documented in the tool definitions. Error handling is minimal, most tools lack recovery guidance for LLMs. The codebase shows implementation details but tool registration schemas are not fully visible in the provided source, making it difficult to verify schema completeness.
Add a message to a feedback thread for discussion and collaboration
Send a screenshot and page context to the Yocoolab AI for analysis and suggestions
Create a pull request on GitHub with file changes to address a feedback thread
Map a selected UI element to its source code location
Get a summary of the current session's activity including tool usage and events
Retrieve the list of AI conversations for the authenticated user
Retrieve full thread details including messages and context for a specific thread
Output schemas not documented in tool definitions. LLMs cannot know what fields to expect from tool results, forcing them to guess at downstream tool chaining. Example: get_context promises 'full thread details' but doesn't specify returned fields.
String parameters lack enum constraints and validation rules in descriptions. 'status' parameter in list_threads accepts 'open or resolved' but this is buried in description text, not formalized. Parameter descriptions do not specify format, length, or allowed values. Example: 'Filter by thread status (open or resolved)' should be an enum constraint with description 'Thread status: open or resolved'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Get the URL to access the Yocoolab activity dashboard
Get preview deployment URL for a repository and branch
Get detailed context and styles for a selected UI element
Get the list of files modified during the current session
Get the most recent element selection from the Yocoolab Chrome extension
Retrieve recent activity events from the activity monitor
Retrieve the history of element selections from the bridge
List feedback threads from Yocoolab, optionally filtered by status and branch
Mark a feedback thread as addressed and update its status in Yocoolab
Query feature usage analytics from Pendo
List available Pendo guides and their configuration
Get page analytics and user behavior data from Pendo
Track a custom event in Pendo
Destructive/write operations lack error handling and recovery guidance. create_pr and mark_addressed modify state but include no description of failure modes, retryability, or LLM-actionable error messages. No confirmation step or dry-run option for irreversible operations.
No tool annotations declared. Tool definitions do not include readOnlyHint, destructiveHint, or idempotentHint. LLMs cannot distinguish safe (GET-like) tools from dangerous (DELETE-like) ones, risking misuse. Example: get_context and list_threads should be marked readOnly; create_pr should be marked destructive.
Pendo tools (pendo_feature_usage, pendo_page_analytics) accept 'time_range' as free-form string with no enum or format spec. Description says 'Time range for analytics' but does not clarify accepted values: is it '7d', '7 days', 'last-week', 'P7D'? LLM will guess, causing API errors.
Parameter descriptions are generic and lack format/constraint details. 'Repository name' does not clarify if it's 'org/repo' format, a project key, or a simple name. 'Filter for threads pending Claude Code action' is vague, does it accept a boolean or specific string? Descriptions must answer: What format? What values? What constraints?
Array parameters (files in create_pr) lack documentation of expected item structure. 'Array of file changes' does not specify: What fields does each file object require? Is it {path, content}, {filename, body}, something else? LLM cannot construct valid payloads.
No pagination support. get_recent_events, get_ai_conversations, pendo_list_guides accept 'limit' but no offset/cursor. Returning unlimited results risks context window exhaustion. Tool descriptions do not state a result cap (e.g., 'Returns up to 50 events').
Inconsistent naming for similar tools. 'get_latest_selection' vs 'get_selection_history' is clear, but 'ai_analyze_page' uses underscores while other tools in the same domain use different patterns. Tool names should consistently follow verb_noun convention across the suite.
No indication of permission requirements or scope declarations. Which tools require YOCOOLAB_TOKEN vs GITHUB_TOKEN vs PENDO_INTEGRATION_KEY? Tool descriptions do not state 'Requires: GitHub token with repo scope' or 'Requires: Yocoolab API token'. This breaks least-privilege agent configuration.