Loading ToolBench
MCP server for time tracking, project management, and memory with AI-powered search
Calq MCP presents 18 tools with generally present but inconsistent parameter documentation. All tools have descriptions (10-180 chars, mostly in 50-100 range, adequate but not optimized for LLM comprehension). Input schemas are visible for all tools with enum constraints on action/scope parameters, but several critical issues limit the score: (1) Tool naming inconsistency, 'entry_manage', 'timer_manage', 'project_manage', 'task_manage', 'youtrack_manage' violate verb_noun conventions and combine multiple actions under generic names. (2) Parameter descriptions lack actionable constraints, e.g., 'New message (for edit)' offers no length limits, format requirements, or validation guidance. (3) No documented output schemas, LLMs cannot predict what fields will be returned or chain tools reliably. (4) Missing error handling guidance, tools describe no recovery paths or classification of failures. (5) Overloaded 'action' enums force LLMs to reason about which action applies rather than calling a focused tool (e.g., 'delete_time_entry' is clearer than 'entry_manage' with action='delete'). (6) Tools like 'component_publish' and 'component_get' expose complex domain concepts (agents, skills, commands, output-styles, hooks, rules) without explaining when each type is appropriate or what the return structure looks like. Baselines: avg tool description length 194 chars (Calq range 50-130 observed), avg params/tool 4 (Calq tools average 4-6), 100% of A+ tools have documented return types (Calq 0%). Strengths: all 18 tools have non-empty descriptions; enum constraints on most multi-choice parameters; coverage is broad (time tracking, project mgmt, tasks, memory search, components). Weaknesses: generic compound names (ending in '_manage') signal multiple responsibilities; no output schema documentation; parameter constraints under-specified; missing dependency hints (e.g., 'First, call time_query() to find unbilled entries before billing them').
Delete a published component
Get a published component by type and name
List published components
Publish a component (agent, skill, command, output-style, hook, rule)
Manage time entries (edit/delete)
Log time to a project
Delete a memory by ID
Tool names ending in '_manage' with overloaded 'action' enums combine multiple responsibilities and violate verb_noun naming conventions. Examples: 'entry_manage' (edit/delete), 'timer_manage' (start/stop/pause/resume/cancel/status), 'project_manage' (8 actions: create/update/delete for both projects and clients), 'task_manage' (create/list/get/complete), 'youtrack_manage' (set_token/sync_issues/list_issues/get_issue). This forces LLMs to reason about which action applies rather than selecting a focused tool. LLMs default to picking the first enum value on ambiguity, risking silent errors.
No documented output/return schemas for any tool. LLMs cannot predict what fields will be returned, breaking composition patterns. For example, 'entry_manage' with action='edit' likely returns an updated entry object, but which fields? Without knowing the structure, agents cannot chain this to 'time_query' or extract IDs for subsequent calls. This violates the baseline that 100% of A+ tools have documented return types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search memories and time entries semantically
Store a memory or observation
Create an observation from a Claude Code session
Manage projects and clients
Create a session summary (end-of-session synthesis)
Query session summaries
Manage tasks (create, list, get, complete)
Query time summaries
Manage active timers (start, stop, pause, resume, cancel)
Get current user information and entity counts
Manage YouTrack integration and sync issues
Parameter descriptions lack actionable constraints. Example: 'message' in log_time says 'What was accomplished' (9 chars), no length limit, format guidance, or validation rules. 'minutes' says 'Time spent in minutes (defaults to 0)', no minimum/maximum bounds. 'project' in multiple tools just says 'Name of the project' or 'Project name', no clarity on whether it's a project_id, project_name, or slug, and no hint that a lookup may be required if the user provides an ambiguous name. Baseline: avg param annotation 72 chars; Calq param descriptions average 30-40 chars and often omit validation context.
No error handling guidance or recovery paths documented. Tools do not indicate which errors are retryable (e.g., rate limits, transient network errors) vs. user-fixable (e.g., invalid project name) vs. fatal (e.g., permission denied). For example, 'youtrack_manage' with action='sync_issues' may fail silently or with a 401 if the token is invalid, no guidance on how the agent should recover. Pattern 'recovery-guide' requires errors to tell the LLM what to do next.
Destructive/irreversible operations (delete_time_entry, delete_component, delete_memory) have no confirmation or dry-run support. Agents may inadvertently delete data when retrying on transient failures. Pattern 'confirmation-request' suggests supporting a dry-run mode or requiring explicit confirmation for destructive ops.
Tool 'component_publish' accepts enum values ['agent', 'skill', 'command', 'output-style', 'hook', 'rule'] but does not document when each type is used, expected structure of 'content' param, or versioning semantics. 'Version' defaults to '1.0.0' but no guidance on SemVer or backward compatibility. Unclear whether publish overwrites or creates a new version.
Tool 'memory_search' and other lookup tools lack pagination or result limits guidance. 'limit' parameter in memory_search defaults to 5, but tools do not specify caps (e.g., max 100) or explain what happens if more results exist. Baseline: large result sets blow context window and degrade LLM reasoning. Tools should cap returned items and offer cursors or offsets for pagination.