Implementación del Protocolo de Contexto de Modelo (MCP) para la API de Gestión de Tareas, escrita en TypeScript. Este proyecto funciona como implementación de referencia y como servidor de gestión de tareas funcional.
Este servidor MCP se conecta a un servicio API de tareas externo y proporciona una interfaz estandarizada para la gestión de tareas. Admite dos modos de ejecución:
Modo STDIO : Comunicación de entrada/salida estándar para aplicaciones basadas en CLI y agentes de IA
Modo HTTP+SSE : servidor accesible desde la Web con eventos enviados por el servidor para navegadores y clientes basados en HTTP
El servidor ofrece un conjunto completo de operaciones de gestión de tareas, validación exhaustiva y manejo robusto de errores.
Related MCP server: Tiny TODO MCP
Operaciones de gestión de tareas :
Enumere las tareas existentes con capacidades de filtrado
Crea nuevas tareas con propiedades personalizables
Actualizar detalles de la tarea (descripción, estado, categoría, prioridad)
Eliminar tareas cuando estén completadas o ya no sean necesarias
Modos de interfaz dual :
Compatibilidad con el protocolo STDIO para la integración de agentes de IA y de línea de comandos
Protocolo HTTP+SSE con interfaz web para acceso basado en navegador
Implementación del protocolo MCP :
Implementación completa del Protocolo de Contexto Modelo
Recursos para estructuras de datos de tareas
Herramientas para operaciones de tareas
Manejo de errores y mensajes informativos
Seguro de calidad :
Cliente de prueba integral para validación
Apagado automático del servidor después de completar las pruebas
Validación detallada de las respuestas de la API
Node.js 16.x o superior
gestor de paquetes npm o pnpm
Clonar el repositorio:
git clone https://github.com/yourusername/mcp-template-ts.git
cd mcp-template-tsInstalar dependencias:
npm installo usando pnpm:
pnpm installCree un archivo .env con sus credenciales de API de tareas:
TASK_MANAGER_API_BASE_URL=https://your-task-api-url.com/api
TASK_MANAGER_API_KEY=your_api_key_here
TASK_MANAGER_HTTP_PORT=3000Construir el proyecto:
npm run buildnpm starto
node dist/index.jsnpm run start:httpo
node dist/http-server.jsDe forma predeterminada, el servidor HTTP se ejecuta en el puerto 3000. Puede cambiar esto configurando la variable de entorno TASK_MANAGER_HTTP_PORT .
Ejecute el conjunto de pruebas completo para verificar la funcionalidad:
npm testEsto hará lo siguiente:
Construir el proyecto
Iniciar una instancia de servidor
Conectar un cliente de prueba al servidor
Ejecutar todas las operaciones de la tarea
Verificar respuestas correctas
Apagar automáticamente el servidor
Para conectarse al servidor STDIO desde su aplicación:
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();Para conectarse al servidor HTTP desde un navegador:
<!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>Enumera todas las tareas disponibles.
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
}
});Crea una nueva tarea.
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
}
});Actualiza una tarea existente.
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
}
});Elimina una tarea.
const result = await client.callTool({
name: "deleteTask",
arguments: {
taskId: 123 // Required: ID of task to delete
}
});Variable | Descripción | Por defecto |
URL BASE DE LA API DEL ADMINISTRADOR DE TAREAS | URL para la API de tareas externas | Ninguno (obligatorio) |
CLAVE DE API DEL ADMINISTRADOR DE TAREAS | Clave API para autenticación | Ninguno (obligatorio) |
PUERTO HTTP DEL ADMINISTRADOR DE TAREAS | Puerto para el servidor HTTP | 3000 |
PUERTO | Nombre de puerto alternativo (tiene prioridad) | Ninguno |
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 documentationInicie el compilador de TypeScript en modo de observación:
npm run watchEjecutar pruebas para verificar los cambios:
npm testEste proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
Este proyecto utiliza @modelcontextprotocol/sdk para la implementación del protocolo MCP
Diseñado para la integración con herramientas de IA y aplicaciones 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