Skip to main content
Glama
just-every

MCP Task

by just-every
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

@just-every/mcp-task

npm version License: MIT

Async MCP server for running long-running AI tasks with real-time progress monitoring using @just-every/task.

Quick Start

1. Create or use an environment file

Option A: Create a new .llm.env file in your home directory:

# Download example env file
curl -o ~/.llm.env https://raw.githubusercontent.com/just-every/mcp-task/main/.env.example

# Edit with your API keys
nano ~/.llm.env

Option B: Use an existing .env file (must use absolute path):

# Example: /Users/yourname/projects/myproject/.env
# Example: /home/yourname/workspace/.env

2. Install

Claude Code

# Using ~/.llm.env
claude mcp add task -s user -e ENV_FILE=$HOME/.llm.env -- npx -y @just-every/mcp-task

# Using existing .env file (absolute path required)
claude mcp add task -s user -e ENV_FILE=/absolute/path/to/your/.env -- npx -y @just-every/mcp-task

# For debugging, check if ENV_FILE is being passed correctly:
claude mcp list

Other MCP Clients

Add to your MCP configuration:

{
  "mcpServers": {
    "task": {
      "command": "npx",
      "args": ["-y", "@just-every/mcp-task"],
      "env": {
        "ENV_FILE": "/path/to/.llm.env"
      }
    }
  }
}

Related MCP server: RunComfy MCP

Available Tools

run_task

Start a long-running AI task asynchronously. Returns a task ID immediately (or batch ID for multiple models).

Parameters:

  • task (required): The task prompt - what to perform

  • model (optional): Model class or specific model name, or array of models for batch execution

  • context (optional): Background context for the task

  • output (optional): The desired output/success state

  • files (optional): Array of file paths to include in the task context

  • read_only (optional): When true, task runs in read-only mode (default: false)

Returns:

  • Single task: { task_id, status, message }

  • Batch execution: { batch_id, task_ids[], status, message }

check_task_status

Check the status of a running task with real-time progress updates.

Parameters:

  • task_id (required): The task ID returned from run_task

Returns: Current status, progress summary, recent events, and tool calls

get_task_result

Get the final result of a completed task.

Parameters:

  • task_id (required): The task ID returned from run_task

Returns: The complete output from the task

cancel_task

Cancel a pending or running task, or all tasks in a batch.

Parameters:

  • task_id (optional): The task ID to cancel

  • batch_id (optional): Cancel all tasks with this batch ID

Returns: Cancellation status and count of cancelled tasks

wait_for_task

Wait for a task or any task in a batch to complete, fail, or be cancelled.

Parameters:

  • task_id (optional): Wait for this specific task to complete

  • batch_id (optional): Wait for any task in this batch to complete

  • timeout_seconds (optional): Maximum seconds to wait (default: 300, max: 600)

  • return_all (optional): For batch_id, return all completed tasks instead of just the first (default: false)

Returns: Task completion details with wait time, or timeout status

list_tasks

List all tasks with their current status.

Parameters:

  • status_filter (optional): Filter by status (pending, running, completed, failed, cancelled)

  • batch_id (optional): Filter tasks by batch ID

  • recent_only (optional): Only show tasks from the last 2 hours (default: false)

Returns: Task statistics and summaries with applied filters

MCP Prompts

The server provides MCP prompts that can be used to execute complex problem-solving strategies:

/solve Prompt

Solves complicated problems by running multiple state-of-the-art LLMs in parallel and implementing their solutions.

Arguments:

  • problem (required): The problem to solve

  • context (optional): Additional context about the problem

  • files (optional): Comma-separated list of file paths relevant to the problem

Strategy:

  1. Starts tasks with multiple models (grok-4, gemini-2.5-pro, o3, reasoning class)

  2. All tasks run in parallel to diagnose and propose solutions

  3. Tasks can create test files but cannot edit existing files

  4. First successful solution is implemented

  5. If a solution fails, retry with feedback to the same model

  6. Continues until problem is resolved

Example Workflow

