Loading ToolBench
The server provides 4 tools with consistent naming (verb_noun pattern: freedcamp_add_task, freedcamp_update_task, freedcamp_delete_task, freedcamp_list_tasks) and detailed parameter schemas. However, there are significant gaps: tool descriptions lack actionable context for LLM selection, parameter descriptions rely on example values (violating pattern:constrained-input), output schemas are not documented, and error handling guidance is absent. The Zod schema definitions in mcpServer.ts are properly typed but descriptions embed examples like '1735689600' which LLMs tend to reuse literally. Task tools support bulk operations via array parameters, which is good composition (reduces N sequential calls), but the schema quality is undermined by missing constraints (enums, format strings) and undocumented return structures.
Create one or more new tasks in Freedcamp with support for title, description, priority, due date, and assignee. Supports bulk operations for creating multiple tasks at once.
Permanently delete one or more tasks from Freedcamp. WARNING: This action cannot be undone. Supports bulk operations for deleting multiple tasks at once.
Retrieve all tasks in the configured Freedcamp project. Returns task details including ID, title, description, status, priority, due date, and assignee information.
Update one or more existing tasks in Freedcamp including title, description, priority, due date, assignee, and status. Supports bulk operations for updating multiple tasks at once.
Tool descriptions lack LLM-optimized context. Descriptions are below 100 chars and do not explain WHEN to use the tool, what preconditions apply, or how results should be interpreted. 'Create one or more new tasks in Freedcamp...' tells what but not why or when. Average description length 124 chars (baseline 194 chars for A+ tools).
Parameter descriptions embed example values (e.g., 'e.g., 1735689600 for 2025-01-01', 'e.g., PROJ'). LLMs latch onto examples and reuse them literally in real calls, causing failures. Replace with formal constraints: format='unix-timestamp', pattern='^[0-9]{10}$', or enum definitions.
Output schemas not documented. Tool descriptions do not specify what fields are returned, data types, or whether results are paginated. The source code shows results are fetched via API but the response structure is opaque to LLMs. freedcamp_list_tasks returns 'all tasks' but no description of pagination, total count, or per-task field names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 63 | 2025-03-26+ | v1 |
Error handling provides no recovery guidance. Source code (http-server.ts) shows generic 500 errors ('Internal server error') with no actionable next steps for LLMs. Destructive tool (freedcamp_delete_task) has no confirmation or dry-run pattern; a single agent mistake triggers permanent data loss.
freedcamp_list_tasks has no pagination parameters (limit, offset, cursor). Returning 'all tasks' in a single response risks context window exhaustion if project contains hundreds of tasks. No mention of result capping or pagination strategy.
Priority parameter uses integer enum (0 - 3) without a lookup table in source. Description states '0=Low, 1=Normal, 2=High, 3=Urgent' but no formal enum constraint in schema. Status parameter in update_task similarly uses undocumented integers (0=Open, 1=Completed, 2=Closed). LLMs cannot discover valid values without hardcoding these mappings.
Missing tool annotations. Tools register with names and schemas but do not declare readOnlyHint, destructiveHint, or idempotentHint. freedcamp_delete_task is destructive but not marked as such; LLMs have no formal signal that this operation is irreversible.
Bulk operation design is good (tasks array reduces N sequential calls) but individual success/failure reporting is undocumented. If one task fails in a batch, does the entire operation roll back or do partial updates occur? No guidance for LLM retry logic.