Skip to main content

Agent + Weather MCP integration

This integration gives an Agent real-time weather ability through a shared Weather MCP server. The agent calls the MCP tool the same way it calls any other tool, while the weather logic stays isolated and versioned.

When to use it​

Use this pattern when you want a model to answer with current facts from a controlled tool instead of free browsing. The MCP contract is small and explicit, which makes it easy to verify and easy to roll back.

The pieces​

  • MCP server — hosts the weather tools.
  • Weather tool — returns current conditions for a city.
  • Agent — calls the tool and turns the result into a user-facing answer.

Step 1: Publish the weather tool​

platformctl mcp create weather-tools
platformctl mcp tools set weather-tools get_forecast \
  --handler @get_forecast.py \
  --description "Current weather for a city"

Step 2: Give the agent a tool contract​

The agent should see only the tool call shape. Keep it simple:

  • one argument, city: string
  • one result object
  • a short error when the city is unknown

That keeps the model focused on the decision instead of forcing it to parse arbitrary prose.

Step 3: Attach the tool to the agent​

How the agent attaches depends on the framework. The important part is that the MCP server becomes a first-class tool in the agent's toolset.

from google.adk.agents import Agent

from crusoe_adk.foundry import foundry_model
from crusoe_adk.mcp import mcp_toolsets
from crusoe_adk.tools import run_python

root_agent = Agent(
    name="weather_agent",
    model=foundry_model(),
    instruction=("Use tools when asked for current weather.\n\n"
                 "Prefer MCP tools over guessing."),
    tools=[run_python, *mcp_toolsets()],
)

mcp_toolsets() and mcp_tools() attach every Ready MCP server the project has. Pass names="weather-tools" — a string, or a list of names — when the agent should not see every tool in the project, or must not have its toolset widened the day somebody else deploys a server. A name that is not attached raises crusoe_core.UnknownMCPServer listing what is attached, rather than quietly attaching nothing.

Publish the tool before you deploy the agent

The platform bakes the project's Ready MCP servers into the agent's revision at deploy time, as the locked MCP_SERVERS variable — you cannot set it by hand afterwards, and a server that is not Ready is skipped. Publishing a tool answers 202 and starts a build; the server is not Ready until that build deploys.

So publish the tool, wait for Ready (platformctl mcp get weather-tools), then deploy — or redeploy — the agent. An agent deployed first gets an empty toolset and answers from memory, which looks exactly like the prompting failure Step 4 tells you to watch for.

Step 4: Test the flow​

Ask for the weather and then verify two things:

  1. the model used the tool rather than inventing a fact, and
  2. the answer matched the tool's response shape.

A good acceptance test is to ask for a city you know is in the tool's table. The response should be stable and exact. A city outside the table should produce the same honest error your MCP tool returns.

Common mistakes​

  • Forgetting that the MCP tool is versioned. The agent sees the currently deployed version; rollback returns to an older version, not an older source.
  • Mixing manual HTTP calls with MCP calls. The MCP protocol is the contract — agents and clients should use the standard tool call flow, not custom endpoints.
  • Letting the agent do the lookup in prose. The point of this pattern is that the model gets structured tool results, not a long web scrape.

Next steps​