Weather Forecast

A Model Context Protocol (MCP) project that demonstrates how a single MCP server can serve multiple LLM clients. Two clients — one using Anthropic's Claude API and one using OpenAI's GPT-4 API — connect to the same weather server, showing how MCP decouples tool execution from model selection.

Why This Matters

Building LLM applications that call external tools typically requires provider-specific code. This project highlights the differences:

Without MCP: Each provider has its own SDK, tool schema format, and message structure. Switching models means rewriting integration code.

With MCP: The server and tool definitions are shared. However, each client still needs provider-specific code to handle tool call/response formats:

Concern	Anthropic Client	OpenAI Client
Tool schema	input_schema	function.parameters
Tool call format	content[].type === "tool_use"	message.tool_calls[]
Tool result format	type: "tool_result" with tool_use_id	role: "tool" with tool_call_id
Response structure	response.content[]	response.choices[0].message

With AWS Bedrock: This entire translation layer is abstracted away — just swap model IDs and the API handles the rest. This project demonstrates why that abstraction is valuable.

Key Observation: Same Data, Different Presentation

Given the same query ("What is today's forecast for Manhattan?") and the same raw NWS data, each model produces noticeably different output:

• Claude (Sonnet 4.5): Concise summary of just today and tonight, with a conversational sign-off
• GPT-4: Full week-long forecast with detailed bullet points

Neither client sets temperature (both default to ~1.0). The differences are purely model personality — different LLMs make different editorial choices about what's relevant.

Side-by-Side Comparison

Both models received the same query and the same raw NWS data. Here's what each returned:

Claude Sonnet 4.5	GPT-4
This Afternoon: Temperature: 29°F Sunny Wind: 6 mph from the northwest Tonight: Temperature: 20°F Mostly cloudy Wind: 0-3 mph from the northwest "It's a cold day in Manhattan! Make sure to bundle up if you're heading outside."	The forecast for Manhattan today is sunny with a temperature of 29°F and a NW wind of 6 mph. Tonight, it will be mostly cloudy with a temperature of 20°F... Tuesday: Mostly cloudy then slight chance light snow, high 35°F Wednesday: Partly sunny, high 39°F Thursday: Mostly sunny, high 34°F Friday: Sunny, high 34°F Saturday: Sunny, high 37°F Sunday: Chance light snow, high 37°F (continued for full 7-day forecast)
Approach: Answered exactly what was asked — today's forecast. Added a friendly, human touch.	Approach: Interpreted "today's forecast" broadly and included the entire week. Data-dense, no editorial voice.

Full sample responses are available in each client's sample-responses/ directory for reference.

Things to Try

• Adjust temperature: Add temperature: 0 to the API calls in either client to get more deterministic, focused responses. Higher values (up to 2.0 for OpenAI, 1.0 for Anthropic) increase creativity and variation. This is the easiest way to tighten up GPT-4's verbose output.
• Swap models: Try gpt-4o instead of gpt-4 in the OpenAI client, or claude-haiku-4-5-20251001 instead of Sonnet in the Anthropic client, and compare speed, cost, and response style.
• Add a system prompt: Neither client sends a system message. Adding one (e.g., "Only answer what the user asked. Be concise.") would give you direct control over response style regardless of model.
• Add a new MCP tool: Extend the server with a third tool (e.g., get-hourly-forecast) — both clients will automatically discover it via listTools() without any client-side code changes. This is the real power of MCP.

Architecture

┌─────────────────────┐     stdio      ┌──────────────────────┐
│  Anthropic Client   │◄──────────────►│                      │
│  (Claude Sonnet 4.5)│                │   MCP Weather Server │
└─────────────────────┘                │                      │
                                       │   Tools:             │
┌─────────────────────┐     stdio      │   - get-forecast     │
│  OpenAI Client      │◄──────────────►│   - get-alerts       │
│  (GPT-4)            │                │                      │
└─────────────────────┘                └──────────┬───────────┘
                                                  │
                                                  ▼
                                       ┌──────────────────────┐
                                       │  NWS API             │
                                       │  api.weather.gov     │
                                       └──────────────────────┘

MCP Transport: stdio

This project uses stdio (standard input/output) as the transport layer between clients and the MCP server. When a client starts, it spawns the server as a child process and communicates over stdin/stdout using JSON-RPC (Remote Procedure Call) messages — a lightweight protocol where the client sends a JSON request describing which function to call and with what arguments, and the server responds with the result in JSON.

How it works in this project:

1. The client runs node ../mcp-weather-server/build/index.js as a subprocess
2. The client sends a JSON-RPC request (e.g., {"method": "tools/call", "params": {"name": "get-forecast", ...}}) to the server's stdin
3. The server processes the request, calls the NWS API, and writes the JSON-RPC response to its stdout
4. The client reads the response and passes the weather data to the LLM for natural language formatting

Why stdio? It's the simplest MCP transport — no network configuration, no ports, no authentication. The server runs locally as a subprocess of the client, making it ideal for CLI tools and local development.

MCP also supports other transports:

• SSE (Server-Sent Events): Server runs as a standalone HTTP service. Multiple clients can connect remotely. Better for shared/hosted servers.
• Streamable HTTP: The newest transport option, replacing SSE for remote connections with better support for stateless and resumable sessions.

For a local demo like this, stdio is the right choice — zero setup, no network overhead, and the server lifecycle is managed automatically by the client.

Setup

Prerequisites

• Node.js
• An Anthropic API key and/or OpenAI API key

Install & Build

Each component is built independently:

# Server
cd mcp-weather-server && npm install && npm run build

# Anthropic client
cd mcp-weather-client-anthropic && npm install && npm run build

# OpenAI client
cd mcp-weather-client-openai && npm install && npm run build

Environment Variables

Rename the .env.sample to .env file in each client directory:

# mcp-weather-client-anthropic/.env
ANTHROPIC_API_KEY=your-key-here

# mcp-weather-client-openai/.env
OPENAI_API_KEY=your-key-here

Run

# Anthropic client
cd mcp-weather-client-anthropic
node build/index.js ../mcp-weather-server/build/index.js

# OpenAI client
cd mcp-weather-client-openai
node build/index.js ../mcp-weather-server/build/index.js

Type a weather query (e.g., "What's the forecast for Manhattan?") and type quit to exit.

MCP Server Tools

Tool	Description	Parameters
get-forecast	Weather forecast for a location	latitude, longitude
get-alerts	Active weather alerts for a state	state (two-letter code)

Both tools call the National Weather Service API and return formatted text responses.