F
licenseA
qualityD
maintenanceProvides calculator tools for mathematical operations, access to TypeScript SDK documentation, and meeting summary prompt templates through both stdio and SSE transports.
8
-
mcp-server-example
by nirojsapkota
Click on "Deploy 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-examplewhat's the weather in Tokyo?"
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.
MCP Server Example
A minimal example Model Context Protocol (MCP) server
built with the official TypeScript SDK (@modelcontextprotocol/sdk). It communicates over
stdio and demonstrates the three core MCP primitives:
Tools — callable functions:
add(a, b)— adds two numbers.get-weather(city)— returns a mock weather report.save-note(key, text)— saves a note in memory.
Resources — readable data:
notes://list— lists all saved notes as JSON.
Prompts — reusable prompt templates:
summarize-notes— asks the model to summarize all saved notes.
Setup
npm install
npm run buildRelated MCP server: mcp-demo
Run
npm startThe server communicates over stdio, so it's meant to be launched by an MCP client (e.g. Claude Desktop, VS Code, or the GitHub Copilot CLI), not run interactively.
Configure with an MCP client
Example client config (e.g. claude_desktop_config.json or similar):
{
"mcpServers": {
"example": {
"command": "node",
"args": ["/absolute/path/to/mcp-server-example/build/index.js"]
}
}
}Debugging
Use the official MCP Inspector to test the server interactively without a full client:
npx @modelcontextprotocol/inspector node build/index.jsProject structure
mcp-server-example/
├── src/
│ └── index.ts # Server implementation (tools, resources, prompts)
├── package.json
├── tsconfig.json
└── README.mdAvailable Tools
4 toolsaddAdd two numbersA
Adds two numbers together and returns the result.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
TDQS
A4.1/5.0
Behavior4/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 behavior. It states that the tool adds two numbers and returns the result, which is transparent and implies a pure function with no side effects. It does not mention error handling or edge cases, but for a simple addition, this is sufficient.
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 is a single, clear sentence that directly conveys the tool's purpose without any extraneous information. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple arithmetic operation, the description is complete: it specifies the inputs (two numbers), the action (adds), and the output (returns the result). No additional context is needed for correct 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 schema fully documents the parameters (a and b, both numbers, required), and the description simply restates 'two numbers' without adding extra meaning about ordering, constraints, or special values. Since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (adds) and the resource (two numbers), and the result is implied. It distinguishes from sibling tools like multiply, get-weather, and save-note by specifying the exact arithmetic operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives, but the context of sibling tools (multiply, weather, note) makes it implicitly clear that this is for addition. No exclusions or edge cases are noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-weatherGet weather (mock)A
Returns a mock weather report for a given city.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the responsibility for conveying behavior. It indicates the tool returns mock data and thereby implies no real-world side effects, but it does not explicitly state whether it is read-only, whether it can fail, or any other behavioral constraints. The term 'mock' offers some transparency but could be more detailed.
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 is a single concise sentence that conveys the essential purpose without any redundant information. It is well-structured and to the point, making it easy for an agent to process quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mock weather tool, the description provides enough context to understand its function and the required parameter. It does not specify the output format or any error behavior, but given the tool's simplicity and the absence of an output schema, the missing details are not critical. Slightly more detail would make it fully complete.
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 provides no description for the 'city' parameter, but the tool description says 'for a given city', which clarifies that the parameter represents a location. This gives partial meaning, but does not elaborate on expected format, examples, or limits. Since schema coverage is 0%, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning a mock weather report for a specified city. The verb 'returns' and the resource 'weather report' are explicit, and the inclusion of 'mock' clarifies the nature of the data. It is easily distinguishable from sibling tools like multiply or add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining weather data, but does not explicitly state when to use this tool over others. However, given the siblings are unrelated operations (arithmetic and note-saving), the appropriate context is obvious. A small explicit note could improve clarity, but it is not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
multiplyMultiply two numbersC
Multiplies two numbers together you jackass
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not mention return values, edge cases, errors, or side effects. For a pure arithmetic operation this is less critical, but transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, but the phrase 'you jackass' is unprofessional and unnecessary, reducing overall clarity and quality.
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?
Adequate for a trivial arithmetic tool, but no output schema or return behavior is described. Missing potential error handling or boundary conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description says 'two numbers' but does not explain parameters a and b individually or any constraints beyond their numeric type.
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?
Clearly states the operation: multiplying two numbers. Distinguishes it from sibling tools like add, though the trailing insult adds noise.
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?
No explicit guidance on when to use this tool versus alternatives like add. The use case is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save-noteSave a noteA
Saves a text note under a given key for later retrieval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| text | Yes |
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects, but it only says 'saves' without mentioning behaviors like overwriting existing notes, idempotency, or error handling. This is a noticeable gap.
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 is a single, clear, and front-loaded sentence with no filler. It efficiently conveys the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two string parameters, the description is mostly complete: it explains the operation and the roles of key and text. However, it would benefit from noting whether saving overwrites an existing key, but given the low complexity, it is still adequate.
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 has no parameter descriptions (0% coverage), so the description must compensate. It mentions 'key' and 'text note,' implying key is the identifier and text is the content, but it lacks specifics about formats, uniqueness, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (saves), the resource (a text note), and the purpose (under a given key for later retrieval). It is unambiguous and distinct from the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'for later retrieval,' but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No direct guidance is provided.
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.
4 tool updates
v1.0.0- First observed
add - First observed
get-weather - First observed
multiply - First observed
save-note
TDQS
B3.1/5.0
Scored across 4 tools
Disambiguation4/5
The tools are mostly easy to tell apart: multiply and add share an arithmetic context but perform clearly distinct operations, while get-weather and save-note are completely unrelated. The only minor ambiguity is that multiply and add could be grouped together by an agent looking for generic math tools.
Naming Consistency2/5
Naming is inconsistent: multiply and add are bare verbs, while get-weather and save-note use hyphenated verb-noun compounds. A uniform verb_noun convention would make the toolset more predictable.
Tool Count4/5
Four tools is a reasonable size for an example MCP server, and each tool has a distinct function. However, the tools serve unrelated domains, making the set feel like a demo grab-bag rather than a focused toolkit.
Completeness2/5
The set is incomplete for any single domain: arithmetic lacks subtract/divide, notes lack retrieval/deletion, and weather is just one mock endpoint. Agents would hit dead ends when trying to do basic related workflows.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
OpenAI-compatible LLM MCP (7 tools); chat via balance key or x402 USDC on Base
Cross-session, cross-device memory for your agent: remember and recall notes. No key to start.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Generate contextual prompts and reusable agent skills, evaluate prompts with the 16-dimension Prompt Score, and manage saved work in PromptDrive. Twelve MCP tools also provide authorized access to private Memory for source-grounded answers. Connect over Streamable HTTP using OAuth 2.1 and PKCE. Generation consumes account quota and automatically saves successful results; Memory access follows account permissions and plan limits.
Related MCP Servers
- AlicenseAqualityDmaintenanceA minimal MCP server example demonstrating Tools, Resources, and Prompts. It enables calculations, time queries, note management, and code review prompts via stdio transport.36 npmMIT
- FlicenseNot gradedqualityCmaintenanceEnables arithmetic addition, personalized greetings, version lookup, and text summarization through MCP tools, a resource, and a prompt.-
- FlicenseAqualityCmaintenanceEnables an LLM client to perform basic arithmetic on two numbers — addition, subtraction, multiplication, and division — plus reverse a supplied text string, through five simple tools exposed over stdio. Inputs and structured text results follow JSON schemas, with invalid operations such as division by zero surfaced as tool errors.5-