Add structured content to the TypeScript weather server and client and update to v2

[olaservo]

Updates the TypeScript examples to MCP SDK 2.0.0 and protocol revision 2026-07-28, and gives both tools a declared outputSchema with matching structuredContent.

get-alerts now returns a top-level JSON array. Before 2026-07-28 an output schema had to be object-rooted, so a tool returning a list had to invent a key to hang it off. get-forecast returns an object, for contrast.

Backwards compatibility note: The server declares the array schema once and never branches on protocol version — the SDK projects it for whichever era connects, so a 2025-11-25 client still sees {"type":"object","properties":{"result":{...}}} and gets {"result":[...]}. Verified against both.

Two pre-existing bugs fixed here

Both stopped the five examples being comparable. Declaring an outputSchema turns them from formatting differences into contract differences, which is why they're fixed rather than left.

• Wrong endpoint. get-alerts queried /alerts?area=XX (every alert ever, including expired) where the other four query /alerts/active/area/XX. For TX: 372 alerts before, 8 after, and the response drops from ~270KB to ~5KB.
• Different published fields. get-alerts published {event, area, severity, status, headline} against {event, area, severity, description, instructions} everywhere else, and forecast periods used NWS camelCase and weren't capped at 5. All five examples now advertise identical shapes.

Verification

A real get-alerts("TX") call against live NWS, captured off the raw wire with no SDK on the client side: outputSchema.type = "array", resultType: "complete", structuredContent an 8-item array, content one block of prose. Called against all five servers in the same minute — identical values from every one.

One of a set, one PR per language: #164 (Python, merged), #165 (TypeScript), #166 (Go), #167 (Rust); #163 was the shared test prerequisite and has merged. Ruby is not in the set — the mcp gem never emits the mandatory resultType, so a spec-strict client rejects every response. That needs an upstream fix.

---

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the TypeScript weather server/client examples to MCP SDK v2 (split client/server packages) and adds declared tool outputSchema with matching structuredContent, including an array-rooted schema for get-alerts to align with protocol revision 2026-07-28.

Changes:

• Migrate server to @modelcontextprotocol/server and use serveStdio(buildServer) with per-tool outputSchema + structuredContent for get-alerts (array) and get-forecast (object).
• Migrate client to @modelcontextprotocol/client, enable automatic protocol version negotiation, and surface basic structured-output handling.
• Update READMEs and dependency manifests/lockfiles for the new package split and Zod v4 usage.

Reviewed changes

Copilot reviewed 6 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
weather-server-typescript/src/index.ts	Switches to v2 server APIs, adds output schemas + structured results, and refactors server startup via serveStdio.
weather-server-typescript/README.md	Documents structured output behavior and backward-compat projection.
weather-server-typescript/package.json	Replaces @modelcontextprotocol/sdk with @modelcontextprotocol/server and adds zod.
weather-server-typescript/package-lock.json	Locks updated dependency graph for server v2 + Zod v4.
mcp-client-typescript/index.ts	Switches to v2 client APIs, enables versionNegotiation: auto, and distinguishes content vs structuredContent.
mcp-client-typescript/README.md	Documents structured output handling and version negotiation.
mcp-client-typescript/package.json	Replaces @modelcontextprotocol/sdk with @modelcontextprotocol/client.
mcp-client-typescript/package-lock.json	Locks updated dependency graph for client v2.

Files not reviewed (2)

• mcp-client-typescript/package-lock.json: Generated file
• weather-server-typescript/package-lock.json: Generated file

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 8 changed files in this pull request and generated no new comments.

Files not reviewed (2)

• mcp-client-typescript/package-lock.json: Generated file
• weather-server-typescript/package-lock.json: Generated file

Suppressed comments (3)

weather-server-typescript/src/index.ts:226

• The new structured result turns a missing temperature into the valid-looking value 0°F. ForecastPeriod.temperature is explicitly optional, so an incomplete upstream period will now publish incorrect machine-readable weather data rather than fail. Preserve the non-null output contract by rejecting a period that lacks its temperature (or unit) before constructing the result.

        periods: rawPeriods.slice(0, 5).map((period) => ({
          name: period.name ?? "Unknown",
          temperature: period.temperature ?? 0,
          temperature_unit: period.temperatureUnit ?? "F",

mcp-client-typescript/package.json:23

• The manifest now requires Node 20, but the root entry in mcp-client-typescript/package-lock.json still records engines.node as >=16.0.0. Regenerate/update the lockfile so installs and tooling see the same runtime contract.

    "node": ">=20.0.0"

weather-server-typescript/package.json:25

• This dependency requires Node 20+, but unlike the updated client, the weather server package does not declare an engines.node floor. Consumers on Node 18 can therefore select/install this example as if it were supported and only encounter the incompatibility through a transitive engine warning or at runtime. Add the Node 20 engine requirement here and refresh the lockfile root metadata.

    "@modelcontextprotocol/server": "^2.0.0",
    "zod": "^4.4.3"