Loading ToolBench
An unofficial MCP server providing a standardized bridge between AI models and the Lunatask API
LunaTask MCP has 13 tools with moderate-to-poor definition quality. Naming is mostly clear and action-oriented (get_, create_, update_, delete_ verbs), but descriptions lack sufficient detail for LLM decision-making. Most tool descriptions are brief (under 100 chars) and do not explain WHEN to use the tool or key prerequisites. Parameters are defined with types but lack comprehensive descriptions, many parameters like 'task_data', 'note_data', 'person_data' are described only as 'object' with minimal context about expected fields. Output schemas are undocumented (no explicit return type specifications visible). Error handling is mentioned in docstrings but lacks actionable recovery guidance. Security is a concern: write/destructive operations lack confirmation patterns or dry-run capability.
Complete a task by marking it as done in the LunaTask API
Create a new journal entry in the LunaTask API
Create a new note in the LunaTask API
Create a new person in the LunaTask API
Create a person timeline note through the LunaTask API
Create a new task in the LunaTask API
Delete an existing note in the LunaTask API
Delete an existing person in the LunaTask API
Generic object parameters lack field documentation. 'task_data', 'note_data', 'person_data' parameters are typed as 'object' with only brief descriptions like 'TaskCreate object containing task data to create'. LLMs cannot infer which fields are required, optional, or what values are valid without explicit schema of nested fields.
Destructive operations (delete_task, delete_note, delete_person) have no confirmation, dry-run, or undo capability. These tools can permanently remove data without any safeguard, and the descriptions do not warn of irreversible consequences.
Output schemas are not documented. Tool descriptions do not specify what fields are returned or their types. Agents cannot plan follow-up calls (e.g., using a returned task_id to update that task) without inferring structure from API responses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Delete a task from the LunaTask API
Retrieve a single task from the LunaTask API by ID
Retrieve all tasks from the LunaTask API
Ping health-check tool that returns a static 'pong' response. This tool serves as a basic health-check endpoint to verify that the MCP server is functioning correctly.
Track an activity for a specific habit on a given date
Update an existing note in the LunaTask API
Update an existing task in the LunaTask API
Most tool descriptions are under 100 characters and lack context about when to use each tool, prerequisites, or how it differs from related tools. Example: 'Update an existing task in the LunaTask API.' does not explain what fields can be updated or common use cases.
Error handling docstrings list exception types but provide no actionable recovery guidance. Example: 'Raises: LunaTaskNotFoundError, LunaTaskValidationError' tells the agent an error happened but not what to do next or how to fix the input.
Parameter 'limit' in get_tasks is documented as 'Optional pagination limit (max 50)' but no minimum is specified. Agents could pass 0, negative, or very large values. Description should state: 'Integer from 1 - 50. Defaults to 20 if omitted.'
Status filter in get_tasks is documented as accepting strings like 'open', but no enum constraint or list of valid values is provided. Agents may pass invalid status values like 'pending' or 'backlog' without validation.