// 1. Start a task
const startResponse = await callTool('run_task', {
  "model": "standard",
  "task": "Search for the latest AI news and summarize",
  "output": "A bullet-point summary of 5 recent AI developments"
});
// Returns: { "task_id": "abc-123", "status": "pending", ... }

// 2. Check progress
const statusResponse = await callTool('check_task_status', {
  "task_id": "abc-123"
});
// Returns: { "status": "running", "progress": "Searching for AI news...", ... }

// 3. Get result when complete
const resultResponse = await callTool('get_task_result', {
  "task_id": "abc-123"
});
// Returns: The complete summary

Supported Models

Model Classes

  • reasoning: Complex reasoning and analysis

  • vision: Image and visual processing

  • standard: General purpose tasks

  • mini: Lightweight, fast responses

  • reasoning_mini: Lightweight reasoning

  • code: Code generation and analysis

  • writing: Creative and professional writing

  • summary: Text summarization

  • vision_mini: Lightweight vision processing

  • long: Long-form content generation

Popular Models

  • claude-opus-4: Anthropic's most powerful model

  • grok-4: xAI's latest Grok model

  • gemini-2.5-pro: Google's Gemini Pro

  • o3, o3-pro: OpenAI's o3 models

  • And any other model name supported by @just-every/ensemble

Integrated Tools

Task agents have access to a lightweight version of the tools available to Claude, optimized for autonomous task execution:

  • Web Search: Search the web for information using @just-every/search

  • File Operations: Read and write files, with optional read-only mode

  • Command Execution: Run shell commands (disabled in read-only mode)

  • Code Analysis: Search and analyze codebases

Read-Only Mode

When read_only: true is specified:

  • Tasks can read files, search the web, and analyze data

  • Tasks cannot modify files or execute commands that change system state

  • Ideal for diagnostic tasks, code review, and solution planning

API Keys

The task runner requires API keys for the AI models you want to use. Add them to your .llm.env file:

# Core AI Models
ANTHROPIC_API_KEY=your-anthropic-key
OPENAI_API_KEY=your-openai-key  
XAI_API_KEY=your-xai-key           # For Grok models
GOOGLE_API_KEY=your-google-key     # For Gemini models

# Search Providers (optional, for web_search tool)
BRAVE_API_KEY=your-brave-key
PERPLEXITY_API_KEY=your-perplexity-key
OPENROUTER_API_KEY=your-openrouter-key

Getting API Keys

Task Lifecycle

  1. Pending: Task created and queued

  2. Running: Task is being executed with live progress via taskStatus()

  3. Completed: Task finished successfully

  4. Failed: Task encountered an error

  5. Cancelled: Task was cancelled by user

Tasks are automatically cleaned up after 24 hours.

CLI Usage

The task runner can also be used directly from the command line:

# Run as MCP server (for debugging)
ENV_FILE=~/.llm.env npx @just-every/mcp-task

# Or if installed globally
npm install -g @just-every/mcp-task
ENV_FILE=~/.llm.env mcp-task serve

Configuration

Task Timeout Settings

The server includes robust safety mechanisms to prevent tasks from getting stuck. All timeouts are configurable via environment variables:

# Default production settings (optimized for long-running tasks)
TASK_TIMEOUT=18000000             # 5 hours max runtime (default)
TASK_STUCK_THRESHOLD=300000       # 5 minutes inactivity = stuck (default)
TASK_HEALTH_CHECK_INTERVAL=60000  # Check every 1 minute (default)

# For shorter tasks, you might prefer:
TASK_TIMEOUT=300000               # 5 minutes max runtime
TASK_STUCK_THRESHOLD=60000        # 1 minute inactivity
TASK_HEALTH_CHECK_INTERVAL=15000  # Check every 15 seconds

# Add to your .llm.env or pass as environment variables

Safety Features:

  • Automatic timeout: Tasks exceeding TASK_TIMEOUT are automatically failed

  • Inactivity detection: Tasks with no activity for TASK_STUCK_THRESHOLD are marked as stuck

  • Health monitoring: Regular checks every TASK_HEALTH_CHECK_INTERVAL ensure tasks are progressing

  • Error recovery: Uncaught exceptions and promise rejections are handled gracefully

