MCP server for interacting with the Freedcamp API, enabling task and project management through the Model Context Protocol
The Freedcamp MCP server provides 8 tools with visible schemas and descriptions, but significant quality gaps limit its production readiness. All tools have names starting with action verbs (get_, create_, update_, delete_) which is correct. However, parameter descriptions lack essential format specifications, enums are missing for constrained inputs, and output schemas are not documented. The server lacks error handling guidance, has no tool annotations (readOnlyHint/destructiveHint), and provides only generic descriptions without actionable context. The instructions in the FastMCP initialization are helpful but do not compensate for missing parameter constraints and output documentation.
Create a new task in a project
Delete a task
Get all projects grouped by their group name
Get all users in the Freedcamp workspace
Get detailed information about a specific task
Get task lists for a specific project, with optional filtering by status
Get tasks for a project with comprehensive filtering options
Missing enum constraints for status_filter, priority_filter, status, priority fields. LLMs cannot infer valid values and will hallucinate options.
No documented output schemas for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., task_id from create_task response).
No pagination parameters (limit, offset, page_number) or documentation for tools returning lists (get_all_projects, get_all_users, get_task_lists, get_tasks). Large result sets will blow context window.
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 | 22 | - | v1 |
Update an existing task
Date format descriptions missing. Parameters due_date_from, due_date_to, due_date specify YYYY-MM-DD format in descriptions, but no validation example or bounds given. LLMs may submit invalid dates.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The Risk field in metadata indicates WRITE and DESTRUCTIVE tools, but these are not expressed in MCP tool definitions, leaving agents without guidance on side effects.
Parameter descriptions lack actionable constraint info. E.g., 'priority_filter' has no description of valid values; 'limit' has no bounds. Baseline requires 'must be 1-100' or enum list.
No error handling guidance. When create_task or update_task fails (e.g., invalid project_id, user not found), no recovery hints provided to the LLM.
get_all_users and get_all_projects descriptions do not mention limits or result caps. Baseline requires 'returns up to N results' or similar to guide agent expectations.
No confirmation or dry-run support for delete_task. Destructive operations should offer a confirmation step to prevent accidental deletions by agents.