F
licenseNot graded
qualityD
maintenanceA boilerplate project for quickly developing MCP servers using TypeScript, featuring example implementations of tools (calculator, greetings) and resources (server info) with Zod schema validation.
calculator-mcp-server
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., "@calculator-mcp-servercalculate 5 + 3"
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.
NitroStack Starter Template
Minimal template for learning NitroStack fundamentals with a calculator-focused MCP server and basic widgets.
What This Template Includes
calculatormodule with tools, resources, and promptsTypeScript + Zod validation setup
Widget-ready project structure
Production-friendly npm scripts
Related MCP server: Calculator MCP Server
Quick Start
npx @nitrostack/cli init my-server --template typescript-starter
cd my-server
npm run devCommon Commands
npm run dev
npm run build
npm startNitroStudio
NitroStudio is the recommended way to test and debug this template during development.
Download: https://nitrostack.ai/studio
Studio: https://nitrostack.ai/studio
Links
Templates docs: https://docs.nitrostack.ai/templates/01-starter-template
Main repository: https://github.com/nitrocloudofficial/nitrostack
Community
Available Tools
2 toolscalculateC
Perform basic arithmetic calculations
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number | |
| b | Yes | Second number | |
| operation | Yes | The operation to perform |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits, but it only states 'basic arithmetic calculations'. It does not mention edge cases (e.g., division by zero), precision, or return format.
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, clear sentence with no unnecessary words. However, it could be slightly more informative without being verbose.
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 simplicity of the tool and full schema coverage, the description is adequate but lacks information about output, error handling, or limitations.
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?
Schema description coverage is 100%, so the schema already documents parameters well. The description adds no extra meaning beyond 'basic arithmetic calculations', providing baseline value.
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 'Perform basic arithmetic calculations' clearly states the verb and resource, indicating the tool does math operations. However, it does not differentiate from the sibling tool 'convert_temperature', which is a distinct domain.
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 guidance is provided on when to use this tool versus alternatives like 'convert_temperature'. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_temperatureC
Convert temperature units based on file content or direct input. Supports Celsius (C) and Fahrenheit (F).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | Temperature value to convert | |
| to_unit | No | Unit to convert to (C or F) | |
| file_name | Yes | Name of the uploaded file | |
| file_type | Yes | MIME type of the uploaded file | |
| from_unit | No | Unit to convert from (C or F) | |
| file_content | Yes | Base64 encoded file content. Will be injected by system. |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description lacks details on errors, side effects, idempotency, or behavior when both file and direct input are provided.
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?
Two sentences, no redundancy, but could better structure intent versus required parameters.
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?
No output schema; description omits return format, behavior for missing values, or handling of file-based conversion steps.
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?
Schema covers 100% of parameters with descriptions; description adds minimal value beyond stating 'file content or direct input', not resolving parameter dependency conflict.
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 clearly states temperature conversion between Celsius and Fahrenheit, but contradicts the schema by saying 'direct input' while requiring file parameters.
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 guidance on when to use this tool versus alternatives (e.g., 'calculate'), nor conditions for direct input vs. file-based conversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
B3.2/5.0
Disambiguation5/5
The two tools, 'calculate' and 'convert_temperature', have clearly distinct purposes with no overlap. An agent can easily select the appropriate tool based on the task.
Naming Consistency5/5
Both tool names follow a consistent verb_noun pattern: 'calculate' (verb) and 'convert_temperature' (verb_noun). The naming is predictable and clear.
Tool Count4/5
With only 2 tools, the set is minimal but still reasonable for a focused calculator server. It covers core arithmetic calculation and temperature conversion without unnecessary clutter.
Completeness3/5
The tool surface covers basic arithmetic and temperature conversion, but lacks other common calculator operations like exponentiation, trigonometry, or memory functions, leaving notable gaps for a general-purpose calculator.
Maintenance
ActivitySlowing
ResponsivenessSyncing
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
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceA calculator-focused MCP server with TypeScript and Zod validation, providing tools, resources, and prompts for basic arithmetic operations.
- FlicenseNot gradedqualityCmaintenanceMinimal MCP server for basic calculator operations, built with NitroStack, TypeScript, and Zod validation.8
- FlicenseBqualityBmaintenanceA starter template for building a calculator-focused MCP server with tools, resources, and prompts using TypeScript and Zod validation.2
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/srichyavang-spec/admission-guardian'
If you have feedback or need assistance with the MCP directory API, please join our Discord server