Session 2 — Tools, permissions and MCP

Session 2 of 13TheoryStudy guide6 min read

A study guide for a lecture that has already been given, including MCP.

Goals

• Distinguish between a tool, a tool call, and a programming interface.
• See why input in a valid format can still be rejected.
• Understand what MCP adds, and what it does not guarantee.

What passes along the way

A tool is an action the system allows you to request, for example reading the price of a product. Behind it there can be a local function or an external service. The programming interface defines how to address that service.

A single call includes a name, arguments, and a result or a failure. In the shop example, read_product with sku = "A" returns a price of 1500 cents.

JSON carries the data. A schema says what must appear: sku is text, price_cents is an integer, and there are no extra fields. The string "1400" is not an integer.

Even after the schema passes, three questions remain:

1. Who the user is, according to a source the system trusts.
2. Whether this user is allowed to change the product.
3. Whether the price meets the business rule.

The model supplies the requested values. The application supplies the authority.

This is a fixed word router, not a model. It shows one principle: the description you write for a tool affects the choice, and the code itself is not visible to whoever chooses.

User requestCalculate the difference between 95 and 90Calculator tool descriptionUse when the user asks for a calculation on numbers that were already found.

Chosen tool: calculator

A rejection that leaves the price in place

The current price is 15 dollars. Cost 10, shipping 2, and a minimum profit of 2, so the floor is 14 dollars. A request for 12 dollars is blocked. A customer's words about a manager's approval are not an approval.

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.

If the write happens before the check, the status can be a rejection and the price still changes. So you check the state, not just the sentence that came back.

A check can also go stale: the floor was 1400, and between the check and the write a manager raised it. A final result of 1500 does not prove that our request was not written, if someone else wrote afterwards. Without a write history you cannot decide.

A short loop

The history is sent to the model. If it requests a tool, the code checks and executes, and returns the result to the same history. Without the result, the next request may repeat an action that already happened. A rejection also counts as an attempt. When the budget runs out, that is a stop, not a success.

MCP

MCP is a shared protocol for discovering tools and calling them. The client asks which tools exist, gets a schema, and then sends a call. A valid call can still fail, for example if no GPU is free.

Two separate tools, one for a graphics processor and one for storage, do not guarantee that both succeed or that neither is saved. Connecting both under one name in MCP does not by itself create an atomic operation. That is a design question, and the full answer is not "a different order of the same calls".

Check your understanding

The tool returned policy_rejected, and the price changed from 1500 to 1200. What broke?

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

Reading

• The documentation of the model's tools approved for the course, on requests and results.
• JSON Schema: object, required fields, and forbidding extra fields.
• MCP architecture and the tools chapter: tools/list and tools/call.

Summary

What stays. The model proposes values. The code checks schema, permission and rule, and only then writes.

What breaks. Writing before checking leaves a rejected price in place. MCP does not turn two calls into one operation.

Next: session 3, The first agent

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