Development

Setup

# Clone the repository
git clone https://github.com/just-every/mcp-task.git
cd mcp-task

# Install dependencies
npm install

# Build for production
npm run build

Development Mode

# Run in development mode with your env file
ENV_FILE=~/.llm.env npm run serve:dev

Testing

# Run tests
npm test

# Type checking
npm run typecheck

# Linting
npm run lint

Architecture

mcp-task/
├── src/
│   ├── serve.ts            # MCP server implementation
│   ├── index.ts            # CLI entry point
│   └── utils/
│       ├── task-manager.ts # Async task lifecycle management
│       └── logger.ts       # Logging utilities
├── bin/
│   └── mcp-task.js         # Executable entry
└── package.json

Contributing

Contributions are welcome! Please:

  1. Fork the repository

  2. Create a feature branch

  3. Add tests for new functionality

  4. Submit a pull request

Troubleshooting

MCP Server Shows "Failed" in Claude

If you see "task ✘ failed" in Claude, check these common issues:

  1. Missing API Keys: The most common issue is missing API keys. Check that your ENV_FILE is properly configured:

    # Test if ENV_FILE is working
ENV_FILE=/path/to/your/.llm.env npx @just-every/mcp-task

  2. Incorrect Installation Command: Make sure you're using -e for environment variables:

    # Correct - environment variable passed with -e flag before --
claude mcp add task -s user -e ENV_FILE=$HOME/.llm.env -- npx -y @just-every/mcp-task

# Incorrect - trying to pass as argument
claude mcp add task -s user -- npx -y @just-every/mcp-task --env ENV_FILE=$HOME/.llm.env

  3. Path Issues: ENV_FILE must use absolute paths:

    # Good
ENV_FILE=/Users/yourname/.llm.env
ENV_FILE=$HOME/.llm.env

# Bad
ENV_FILE=.env
ENV_FILE=~/.llm.env  # ~ not expanded in some contexts

  4. Verify Installation: Check your MCP configuration:

    claude mcp list

  5. Debug Mode: For detailed error messages, run manually:

    ENV_FILE=/path/to/.llm.env npx @just-every/mcp-task

Task Not Progressing

  • Check task status with check_task_status to see live progress

  • Look for error messages prefixed with "ERROR:" in the output

  • Verify API keys are properly configured

Model Not Found

  • Ensure model name is correctly spelled

  • Check that required API keys are set for the model provider

  • Popular models: claude-opus-4, grok-4, gemini-2.5-pro, o3

Task Cleanup

  • Completed tasks are automatically cleaned up after 24 hours

  • Use list_tasks to see all active and recent tasks

  • Cancel stuck tasks with cancel_task

License

MIT

Author

Created by Just Every - Building powerful AI tools for developers.

Available Tools

6 tools
cancel_taskA
DestructiveIdempotent

Cancel a pending or running task, or all tasks in a batch.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idNoThe task ID to cancel (required if batch_id not provided)
batch_idNoCancel all tasks with this batch ID (required if task_id not provided)

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable context beyond annotations by specifying what types of tasks can be cancelled (pending or running) and the batch-level operation option. While annotations already indicate destructiveHint=true and idempotentHint=true, the description clarifies the operational scope without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise with a single sentence that contains no wasted words. It's front-loaded with the core action and immediately specifies the two operational modes, making every word earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's destructive nature (destructiveHint=true) and lack of output schema, the description provides good context about what the tool does. However, it doesn't mention potential side effects, error conditions, or what happens after cancellation, which would be helpful for a destructive operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already fully documents both parameters (task_id and batch_id) with their descriptions and mutual exclusivity rules. The description doesn't add significant parameter semantics beyond what's in the schema, maintaining the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Cancel') and target resources ('a pending or running task, or all tasks in a batch'), distinguishing it from sibling tools like check_task_status, get_task_result, list_tasks, run_task, and wait_for_task. It precisely defines the scope of what can be cancelled.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool (to cancel pending/running tasks or entire batches), but doesn't explicitly mention when NOT to use it or name specific alternatives. It implies usage for task management but lacks explicit exclusions or comparison with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_task_statusA
Read-only

