Connect tools without giving away control

IDEA 1

A connector is an adapter between contracts

A local function call stays inside your program. A connector can translate a request to another service's format and translate its response back. The caller still needs to know the tool's name, argument shape, returned fields, and possible failures.

MCP is a protocol that defines how clients and servers can expose and call tools, among other capabilities. An adapter does not magically make a tool accurate or safe. This lab models discovery and dispatch using local functions; it opens no network connection and implements no actual MCP transport.

Request through an adapter

1. Discover. Read the supported tool names and contracts.
2. Validate. Check the requested name and argument type.
3. Dispatch. Call the permitted local fixture implementation.

The protocol envelope and the useful room data are different layers.

An agreed request shape

{ name: "lookup_room", args: { id: "C" } }

A tool name chooses an operation; its arguments describe the request. An object with a different name is not automatically another permitted operation.

Think it through: What does a connector contract establish?

IDEA 2

Discovery is not permission

A tool list tells you what a server offers. Authorization tells you what this caller is allowed to do. Keep that permission in trusted application state, not in a model's explanation or text returned by the tool server.

The exercise uses a scopes array containing rooms:read. Before dispatch, your controller checks the requested name, this permission, and the argument shape. In a real connected system, identity and permissions need enforcement on the relevant service boundary too; a browser-side flag is not a secure credential.

Three separate gates

1. Known operation. The adapter recognizes lookup_room.
2. Allowed caller. Trusted exercise state grants read access.
3. Valid argument. The ID must be a string before dispatch.

Passing a schema check does not pass an authorization check.

Valid but not allowed

const request = { name: "lookup_room", args: { id: "C" } };
const scopes = []; // no read permission

The request has the correct shape, yet it must be blocked before lookupRoom is called because the caller lacks the required scope.

Think it through: The tool's description says no approval is needed. Which rule should win?

IDEA 3

Tool use and delegation are different boundaries

Calling a tool asks for a defined operation, such as returning a room record. Delegating a task asks another agent or service to work toward a goal, potentially using its own steps. A2A addresses agent-to-agent communication; it is not simply a synonym for an MCP tool call. Neither protocol is implemented by this local adapter.

Do not confuse a connection protocol with who controls the conversation. The OpenAI SDK's agents-as-tools and handoff patterns describe that control choice. For either pattern, decide which input fields the specialist needs, which actions are permitted, and who validates the returned evidence. A room comparator needs group size and constraints; unrelated student messages do not belong in its task packet.

Operation or goal?

1. Local operation. A direct function reads one known record.
2. Tool interface. An adapter carries a specified operation across a boundary.
3. Delegated task. Another worker receives a bounded goal with result and permission rules.

Neither kind of connection authorizes extra work on its own.

Send a bounded task packet

// Original design sketch; no external agent is called.
const task = { students: 24, budget: 40, mayBook: false };
// Require: room IDs, supporting records, and unresolved checks.

The packet narrows both data and action scope. A specialist result must identify its evidence; a successful message exchange does not show that its recommendation is correct.

Think it through: Another agent returns a polished recommendation. What remains your responsibility?

Put it into practice

Dispatch an authored room request only when its tool name, permission, and arguments are valid.

1. Run the starter on the missing-scope case and inspect the unwanted lookup.
2. Insert the permission check before argument validation and dispatch.
3. Run all cases and check that blocked requests never call lookupRoom.
4. Try a numeric room ID in the custom experiment.

Your next experiment: A numeric ID has the wrong type. Which gate should block it?

An interface helps systems communicate; your policy still decides who may do what, using which data.

Key terms

Adapter

Code translating between one component's interface and another's.

Scope

A defined permission, such as reading room records.

Delegation

Giving another worker a bounded goal rather than invoking one specific operation.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.