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 get 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.
A minimal Model Context Protocol (MCP) server built with TypeScript. It exposes a single tool, get_weather, over a stdio transport so that MCP-compatible clients (Claude Desktop, Claude Code, the MCP Inspector, etc.) can call it.
Built on @modelcontextprotocol/sdk
Input validation via zod
Communicates over stdio (JSON-RPC)
One example tool: get_weather
Related MCP server: MCP Demo Server
Node.js (v18+ recommended)
Yarn (v1 classic or Berry)
yarn installCompiles the TypeScript source in src/ to JavaScript in build/:
yarn buildThis runs tsc and marks build/index.js as executable.
Start the server directly (for a quick smoke test — it will sit silently listening on stdio, which is expected):
yarn startStart with the MCP Inspector (recommended for interactive testing/debugging):
yarn start:localThis launches a local web UI (usually at http://localhost:6274) where you can view the registered tools, call them with test inputs, and inspect the raw JSON-RPC traffic.
If running the Inspector through a Yarn script causes connection issues, run it directly instead:
npx @modelcontextprotocol/inspector node build/index.js
get_weatherReturns a (currently mocked) weather reading for a given city.
Input:
Parameter | Type | Description |
| string | Name of the city |
Example output:
The weather in Chandigarh is 24°C and sunny.Note: this is a stub implementation returning a random temperature. Replace the logic inside
registerTool("get_weather", ...)insrc/index.tswith a real weather API call as needed.
To use this server with Claude Desktop or another MCP client, add it to the client's config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"MCP-Server": {
"command": "node",
"args": ["/absolute/path/to/MCP-Server/build/index.js"]
}
}
}Restart the client afterward — the get_weather tool should appear as available.
.
├── src/
│ └── index.ts # Server entry point + tool definitions
├── build/ # Compiled output (generated by `yarn build`)
├── package.json
├── tsconfig.json
└── README.mdTo add more tools, call server.registerTool(...) again inside src/index.ts with a new name, schema, and handler. For larger projects, consider splitting each tool into its own file under src/tools/ and importing them into index.ts.
MIT
Get age
| Name | Required | Description | Default |
|---|---|---|---|
| person | Yes | Name of the person |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose any behavioral traits such as return format, default behavior, or side effects. Agent gets no insight beyond the tool's 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?
Extremely short, but lacks informative content. It is underspecified rather than efficiently concise.
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?
For a simple single-parameter tool with no output schema, the description fails to explain what the age is, how it is obtained, or any edge cases. Completely inadequate.
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?
Input schema covers the single parameter 'person' with a description. The tool description adds no extra meaning, but schema coverage is 100%, meeting baseline expectations.
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?
Tautological: description restates name/title.
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?
No guidance on when to use this tool versus alternatives like 'get_weather'. No context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current weather for a city
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Name of the city |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral disclosure. It does not mention rate limits, data freshness, units, or error handling. For a read operation, this is insufficient.
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 a single sentence with no waste and front-loads the verb 'Get'. However, it could afford to be slightly longer to include more useful details without losing conciseness.
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 (one parameter, no output schema), the description is too minimal. It does not explain the return format or units, leaving the agent without key information for selecting or invoking the tool.
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?
Schema description coverage is 100% (city is described as 'Name of the city'). The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 clearly states the verb 'Get' and the resource 'current weather for a city', which distinguishes it from sibling tool 'get_age'. However, it does not specify what aspects of weather are returned (e.g., temperature, conditions).
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?
No guidance is provided on when to use this tool versus alternatives. The sibling tool 'get_age' is unrelated, but there is no explicit when-to-use or when-not-to-use context.
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.
v1.0.0get_ageget_weatherScored across 2 tools
The two tools serve completely distinct purposes (age vs. weather), so there is no ambiguity or overlap. An agent can easily tell them apart.
Both tool names follow a consistent verb_noun pattern ('get_age', 'get_weather'), making the naming predictable and clear.
Only two tools exist, covering two unrelated domains. This feels insufficient for any meaningful workflow, as each domain likely requires more operations (e.g., for weather: location support, forecast; for age: input variations).
Each tool is a single isolated operation with no supporting tools (e.g., no set_age, no get_forecast). The surface is severely incomplete for any realistic use case.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…