otask-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for HTTP server (default: 3847) | 3847 |
| OTASK_EMAIL | No | Email for O!task API login | |
| MCP_AUTH_TOKEN | No | Optional Bearer token to protect the MCP HTTP endpoint (for n8n clients) | |
| OTASK_AUTH_KEY | No | Static Bearer token for O!task API authentication | |
| OTASK_PASSWORD | No | Password for O!task API login |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| otask_get_taskA | Fetch a task from O!task by workspace and task slug. Use before otask_update_task to inspect current field values (board_id, performers, tags, etc.). Args:
Returns JSON with key task fields: id, slug, name, description, end_at, board_id, board_column_id, priority_id, project_id, performers, tags. Docs: https://api.otask.ru/docs#zadaci-GETapi-v1-ws--ws_slug--tasks--task_slug |
| otask_update_taskA | Update an existing O!task task. Sends POST /api/v1/ws/{ws_slug}/tasks/{task_slug}/update. The O!task API requires a full task payload. This tool fetches the current task, merges your changes, then submits the update. Only pass fields you want to change. Common updates:
Args:
Returns updated task summary on success. Docs: https://api.otask.ru/docs#zadaci-POSTapi-v1-ws--ws_slug--tasks--task_slug--update |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one retrieves a task's current state, the other updates it. There is no overlap or ambiguity between them.
Both tools follow the same 'otask_verb_task' pattern with snake_case, using 'get' and 'update' as clear verbs. Perfectly consistent.
With only two tools (get and update), the server feels extremely limited for a task management API. Typical CRUD operations (create, delete, list) are missing, making the tool count too low for the apparent domain.
The tool surface is severely incomplete. Basic operations like creating, deleting, and listing tasks are absent. An agent cannot perform end-to-end task management with only get and update.