Skip to main content
In this walkthrough you’ll run a small MCP (Model Context Protocol) server locally that connects a language model to real-time weather data from the free Open-Meteo API. The goal: let an assistant (for example, Claude) answer questions like “What is the weather like today?” by calling a trusted local tool that fetches live data. Why this pattern? LLMs are excellent at reasoning and natural language, but they don’t have up-to-date real-time knowledge. MCP lets you expose a controlled set of tools that the model can call to obtain fresh information (current weather, hourly forecasts, or a short summary) without giving the model direct network access. Open-Meteo quick example (curl)
Change latitude / longitude or the hourly parameters to request different fields. Open-Meteo uses simple HTTP GET queries and returns JSON. Repository and local server I built a small Node.js MCP server (Weather-MCP-Server) that calls Open-Meteo and exposes three MCP tools:
  • get_current_weather — current conditions for a latitude/longitude
  • get_weather_forecast — hourly forecast for a location (optionally specify days)
  • get_weather_summary — a natural-language summary that combines current + forecast
Clone and run:
This launches the MCP server (server.js) locally. The server advertises the three tools so an MPC-capable assistant can discover and call them. Tools overview Inspecting server.js Below is the consolidated Node.js MCP server used in this lesson. It defines the tool metadata (name, description, input schema), implements the Open-Meteo calls, maps tool names to handlers, and exposes MCP request handlers for tools/list and tools/call.
Testing with Postman Postman supports MCP requests and is a convenient way to test your local server. Create a new MCP request and configure Postman to run your Node server command. Use the node binary plus the full path to server.js as the command to launch when Postman starts the MCP connection:
A dark-themed Postman workspace screenshot showing a central pop-up menu with options like HTTP, GraphQL, WebSocket, Collection (highlighted) and other API/testing tools. The left sidebar lists workspace sections (Collections, Environments, APIs, Monitors, etc.).
When Postman launches the server, MCP messages are routed to your process and you should see the three advertised tools: get_current_weather, get_weather_forecast, and get_weather_summary. Example MCP call (tool invocation) Here’s a minimal MCP request body to call get_current_weather for latitude 45.4318 and longitude -123.1426:
The server will respond with JSON containing current weather fields (temperature, wind speed, etc.). Alternative: call Open-Meteo directly with curl You can bypass MCP and call Open-Meteo directly for quick checks:
This returns raw JSON arrays of hourly time, temperature_2m, and relativehumidity_2m. MCP wraps that low-level API behind simple tool interfaces so an assistant can use names, inferred parameters, and validated inputs instead of constructing queries manually. Integrating the MCP server with Claude To allow Claude to call your local MCP server, add the server entry in Claude’s Developer settings (MCP servers list). Example config.json snippet (used for Claude’s local MCP entries):
After saving and restarting Claude, the assistant will inspect advertised tools and their input schemas. When a user asks “What is the weather like in Forest Grove, Oregon today?” Claude can decide to call the appropriate tool and (if needed) infer or resolve parameters like lat/long. When Claude requests permission to call an MCP tool, you’ll typically see a permission modal. Grant access to let the assistant call the tool.
A code editor (project "WEATHER-MCP-SERVER") is visible behind a dark permission modal. The modal asks to allow "Claude" to use an external "get_weather_summary" Meteo API, with buttons to Decline, Allow always, or Allow once.
After granting permission, Claude will call the tool and can return a natural-language summary combined with the raw data:
A dark-mode chat window (Claude) in the center displays a weather summary for Forest Grove, Oregon (14.7°C, partly cloudy, ~14.1 km/h breeze, 61% humidity). Behind it is a Visual Studio Code window showing a project with files like server.js.
Best practices and next steps
  • Use input schemas to validate tool arguments and keep tool behavior explicit. That helps assistants choose tools appropriately.
  • Prefer to keep MCP servers local or behind strict access controls. Don’t expose your local testing server directly to the public Internet without proper authentication.
  • Use the get_weather_summary tool as a compact text response for chat UIs, while get_current_weather / get_weather_forecast provide structured data for downstream logic.
Do not expose local MCP servers publicly without authentication or firewall rules. MCP tools can access external APIs — treat them like any other backend service when it comes to security.
Why this matters
  • LLMs supply natural-language understanding, reasoning, and parameter inference (e.g., mapping a place name to lat/long).
  • An MCP server provides an explicit, auditable set of tools that call up-to-date external APIs.
  • Combined, this is a simple Retrieval-Augmented Generation (RAG) pattern: a model reasons and generates while external APIs provide current facts.
Links and references
Start small: run the server locally, test with Postman, and then connect your assistant. Once you have the basic flow working, extend the server to support geocoding (resolve names → lat/long), caching, or rate-limiting for production use.
Thank you — enjoy experimenting with MCP and real-time APIs.

Watch Video