Task API Server
The Task API Server is a task management system offering standardized operations across dual runtime modes (STDIO and HTTP+SSE), supporting integration with CLI, AI agents, and web applications.
List Tasks: Retrieve and filter tasks by status (not_started, started, done) or priority (low, medium, high)
Create Tasks: Add new tasks with required fields (task description, category) and optional fields (status, priority)
Update Tasks: Modify existing tasks by updating any field using the task ID
Delete Tasks: Remove tasks using their unique task ID
Multiple Interfaces: Works via STDIO mode for CLI/AI integration and HTTP+SSE for browser-based access
Robust Validation: Ensures data integrity with input validation and error handling
Enables configuration through environment variables to set API credentials, base URLs, and server ports for connecting to external task management services.
Supports browser-based clients through CDN-delivered MCP SDK, enabling web applications to connect to the task management server.
Supports running as a Node.js application in either STDIO mode for CLI/AI agent integration or HTTP+SSE mode for web-based access.
Provides a standardized interface for task management, allowing users to list, create, update, and delete tasks with customizable properties such as status, category, and priority levels.
Implemented in TypeScript, providing type safety and modern JavaScript features for reliable task management operations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Task API Serverlist my open tasks for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Task API Server - MCP TypeScript Implementation
A Model Context Protocol (MCP) implementation for Task Management API written in TypeScript. This project serves as both a reference implementation and a functional task management server.
Overview
This MCP server connects to an external Task API service and provides a standardized interface for task management. It supports two runtime modes:
STDIO Mode: Standard input/output communication for CLI-based applications and AI agents
HTTP+SSE Mode: Web-accessible server with Server-Sent Events for browser and HTTP-based clients
The server offers a complete set of task management operations, extensive validation, and robust error handling.
Related MCP server: Tiny TODO MCP
Features
Task Management Operations:
List existing tasks with filtering capabilities
Create new tasks with customizable properties
Update task details (description, status, category, priority)
Delete tasks when completed or no longer needed
Dual Interface Modes:
STDIO protocol support for command-line and AI agent integration
HTTP+SSE protocol with web interface for browser-based access
MCP Protocol Implementation:
Complete implementation of the Model Context Protocol
Resources for task data structures
Tools for task operations
Error handling and informative messages
Quality Assurance:
Comprehensive test client for validation
Automatic server shutdown after tests complete
Detailed validation of API responses
Getting Started
Prerequisites
Node.js 16.x or higher
npm or pnpm package manager
Installation
Clone the repository:
git clone https://github.com/yourusername/mcp-template-ts.git cd mcp-template-tsInstall dependencies:
npm installor using pnpm:
pnpm installCreate an
.envfile with your Task API credentials:TASK_MANAGER_API_BASE_URL=https://your-task-api-url.com/api TASK_MANAGER_API_KEY=your_api_key_here TASK_MANAGER_HTTP_PORT=3000Build the project:
npm run build
Running the Server
STDIO Mode (for CLI/AI integration)
npm startor
node dist/index.jsHTTP Mode (for web access)
npm run start:httpor
node dist/http-server.jsBy default, the HTTP server runs on port 3000. You can change this by setting the TASK_MANAGER_HTTP_PORT environment variable.
Testing
Run the comprehensive test suite to verify functionality:
npm testThis will:
Build the project
Start a server instance
Connect a test client to the server
Run through all task operations
Verify correct responses
Automatically shut down the server
Using the MCP Client
STDIO Client
To connect to the STDIO server from your application:
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
import * as path from 'path';
// Create transport
const transport = new StdioClientTransport({
command: 'node',
args: [path.resolve('path/to/dist/index.js')]
});
// Initialize client
const client = new Client(
{
name: "your-client-name",
version: "1.0.0"
},
{
capabilities: {
prompts: {},
resources: {},
tools: {}
}
}
);
// Connect to server
await client.connect(transport);
// Example: List all tasks
const listTasksResult = await client.callTool({
name: "listTasks",
arguments: {}
});
// Example: Create a new task
const createTaskResult = await client.callTool({
name: "createTask",
arguments: {
task: "Complete project documentation",
category: "Documentation",
priority: "high"
}
});
// Clean up when done
await client.close();HTTP Client
To connect to the HTTP server from a browser:
<!DOCTYPE html>
<html>
<head>
<title>Task Manager</title>
<script type="module">
import { Client } from 'https://cdn.jsdelivr.net/npm/@modelcontextprotocol/sdk/dist/esm/client/index.js';
import { SSEClientTransport } from 'https://cdn.jsdelivr.net/npm/@modelcontextprotocol/sdk/dist/esm/client/sse.js';
document.addEventListener('DOMContentLoaded', async () => {
// Create transport
const transport = new SSEClientTransport('http://localhost:3000/mcp');
// Initialize client
const client = new Client(
{
name: "browser-client",
version: "1.0.0"
},
{
capabilities: {
prompts: {},
resources: {},
tools: {}
}
}
);
// Connect to server
await client.connect(transport);
// Now you can use client.callTool() for tasks
});
</script>
</head>
<body>
<h1>Task Manager</h1>
<!-- Your interface elements here -->
</body>
</html>Available Tools
listTasks
Lists all available tasks.
const result = await client.callTool({
name: "listTasks",
arguments: {
// Optional filters
status: "pending", // Filter by status
category: "Work", // Filter by category
priority: "high" // Filter by priority
}
});createTask
Creates a new task.
const result = await client.callTool({
name: "createTask",
arguments: {
task: "Complete the project report", // Required: task description
category: "Work", // Optional: task category
priority: "high" // Optional: low, medium, high
}
});updateTask
Updates an existing task.
const result = await client.callTool({
name: "updateTask",
arguments: {
taskId: 123, // Required: ID of task to update
task: "Updated task description", // Optional: new description
status: "done", // Optional: pending, started, done
category: "Personal", // Optional: new category
priority: "medium" // Optional: low, medium, high
}
});deleteTask
Deletes a task.
const result = await client.callTool({
name: "deleteTask",
arguments: {
taskId: 123 // Required: ID of task to delete
}
});Environment Variables
Variable | Description | Default |
TASK_MANAGER_API_BASE_URL | URL for the external Task API | None (Required) |
TASK_MANAGER_API_KEY | API key for authentication | None (Required) |
TASK_MANAGER_HTTP_PORT | Port for the HTTP server | 3000 |
PORT | Alternative port name (takes precedence) | None |
Project Structure
mcp-template-ts/
├── dist/ # Compiled JavaScript files
├── src/ # TypeScript source files
│ ├── index.ts # STDIO server entry point
│ ├── http-server.ts # HTTP+SSE server entry point
│ ├── test-client.ts # Test client implementation
├── .env # Environment variables
├── package.json # Project dependencies
├── tsconfig.json # TypeScript configuration
└── README.md # Project documentationDevelopment
Start the TypeScript compiler in watch mode:
npm run watchRun tests to verify changes:
npm test
License
This project is licensed under the MIT License - see the LICENSE file for details.
Acknowledgments
This project uses the @modelcontextprotocol/sdk for MCP protocol implementation
Built for integration with AI tooling and web applications
Available Tools
4 toolscreateTaskD
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The task description or title | |
| category | Yes | Task category (e.g., 'Development', 'Documentation') | |
| priority | No | Task priority level (defaults to 'medium' if not specified) | |
| status | No | Initial task status (defaults to 'not_started' if not specified) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deleteTaskD
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to delete |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listTasksD
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter tasks by status (optional) | |
| priority | No | Filter tasks by priority level (optional) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
updateTaskD
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to update | |
| task | No | New task description/title (if you want to change it) | |
| category | No | New task category (if you want to change it) | |
| priority | No | New task priority (if you want to change it) | |
| status | No | New task status (if you want to change it) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
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.
4 tool updates
- First observed
createTask - First observed
deleteTask - First observed
listTasks - First observed
updateTask
TDQS
Each tool has a clearly distinct purpose targeting a specific CRUD operation on tasks: create, delete, list, and update. There is no overlap or ambiguity between these actions.
All tool names follow a consistent verb_noun pattern (createTask, deleteTask, listTasks, updateTask) with no deviations in style or convention.
With 4 tools, this server is well-scoped for a basic task management API, covering essential CRUD operations without unnecessary bloat or missing core functionality.
The tool set provides complete CRUD coverage for the task domain (create, read via list, update, delete), with no obvious gaps or dead ends for managing tasks.
Maintenance
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
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for todo.vu task management and time tracking.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA FastAPI-based implementation of the Model Context Protocol that enables standardized interaction between AI models and development environments, making it easier for developers to integrate and manage AI tasks.10MIT
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that provides persistent task management capabilities for AI assistants, allowing them to create, update, and track tasks beyond their usual context limitations.5-
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server that supports STDIO, SSE and Streamable HTTP protocols for AI model interactions.281MIT
- AlicenseNot gradedqualityFmaintenanceA robust server implementing the Model Context Protocol with SSE and STDIO transport, enabling real-time communication and extensible tooling for AI models.2254MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/milkosten/task-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server