Skip to main content
Glama
CaptainCrouton89

MCP Server Boilerplate

by CaptainCrouton89
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

MCP Server Boilerplate

A starter template for building MCP (Model Context Protocol) servers. This boilerplate provides a clean foundation for creating your own MCP server that can integrate with Claude, Cursor, or other MCP-compatible AI assistants.

Purpose

This boilerplate helps you quickly start building:

  • Custom tools for AI assistants

  • Resource providers for dynamic content

  • Prompt templates for common operations

  • Integration points for external APIs and services

Related MCP server: MCP Template

Features

  • Simple "hello-world" tool example

  • TypeScript support with proper type definitions

  • Easy installation scripts for different MCP clients

  • Clean project structure ready for customization

How It Works

This MCP server template provides:

  1. A basic server setup using the MCP SDK

  2. Example tool implementation

  3. Build and installation scripts

  4. TypeScript configuration for development

The included example demonstrates how to create a simple tool that takes a name parameter and returns a greeting.

Getting Started

# Clone the boilerplate
git clone <your-repo-url>
cd mcp-server-boilerplate

# Install dependencies
pnpm install

# Build the project
pnpm run build

# Start the server
pnpm start

Installation Scripts

This boilerplate includes convenient installation scripts for different MCP clients:

# For Claude Desktop
pnpm run install-desktop

# For Cursor
pnpm run install-cursor

# For Claude Code
pnpm run install-code

# Generic installation
pnpm run install-server

These scripts will build the project and automatically update the appropriate configuration files.

Usage with Claude Desktop

The installation script will automatically add the configuration, but you can also manually add it to your claude_desktop_config.json file:

{
  "mcpServers": {
    "your-server-name": {
      "command": "node",
      "args": ["/path/to/your/dist/index.js"]
    }
  }
}

Then restart Claude Desktop to connect to the server.

Customizing Your Server

Adding Tools

Tools are functions that the AI assistant can call. Here's the basic structure:

server.tool(
  "tool-name",
  "Description of what the tool does",
  {
    // Zod schema for parameters
    param1: z.string().describe("Description of parameter"),
    param2: z.number().optional().describe("Optional parameter"),
  },
  async ({ param1, param2 }) => {
    // Your tool logic here
    return {
      content: [
        {
          type: "text",
          text: "Your response",
        },
      ],
    };
  }
);

Adding Resources

Resources provide dynamic content that the AI can access:

server.resource(
  "resource://example/{id}",
  "Description of the resource",
  async (uri) => {
    // Extract parameters from URI
    const id = uri.path.split("/").pop();

    return {
      contents: [
        {
          uri,
          mimeType: "text/plain",
          text: `Content for ${id}`,
        },
      ],
    };
  }
);

Adding Prompts

Prompts are reusable templates:

server.prompt(
  "prompt-name",
  "Description of the prompt",
  {
    // Parameters for the prompt
    topic: z.string().describe("The topic to discuss"),
  },
  async ({ topic }) => {
    return {
      description: `A prompt about ${topic}`,
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: `Please help me with ${topic}`,
          },
        },
      ],
    };
  }
);

Project Structure

├── src/
│   └── index.ts          # Main server implementation
├── scripts/              # Installation and utility scripts
├── dist/                 # Compiled JavaScript (generated)
├── package.json          # Project configuration
├── tsconfig.json         # TypeScript configuration
└── README.md            # This file

Development

  1. Make changes to src/index.ts

  2. Run pnpm run build to compile

  3. Test your server with pnpm start

  4. Use the installation scripts to update your MCP client configuration

Next Steps

  1. Update package.json with your project details

  2. Customize the server name and tools in src/index.ts

  3. Add your own tools, resources, and prompts

  4. Integrate with external APIs or databases as needed

License

MIT

Available Tools

2 tools
get-mcp-docsD

Make an MCP server

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesThe name of the MCP server

TDQS

D1.7/5.0
Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. 'Make an MCP server' doesn't indicate whether this is a read operation, a write operation, or something else. It doesn't disclose what happens when invoked (e.g., creates files, returns documentation, requires specific permissions). The description provides no behavioral context beyond the minimal action implied by the verb 'Make'.

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

Conciseness2/5

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

