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 weather server What's the forecast for Lisbon on Saturday?"
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 server with one tool, get_forecast, that answers
"what's the weather in a city on a day?" using the free Open-Meteo API (no key needed).
It's the code from the video How to Build an MCP Server in Python (From Scratch): [VIDEO LINK]
Claude Desktop --(MCP over stdio)--> weather.py --(HTTPS)--> Open-MeteoPython 3.10 or newer
Claude Desktop, or any other MCP host
Related MCP server: Weather MCP Server
uv syncTest it on its own in the MCP Inspector (a local web page for trying out servers):
uv run mcp dev weather.pyIn the Inspector: Connect, then Tools and List Tools, then pick get_forecast, enter a city (Lisbon) and a date
within the next 16 days (YYYY-MM-DD), and click Run Tool.
Or test it from the terminal, the way a host talks to it (lists the tools, then calls the tool twice):
uv run python check_client.pyFind your full paths: which uv (on Windows where uv), and pwd in this folder.
Open Claude Desktop's config file (Claude Desktop: Settings, Developer, Edit Config), or create it if it's missing:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the weather entry from claude_desktop_config.example.json inside
mcpServers, with your two paths. Keep any servers already there.
Quit Claude Desktop completely and reopen it. Ask: Is it sunny in Lisbon on Saturday?
Claude asks for your permission before it runs the tool, and shows the arguments it chose.
The path must be absolute. --directory needs the full path to this folder.
Claude may not find uv. Use the full path from which uv as command.
Nothing may print to stdout. Over stdio, stdout carries the protocol messages; a stray print() breaks them.
Log with logging (it goes to stderr) instead.
Claude Desktop's own log for the server is in ~/Library/Logs/Claude/mcp-server-weather.log (macOS).
MCPServer("weather") is the server; @mcp.tool() turns get_forecast into a tool.
The type hints (city: str, day: str) become the tool's input schema; the docstring becomes the description the model reads.
The tool looks the city up with Open-Meteo's geocoding API, gets the daily forecast, and returns one short sentence,
such as Rainy, 20 °C on 2026-11-07.
An unknown city returns a message instead of raising an error, so the model can tell the user.
Weather data by Open-Meteo, free for non-commercial use. Built with the MCP Python SDK.
MIT, see LICENSE.
Get the weather forecast for a city on one day.
Args: city: City name, for example Lisbon day: Date as YYYY-MM-DD, within the next 16 days
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | ||
| city | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one important behavioral limit: the 16-day forecast horizon. It says nothing about units, timezone, or what happens when a date is out of range, so the disclosure is partial.
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?
Front-loaded one-line summary followed by a tight two-item Args block; every line carries information. Slightly repetitive docstring formatting, but no wasted content.
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 two-parameter read tool with an output schema already defining return values, the description covers the essentials: what is returned, the date format, and the valid date window. Only minor gaps remain (units, timezone, out-of-range behavior).
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 0%, but the description compensates well for both parameters: 'city' gets a concrete example (Lisbon) and 'day' gets a format ('YYYY-MM-DD') plus a range constraint ('within the next 16 days') that the schema does not express at all.
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 first sentence gives a specific verb ('Get') and resource ('weather forecast') with an explicit scope ('for a city on one day'). It is unambiguous what the tool returns, though with no sibling tools there is no differentiation work to do.
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?
Usage is implied rather than stated: the agent learns the day must fall 'within the next 16 days,' which is a real applicability constraint. There is no guidance on when not to use it or what to do for dates outside that window.
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_forecastScored across 1 tool
With a single tool there is nothing to confuse it with; the purpose (daily forecast for a city) is unambiguous. An agent cannot misselect among tools here.
get_forecast follows a clear verb_noun convention, though with only one tool there is no pattern to actually verify. It is readable and predictable, but consistency is untested.
One tool is thin even for a narrowly scoped weather server; users would reasonably expect current conditions or multi-day output. It is not mismatched to the stated purpose, but it is on the sparse edge.
The surface covers only a single-day forecast, with no tool for current conditions, multi-day ranges, alerts, or location lookup/geocoding. These are standard weather operations that agents would commonly need and cannot work around with this set.
Get current weather for any city and create images from your prompts. Streamline planning, reports…
Weather forecast for any city, UV index, sunrise and sunset, pollen and air quality. Free, no key.
Global weather via Open-Meteo: forecast, historical, marine, air quality, geocoding, elevation.
Current temperature for a city via Open-Meteo. Query discarded after the call.