Check the status of a running task. Returns current status, progress, and partial results if available.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task ID returned from run_task

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, non-destructive, non-idempotent, and closed-world behavior. The description adds valuable context by specifying what is returned (current status, progress, partial results if available), which is not covered by annotations. It does not contradict annotations, as checking status aligns with read-only operations, and it provides useful behavioral details beyond the structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and efficiently structured in two sentences: the first states the action and resource, and the second specifies the return values. Every sentence adds essential information without redundancy, making it highly concise and well-organized for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one parameter, no output schema) and rich annotations, the description is mostly complete. It covers purpose, return values, and usage hints, but lacks explicit guidance on when to choose this tool over siblings like 'get_task_result', which could improve completeness for an agent in a multi-tool environment.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting the single required parameter 'task_id' as from 'run_task'. The description adds minimal semantic value by referencing 'task_id' indirectly but does not provide additional details like format examples or constraints beyond what the schema already covers. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Check the status') and resource ('a running task'), distinguishing it from siblings like 'cancel_task', 'get_task_result', 'list_tasks', 'run_task', and 'wait_for_task'. It specifies the scope of what is returned (status, progress, partial results), making the purpose unambiguous and differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by mentioning 'a running task' and referencing 'task_id' from 'run_task', suggesting it should be used after initiating a task. However, it does not explicitly state when to use this tool versus alternatives like 'get_task_result' or 'wait_for_task', nor does it provide exclusions or detailed prerequisites, leaving some ambiguity in tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_task_resultB
Read-only

