Skip to main content
Glama
enesjakozh
stevennevins

MCP Server Template

by stevennevins
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

MCP 服务器模板

一个使用 TypeScript 创建模型上下文协议 (MCP) 服务器的模板。此模板为构建兼容 MCP 的服务器奠定了坚实的基础，并提供了合适的工具、类型安全性和最佳实践。

特征

  • 🚀 全面支持 TypeScript

  • 🏗️基于容器的依赖注入

  • 📦具有 DataProcessor 接口的基于服务的架构

  • 🛠️ 带有测试的示例工具实现

  • 🧪 Vitest 测试框架

  • 📝 类型定义

  • 🔌 MCP SDK 集成

Related MCP server: MCP Server Template

入门

发展

  1. 安装依赖项：

    npm install

  2. 使用热重载启动开发服务器：

    npm run dev

  3. 构建项目：

    npm run build

  4. 运行测试：

    npm test

  5. 启动生产服务器：

    npm start

项目结构

src/
├── index.ts          # Entry point
├── interfaces/       # Interface definitions
│   └── tool.ts      # DataProcessor interface
└── tools/           # Tool implementations
    └── example.ts   # Example tool

创建工具

  1. 按照src/tools/example.ts中的示例导出工具和处理程序：

    // In your-tool.ts
export const YOUR_TOOLS = [
  {
    name: "your-tool-name",
    description: "Your tool description",
    parameters: {
      // Your tool parameters schema
    },
  },
];

export const YOUR_HANDLERS = {
  "your-tool-name": async (request) => {
    // Your tool handler implementation
    return {
      toolResult: {
        content: [{ type: "text", text: "Result" }],
      },
    };
  },
};

  2. 在src/index.ts中的ALL_TOOLS和ALL_HANDLERS常量中注册您的工具：

    // In src/index.ts
import { YOUR_TOOLS, YOUR_HANDLERS } from "./tools/your-tool.js";

// Combine all tools
const ALL_TOOLS = [...EXAMPLE_TOOLS, ...YOUR_TOOLS];
const ALL_HANDLERS = { ...EXAMPLE_HANDLERS, ...YOUR_HANDLERS };

服务器将自动：

  • 在可用工具中列出您的工具

  • 处理输入验证

  • 处理对您的工具的请求

  • 根据 MCP 协议格式化响应

测试

该模板包括用于本地测试的内置 TestClient 和用于可视化调试的 MCP Inspector。

使用 TestClient

TestClient 提供了一种测试工具的简单方法：

import { TestClient } from "./utils/TestClient";

describe("YourTool", () => {
  const client = new TestClient();

  it("should process data correctly", async () => {
    await client.assertToolCall(
      "your-tool-name",
      { input: "test" },
      (result) => {
        expect(result.toolResult.content).toBeDefined();
      }
    );
  });
});

使用 MCP 检查器

该模板包括用于工具可视化调试的 MCP 检查器：

  1. 启动检查器：

    npx @modelcontextprotocol/inspector node dist/index.js

  2. 在http://localhost:5173打开检查器 UI

检查员提供：

  • 测试工具的可视化界面

  • 实时请求/响应监控

  • 工具元数据检查

  • 交互式测试环境

使用游标进行本地测试

要使用 Cursor 在本地测试您的 MCP 服务器：

  1. 构建并链接包：

    npm run build
npm run link

  2. 验证二进制文件是否有效：

    npx example-mcp-tool

  3. 将服务器添加到 Cursor：

    • 打开光标设置

    • 导航至“功能”选项卡

    • 向下滚动到 MCP 服务器部分

    • 点击“添加服务器”

    • 选择“命令”类型

    • 给它起一个名字（例如，“本地示例工具”）

    • 输入命令： npx example-mcp-tool

    • 点击确认

  4. 通过检查 MCP 服务器部分是否显示您的服务器正在运行，验证服务器是否在 Cursor 中正确启动。

注意：如果您更改了代码，请记住重建并重新链接：

npm run build
npm run link

完成测试后，您可以取消链接包：

npm run unlink

这将删除在开发期间创建的全局符号链接。

Available Tools

1 tool
example-toolC

An example tool that processes input data

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesInput string to process

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'processes input data', which implies some action but doesn't reveal behavioral traits like whether it's read-only, destructive, requires authentication, has side effects, or rate limits. This leaves significant gaps in understanding how the tool behaves.

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 a single, efficient sentence with no wasted words, making it appropriately concise. However, it's front-loaded with the basic purpose but lacks structure or additional details that could enhance clarity, keeping it simple but under-specified.

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

Completeness2/5

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

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'processes' means, the expected output, or behavioral context, leaving the agent with insufficient information to use the tool effectively despite the straightforward schema.

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 description adds no specific meaning about the 'input' parameter beyond what the schema provides, which has 100% coverage and describes it as 'Input string to process'. With high schema coverage, the baseline is 3, as the schema adequately documents the parameter, and the description doesn't compensate or add further semantics.

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

Purpose3/5

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

The description states the tool 'processes input data', which provides a basic purpose but is vague about what 'processes' entails. It doesn't specify the type of processing or outcome, and with no sibling tools, differentiation isn't needed. This is a minimal viable description that communicates a general function without specifics.

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 offers no guidance on when to use this tool, such as context, prerequisites, or alternatives. With no sibling tools, it doesn't need to distinguish from others, but it lacks any usage instructions or scenarios, leaving the agent without direction on appropriate application.

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.

  1. 1 tool update
    • First observedexample-tool
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

C2.8/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools, as there are no other tools to compare it against. The single tool's purpose is clearly defined, eliminating any ambiguity in tool selection.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect—there are no other tools to create inconsistency. The tool name 'example-tool' follows a simple, clear pattern without any conflicting conventions to evaluate.

Tool Count2/5

A single tool is generally too few for a server's purpose, as it limits functionality and suggests an incomplete or trivial implementation. For a server named 'MCP Server Template', one tool feels insufficient to demonstrate a coherent set of capabilities, making it borderline inadequate.

Completeness1/5

The server's purpose is unclear from the name 'MCP Server Template', but with only one generic tool ('example-tool'), there are significant gaps in coverage. It lacks any CRUD operations, lifecycle management, or domain-specific functions, making it severely incomplete for any practical application.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches