一个用 TypeScript 编写的任务管理 API 的模型上下文协议 (MCP) 实现。该项目既可用作参考实现，也可用作功能性任务管理服务器。
此 MCP 服务器连接到外部 Task API 服务，并提供标准化的任务管理接口。它支持两种运行模式：
STDIO 模式：基于 CLI 的应用程序和 AI 代理的标准输入/输出通信
HTTP+SSE 模式：可通过 Web 访问的服务器，为浏览器和基于 HTTP 的客户端提供服务器发送事件
该服务器提供了一整套任务管理操作、广泛的验证和强大的错误处理。
Related MCP server: Tiny TODO MCP
任务管理操作：
列出具有过滤功能的现有任务
创建具有可自定义属性的新任务
更新任务详细信息（描述、状态、类别、优先级）
完成或不再需要时删除任务
双接口模式：
STDIO 协议支持命令行和 AI 代理集成
HTTP+SSE 协议，带有 Web 界面，可基于浏览器访问
MCP 协议实现：
完整实现模型上下文协议
任务数据结构资源
任务操作工具
错误处理和信息消息
质量保证：
用于验证的综合测试客户端
测试完成后服务器自动关闭
API 响应的详细验证
Node.js 16.x 或更高版本
npm 或 pnpm 包管理器
克隆存储库：
git clone https://github.com/yourusername/mcp-template-ts.git
cd mcp-template-ts安装依赖项：
npm install或者使用 pnpm：
pnpm install使用您的任务 API 凭证创建一个.env文件：
TASK_MANAGER_API_BASE_URL=https://your-task-api-url.com/api
TASK_MANAGER_API_KEY=your_api_key_here
TASK_MANAGER_HTTP_PORT=3000构建项目：
npm run buildnpm start或者
node dist/index.jsnpm run start:http或者
node dist/http-server.js默认情况下，HTTP 服务器在端口 3000 上运行。您可以通过设置TASK_MANAGER_HTTP_PORT环境变量来更改此设置。
运行综合测试套件来验证功能：
npm test这将：
构建项目
启动服务器实例
将测试客户端连接到服务器
运行所有任务操作
验证正确的响应
自动关闭服务器
要从您的应用程序连接到 STDIO 服务器：
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 服务器：
<!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>列出所有可用任务。
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
}
});创建新任务。
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
}
});更新现有任务。
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
}
});删除任务。
const result = await client.callTool({
name: "deleteTask",
arguments: {
taskId: 123 // Required: ID of task to delete
}
});多变的 | 描述 | 默认 |
任务管理器API基础URL | 外部任务 API 的 URL | 无（必填） |
任务管理器API密钥 | 用于身份验证的 API 密钥 | 无（必填） |
任务管理器HTTP端口 | HTTP 服务器的端口 | 3000 |
港口 | 备用端口名称（优先） | 没有任何 |
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 documentation以监视模式启动 TypeScript 编译器：
npm run watch运行测试来验证更改：
npm test该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅 LICENSE 文件。
本项目使用@modelcontextprotocol/sdk进行MCP协议实现
专为与 AI 工具和 Web 应用程序集成而构建
| 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) |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to delete |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter tasks by status (optional) | |
| priority | No | Filter tasks by priority level (optional) |
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.
| 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) |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
createTaskdeleteTasklistTasksupdateTaskScored across 4 tools
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.
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