Get the final result of a completed task.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task ID returned from run_task

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=false, covering safety and idempotency. The description adds minimal behavioral context by specifying 'completed task,' which hints at a prerequisite state, but doesn't elaborate on error handling, rate limits, or return format. With annotations doing heavy lifting, this earns a baseline score for adding some value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with zero waste, front-loading the essential action and target. It's appropriately sized for a simple tool, making it easy for an agent to parse quickly without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one parameter, no output schema) and rich annotations, the description is minimally adequate. It states the purpose but lacks details on return values, error cases, or sibling differentiation. For a read-only tool with good annotations, this is passable but leaves gaps in usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the 'task_id' parameter fully documented as 'The task ID returned from run_task.' The description adds no additional parameter details beyond what the schema provides, so it meets the baseline for high schema coverage without compensating with extra semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and target ('final result of a completed task'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'check_task_status' or 'wait_for_task', which might also retrieve task-related information, so it misses the highest score for sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for completed tasks but provides no explicit guidance on when to use this tool versus alternatives like 'check_task_status' for pending tasks or 'wait_for_task' for blocking. There's no mention of prerequisites, exclusions, or named alternatives, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tasksB
Read-only

List all tasks with their current status.

ParametersJSON Schema
NameRequiredDescriptionDefault
status_filterNoOptional: Filter tasks by status
batch_idNoOptional: Filter tasks by batch ID to only show tasks from a specific batch
recent_onlyNoOptional: Only show tasks from the last 2 hours (default: false)

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide key behavioral hints (readOnlyHint: true, destructiveHint: false), indicating it's a safe read operation. The description adds minimal context by implying it returns current statuses, but doesn't disclose details like pagination, rate limits, or what 'all' entails (e.g., system-wide or user-specific). No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (list operation with filtering), rich annotations (covering safety), and full schema coverage, the description is adequate but incomplete. It lacks output details (no schema provided), doesn't explain behavioral constraints like limits, and misses sibling differentiation, leaving gaps for an agent to infer usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema fully documents all three parameters (status_filter, batch_id, recent_only), including enums and defaults. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high coverage without compensating value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('tasks') with scope ('all'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'check_task_status' or 'get_task_result', which might also involve task retrieval but with different scopes or purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'check_task_status' for individual tasks or 'get_task_result' for completed tasks. It lacks context on prerequisites, such as whether authentication is needed or if it's suitable for real-time monitoring versus historical queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoOptional: Single model OR array of models for batch execution. Defaults to 'standard' if not specified.
taskYesThe task prompt - what to perform (required)
contextNoOptional: Background context for the task
outputNoOptional: The desired output/success state
filesNoOptional: Array of file paths to include in the task context
read_onlyNoOptional: When true, excludes tools that can modify files, execute commands, or make changes. Only allows read/search/analysis tools.

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, covering safety and idempotency. The description adds value by explaining the return behavior ('Returns a task ID immediately (or batch ID for multiple models)') and the asynchronous nature, which isn't captured in annotations. However, it doesn't disclose rate limits, authentication needs, or detailed error handling, leaving some behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with three sentences that are front-loaded: the first states the purpose, the second explains batch capability, and the third covers returns. There's no wasted text, but it could be slightly more structured by explicitly separating usage notes from behavioral details, though it remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a 6-parameter tool with no output schema, the description is reasonably complete. It covers the core action, batch capability, and return values, aligning with the annotations. However, it lacks details on error cases, task lifecycle, or integration with sibling tools, which would enhance completeness for this asynchronous operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal semantics beyond the schema, only implying batch execution with 'Start multiple tasks at once by using an array for model'. It doesn't explain parameter interactions or provide additional context like default behaviors beyond what's in the schema, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Start a complex AI task') and resource ('AI task'), specifying it involves 'advanced reasoning and analysis with state of the art LLMs'. It distinguishes from siblings like 'check_task_status' or 'get_task_result' by focusing on initiation rather than monitoring or retrieval. However, it doesn't explicitly contrast with 'list_tasks' or 'wait_for_task', missing full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by mentioning 'Start multiple tasks at once by using an array for model', which suggests when to use batch mode, but lacks explicit guidance on when to choose this tool over alternatives like 'wait_for_task' or prerequisites. It hints at alternatives for checking status ('to check status and retrieve results') but doesn't name specific sibling tools or provide clear when-not-to-use criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wait_for_taskA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idNoWait for this specific task to complete (required if batch_id not provided)
batch_idNoWait for any task in this batch to complete (required if task_id not provided)
timeout_secondsNoMaximum seconds to wait before timing out (default: 300, max: 600)
return_allNoFor batch_id: return all completed tasks instead of just the first one (default: false)

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context about ignoring already completed tasks and the waiting behavior, which is not captured in annotations. However, it doesn't detail error handling or response format, leaving some behavioral aspects unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and followed by a critical behavioral note. Every sentence adds essential information without redundancy, making it highly efficient and well-structured for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (waiting behavior with timeout and batch options), annotations cover safety and idempotency well, and schema covers parameters fully. The description adds key behavioral context (ignoring completed tasks). However, without an output schema, it doesn't explain return values (e.g., what 'complete, fail, or be cancelled' means in output), leaving a minor gap in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are fully documented in the input schema. The description doesn't add extra meaning beyond what the schema provides (e.g., it mentions 'task_id' and 'batch_id' but without additional semantics). Baseline score of 3 is appropriate as the schema carries the full burden of parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Wait for a task or any task in a batch to complete, fail, or be cancelled') and specifies the resource (task/batch). It distinguishes from siblings like 'check_task_status' by emphasizing waiting behavior and ignoring already completed tasks, making the purpose specific and well-differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('Only waits for tasks that complete AFTER this call is made - ignores tasks that were already completed'), which differentiates it from siblings like 'check_task_status' that might check current status. It also implies usage with 'task_id' or 'batch_id' as alternatives, providing clear context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updates
    • First observedcancel_task
    • First observedcheck_task_status
    • First observedget_task_result
    • First observedlist_tasks
    • First observedrun_task
    • First observedwait_for_task
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/just-every/mcp-task'

If you have feedback or need assistance with the MCP directory API, please join our Discord server