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 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 are present, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, idempotent, or any side effects. Minimal information.
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 extremely short (two words) but at the cost of omitting essential context. Brevity is not beneficial here as it leaves the agent with insufficient guidance.
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?
The tool has one parameter and no output schema, yet the description does not explain what the tool returns (e.g., age as a number, string, format). Incomplete for practical use.
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% and the parameter 'person' has a clear description ('Name of the person'). 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?
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. The only sibling is 'get_weather', but no explicit conditions or exclusions are provided.
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?
No annotations provided; description only implies a read operation but does not confirm idempotency, rate limits, or data freshness.
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?
Single sentence with no fluff, directly conveys the tool's purpose.
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?
No output schema; description does not explain return format. Adequate for a simple tool but incomplete for usage planning.
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 coverage is 100%, and the description adds no additional meaning beyond the schema's parameter description.
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?
Description clearly states verb 'Get' and resource 'current weather for a city'. It distinguishes from sibling tool 'get_age' due to different domain.
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 vs alternatives. No context about prerequisites or limitations.
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.0get_ageget_weatherThe 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vikrantkalyan23/typescript-mcp-tool-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server