While technically concise with just three words, this is under-specification rather than effective conciseness. The description fails to communicate essential information and wastes the opportunity to provide meaningful guidance. A truly concise description would still convey purpose and usage while being brief.

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

Completeness1/5

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

Given a tool with 1 parameter, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what behavior to expect, or what the output might be. For a tool that presumably performs some meaningful action (based on the name 'get-mcp-docs'), this description leaves the agent with almost no useful information.

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 schema description coverage is 100%, so the schema already documents the single parameter 'name' as 'The name of the MCP server'. The description adds no additional meaning about this parameter - it doesn't explain what format the name should take, what it's used for, or provide examples. With complete schema coverage, the baseline of 3 is appropriate since the description doesn't compensate but also doesn't detract.

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

Purpose2/5

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

The description 'Make an MCP server' is a tautology that essentially restates the tool name 'get-mcp-docs' in different words. It doesn't specify what action is performed (e.g., retrieve documentation, generate code, create configuration) or what resource is involved. The description fails to distinguish this tool from its sibling 'hello-world' or provide any meaningful clarification about its function.

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

Usage Guidelines1/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, what context it's appropriate for, or any prerequisites. There's no mention of when-not-to-use scenarios or comparison with the sibling tool 'hello-world'. The agent receives zero usage direction beyond the vague description.

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

hello-worldB

Say hello to the user

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesThe name of the user

TDQS

B3.1/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. 'Say hello to the user' implies a read-only, non-destructive operation, but it doesn't specify output format, side effects, or any constraints (e.g., rate limits, authentication needs). For a tool with zero annotation coverage, this leaves significant 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.

Conciseness5/5

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

The description 'Say hello to the user' is a single, efficient sentence that directly conveys the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste, making it easy for an agent 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 simplicity (one parameter, no annotations, no output schema), the description is minimally adequate. It states what the tool does but lacks details on output, usage context, or behavioral traits. For a basic greeting tool, this might suffice, but it doesn't provide complete guidance for optimal agent invocation.

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, with the single parameter 'name' documented as 'The name of the user'. The description doesn't add any parameter details beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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 'Say hello to the user' clearly states the tool's purpose with a specific verb ('Say hello') and target ('to the user'). It distinguishes itself from the sibling tool 'get-mcp-docs' by focusing on greeting rather than documentation retrieval. However, it doesn't explicitly mention the resource being acted upon (e.g., generating a greeting message).

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. There's no mention of context, prerequisites, or comparison with the sibling tool 'get-mcp-docs'. The agent must infer usage based solely on the tool name and description without explicit direction.

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. 2 tool updates
    • First observedget-mcp-docs
    • First observedhello-world
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.2/5.0
Disambiguation5/5

The two tools have completely distinct purposes: one is for creating MCP servers (get-mcp-docs) and the other is for greeting users (hello-world). There is no overlap or ambiguity between these functions, making tool selection straightforward.

Naming Consistency2/5

The naming is inconsistent: get-mcp-docs uses kebab-case with a verb-noun structure, while hello-world uses kebab-case but is a phrase rather than a clear action. There is no predictable pattern across the tool set, making it harder to infer functionality from names alone.

Tool Count2/5

With only 2 tools, this server feels thin and under-scoped for a 'boilerplate' purpose, which typically implies a foundational set of utilities. The count is too low to provide meaningful coverage or demonstrate a coherent tool surface for server development.

Completeness1/5

The server is severely incomplete for a boilerplate MCP server domain. It lacks essential operations like configuration, testing, deployment, or common utilities, leaving obvious gaps that would hinder agent workflows and fail to support typical development tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

  • hithereiamaliff-mcp-nextcloudOAuth
    ai.smithery

    A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…

    Cloud StorageFile SystemsWorkplace & Productivity
    237
  • mcpCOAuth
    com.wix

    A Model Context Protocol server for Wix AI tools

    Developer ToolsContent Management SystemsApp Automation
    216
  • Apideck MCPA
    dev.apideck.mcp

    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

    Developer Tools
    42
  • TelnyxA
    com.telnyx.api

    The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.

    CommunicationCloud PlatformsCloud Storage
    62

Related MCP Servers

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/CaptainCrouton89/mcp-reasoning'

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