MCP Task
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_taskA | Start a complex AI task. Perform advanced reasoning and analysis with state of the art LLMs. Start multiple tasks at once by using an array for model. Returns a task ID immediately (or batch ID for multiple models) to check status and retrieve results. |
| check_task_statusA | Check the status of a running task. Returns current status, progress, and partial results if available. |
| get_task_resultB | Get the final result of a completed task. |
| cancel_taskA | Cancel a pending or running task, or all tasks in a batch. |
| wait_for_taskA | Wait for a task or any task in a batch to complete, fail, or be cancelled. Only waits for tasks that complete AFTER this call is made - ignores tasks that were already completed. |
| list_tasksB | List all tasks with their current status. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| solve | Solve a complicated problem with multiple state-of-the-art LLMs |
| plan | Create a comprehensive plan using multiple state-of-the-art LLMs working in parallel |
| code | Generate or modify code using a state-of-the-art coding LLM |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose with no ambiguity: list_tasks enumerates tasks, run_task initiates tasks, check_task_status monitors progress, get_task_result retrieves final outcomes, wait_for_task blocks for completion, and cancel_task stops tasks. The descriptions clearly differentiate these functions, making misselection unlikely.
All tool names follow a consistent verb_noun pattern with underscores, such as run_task, check_task_status, and cancel_task. This predictable naming convention enhances readability and usability across the tool set.
With 6 tools, the count is well-scoped for a task management server, covering the full lifecycle from creation to completion and cancellation. Each tool earns its place without redundancy or bloat, making the set efficient and focused.
The tool surface provides complete CRUD/lifecycle coverage for task management: run_task for creation, list_tasks for listing, check_task_status and wait_for_task for monitoring, get_task_result for retrieval, and cancel_task for deletion. There are no obvious gaps that would cause agent failures.