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., "@Weather MCP Server what's the weather like in Tokyo today?"
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 Model Context Protocol (MCP) server that provides weather information.
pnpm installRelated MCP server: Weather MCP
pnpm startpnpm testTo test your server with the MCP Inspector:
Install the Inspector (if not already installed):
npx @modelcontextprotocol/inspectorConfigure the connection:
Command: npx
Args: tsx main.ts
Or use the full command: npx tsx /path/to/mcpWeather/main.ts
Test the tool:
Select the fetch-Weather tool
Enter a city name (e.g., "Bogotá")
Call the tool
Get the weather for a given location.
Parameters:
city (string, required): City name like 'Bogotá'
Example:
{
"city": "Bogotá"
}Response:
{
"content": [
{
"type": "text",
"text": "The weather in Bogotá is sunny"
}
]
}⚠️ Zod Version: This project uses Zod v3.23.8 to match the MCP SDK requirements. Do not upgrade to Zod v4 as it will cause parameter registration issues.
The server uses:
MCP SDK: @modelcontextprotocol/sdk v1.20.0
Zod: v3.23.8 (for parameter validation)
TSX: v4 (for running TypeScript)
Get the weather for a given location
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | city name like 'Bogotá' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Get the weather' but doesn't disclose behavioral traits like rate limits, error handling, data freshness, or authentication needs. This leaves significant gaps for a tool that likely interacts with external data.
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, clear sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence contributes directly to understanding the tool's function.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what weather data is returned (e.g., temperature, conditions), potential errors, or usage constraints, which are crucial for effective tool invocation in this 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 description implies a 'location' parameter, but the input schema already fully documents the single parameter 'city' with 100% coverage. No additional semantic details are added beyond what the schema provides, so it meets the baseline for high schema coverage.
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 tool's purpose with a specific verb ('Get') and resource ('weather'), specifying it's for a given location. It's not a tautology of the name, but since there are no sibling tools, it doesn't need to differentiate from alternatives, so it doesn't achieve the highest score.
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, prerequisites, or exclusions. It only states what it does, without context for usage, which is minimal guidance.
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.0fetch-Weather2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsefetch-WeatherScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool has a distinct purpose of fetching weather data for a location.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'fetch-Weather' follows a verb-noun pattern, though the capitalization is inconsistent, but this does not affect the score due to the single-tool context.
A single tool for a weather server is too few for the apparent scope, as it lacks basic operations like forecasts, historical data, or location searches. This minimal set limits functionality and is not well-scoped for typical weather-related tasks.
The tool surface is severely incomplete for a weather domain, covering only current weather fetching. There are significant gaps, such as missing forecasts, alerts, or multi-location queries, which will likely cause agent failures in broader weather-related workflows.
Provide real-time and forecast weather information for locations in the United States using natura…
Get current weather for any city and create images from your prompts. Streamline planning, reports…
Free, keyless real-time weather and 7-day forecasts for any city worldwide.
Current temperature for a city via Open-Meteo. Query discarded after the call.