Session 5 — Local tools and APIs

Session 5 of 13PracticeDraft5 min read

Draft for the lecturer's approval. This is preliminary study material. It does not replace guidance published in Moodle, and it does not set any date or grade.

Goals

• Connect a local tool and a tool that calls a free service.
• Reject invalid input and a forbidden action before execution.
• Keep a log in which the request, the decision and the result are visible.
• Return a tool failure as a result the agent can read, instead of crashing.

Two tools

calculator takes an operation and two numbers. It does not take a string to run.

weather calls Open-Meteo for coordinates that appear in a closed list, for example Tel Aviv. A city that is not on the list is rejected without a network call. This is how you learn permission even when the service itself is free. Open-Meteo's terms of use apply to the call, and here it is meant for non-commercial practice.

MCP comes in here as a second way to expose the same calculator: tools/list returns the schema, tools/call runs it. The local server does not replace the permission check.

The order of the checks

Every call goes through the same order, and only the last stage touches the world:

1. Schema: the required fields are there, and the types are right. "1400" as text is rejected.
2. Permission: the action is allowed for this user and this value. A city outside the list stops here.
3. Rule: the value meets the business rule, for example a price floor.
4. Execution: only now do you write or go to the network.

Each stage returns its own status. invalid_request, forbidden and policy_rejected are three different answers, and the agent needs to know which one it got.

The tool runs locally in your browser. The starting price is 1500 cents and the floor is 1400.

sku (product id)price_cents (price in cents)

Not run yet. Guess what will be stored before you click.

The playground above is the shop version from session 2. In lab 2 you add the call log and the weather service.

A log you can read

A log line holds the tool name, the arguments, the status, and what changed: how many writes, how many network calls. A line like this answers "what happened" without guessing from the text the model wrote afterwards.

weather  {"city": "paris"}     forbidden    network_calls=0
weather  {"city": "tel-aviv"}  unavailable  network_calls=0

A failure you return to the model

If Open-Meteo is unavailable, the result is a network error, not a made-up forecast. One more attempt is allowed. After it, you stop and report what is missing. A permission error does not get another attempt: a city outside the list will stay outside the list.

Run lab 2 without a network. Make sure an allowed city returns unavailable and not a temperature. Then add a third city to the list, and show in the log that a call for a city not on the list still records zero network calls.

Check your understanding

The external service did not answer in time. What does the tool return to the agent?

Pick an answer to see the explanation. There is no grade here.

Summary

What stays. Schema, permission, rule, and only then execution. Each stage returns its own status to the log.

What breaks. A network error that turns into a forecast. A retry on a permission refusal.

Next: session 6, Planning and decisions

The mark is saved only in this browser. It is not an academic record and is not sent to a server.