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., "@MCP Server TypeScript Template add 15 and 27"
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.
A template for creating Model Context Protocol (MCP) servers using TypeScript. This project demonstrates how to implement a simple MCP server with custom tools.
This template implements a basic MCP server that provides tools for:
Example operation: A simple demonstration operation
Addition: A tool that adds two numbers
The server uses the Model Context Protocol SDK to handle communication between AI models and external tools.
Related MCP server: MCP Server Starter
Node.js (v16 or higher)
npm or yarn
The project is structured as follows:
mcp-server-typescript-template/
├── common/
│ ├── constant.ts # Project constants
│ ├── errors.ts # Error handling utilities
│ └── types.ts # Type definitions
│ └── utils.ts # Utility functions
├── operations/
│ └── example-operation.ts # Implementation of example operations
├── index.ts # Main server implementation
├── package.json
└── tsconfig.jsonClone the repository and install dependencies:
git clone <repository-url>
cd mcp-server-typescript-template
npm install
npm run test
npm run build
npm run start # this will start the server for testingedit your claude_desktop_config.json file to add the following:
{
"mcpServers": {
"example": {
"command": "node",
"args": [
"/path/to/mcp-server-typescript-template/dist/index.js"
]
}
}
}
Add two numbers
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
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. While 'Add' implies a computational operation, the description doesn't specify whether it's read-only, destructive, has rate limits, or what the output format might be. It lacks essential behavioral context for an agent.
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?
The description 'Add two numbers' is extremely concise and front-loaded, consisting of just three words that directly convey the core functionality. There's no wasted language, making it efficient and easy to parse.
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?
Given the tool's simplicity (2 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, potential errors, or behavioral traits, leaving gaps that could hinder an agent's effective use despite the straightforward operation.
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?
The description mentions 'two numbers', which aligns with the two parameters (a and b) in the schema. However, with 0% schema description coverage, the description doesn't add meaningful details about parameter roles, constraints, or examples beyond the basic count. It partially compensates but leaves parameters minimally documented.
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?
The description 'Add two numbers' clearly states the verb ('Add') and the resource ('two numbers'), making the purpose immediately understandable. It doesn't distinguish from the sibling tool 'example_operation', but the purpose is specific enough for this simple arithmetic operation.
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?
The description provides no guidance on when to use this tool versus alternatives or in what context it should be applied. There's no mention of prerequisites, limitations, or comparison with the sibling tool 'example_operation', leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A simple example operation
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| Yes | |||
| name | Yes |
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. However, it offers no information about what the tool does (e.g., whether it's a read, write, or compute operation), its effects, permissions required, rate limits, or error handling. This leaves the agent with no insight into the tool's behavior beyond its name.
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?
The description is concise with a single sentence, but it is under-specified rather than efficiently informative. While it avoids unnecessary length, it does not front-load critical information, as the content is too vague to be helpful. It earns a baseline score for brevity but lacks substantive structure.
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?
Given the tool's complexity (3 required parameters) and the absence of annotations and output schema, the description is completely inadequate. It does not explain the tool's purpose, usage, behavior, or parameters, leaving the agent with insufficient information to understand or invoke the tool correctly in any meaningful context.
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?
The input schema has 3 required parameters (name, email, date) with 0% description coverage, meaning the schema provides no semantic details. The description does not mention any parameters or their purposes, failing to compensate for the schema's lack of information. This leaves all parameters undocumented and their roles unclear.
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?
The description 'A simple example operation' is tautological, essentially restating the tool name 'example_operation' with minimal added meaning. It does not specify what the tool actually does (e.g., what action it performs or what resource it affects), nor does it differentiate from the sibling tool 'addition'. This leaves the purpose vague and uninformative.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or comparisons to the sibling tool 'addition', making it impossible for an agent to determine appropriate usage scenarios. This lack of direction is misleading in practice.
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. Dates show when Glama detected each change.
v1.0.0additionexample_operationThe two tools have clearly distinct purposes: 'addition' performs a mathematical operation on two numbers, while 'example_operation' appears to be a generic demonstration tool. There is no overlap or ambiguity between them, making it easy for an agent to select the correct tool based on the task.
The naming is mixed: 'addition' uses a noun form, while 'example_operation' uses a noun_verb pattern. This inconsistency in verb usage and structure makes the set less predictable, though both names are still readable and descriptive.
With only two tools, this server feels thin and under-scoped for a general-purpose TypeScript template. Such a template typically implies broader utility or demonstration capabilities, making this count insufficient for meaningful agent interactions or coverage of a domain.
The tool surface is severely incomplete for a TypeScript template server, which might be expected to include more operations like file handling, API interactions, or common utilities. The two tools provided do not cover any coherent domain or lifecycle, leaving significant gaps for agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Kickstart development with a customizable TypeScript template featuring sample tools for greeting,…
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/minimind-org/mcp-server-typescript-template'
If you have feedback or need assistance with the MCP directory API, please join our Discord server