Agent Tool Use and Context Protocols

Language

Agent Tool Use and Context Protocols

Inspect the boundary between model output, a structured tool call, runtime validation, authorization, deterministic execution, returned observation, context update, and stopping. Every executable transition is produced by the frozen deterministic teaching policy and in-memory tool world.

AI Playgrounds

Evidence boundary.

This prototype uses a transparent deterministic teaching policy and frozen in-memory tools. It is not a frontier agent, does not expose hidden reasoning, and performs no real network, mail, calendar, or filesystem action.

Scenario

Principal

GOAL

1 · Proposemodel-side output

2 · Validatetool + schema

3 · Authorizeprincipal permission

4 · Executedeterministic tool

5 · Observeappend context

Context ledger

Candidate model outputs

Tool catalog

Availability, schema validity, authorization, and execution are separate states.

MCP envelope inspector

Version-scoped to MCP 2026-07-28. The abstract agent loop remains protocol-neutral.

Trace timeline

✨ Featured experiment

Permission is a runtime boundary

Core question: Why is a valid call still not automatically allowed?

Run and watch: Apply the permission scenario, compare principals, and trace the authorization result.

🎯 Try these scenarios first

Pick a scenario, predict what should happen, then apply it and compare the result with your prediction.

Scenario 1: An observation changes the next action

Core question: Why can the justified next step change after a tool returns?

Run and watch: Use the canonical scenario and step through the first call, observation, context update, and next proposal.

Predict first: Predict the next action before revealing the observation.

Explain afterward: Explain which new fact in context changed the decision.

Scenario 2: Invalid arguments stop before execution

Core question: Where should a malformed tool call be rejected?

Run and watch: Apply the invalid-arguments scenario and identify the first failed gate.

Predict first: Predict whether authorization or tool execution will be reached.

Explain afterward: Explain why schema validity and permission are separate checks.

Scenario 3: Permission is a runtime boundary

Core question: Why is a valid call still not automatically allowed?

Run and watch: Apply the permission scenario, compare principals, and trace the authorization result.

Predict first: Predict which principal can execute the proposed action.

Explain afterward: Explain why the model’s request cannot grant itself permission.

Scenario 4: Tool output is data, not an instruction

Core question: How should instruction-like text inside an observation be handled?

Run and watch: Apply the injection scenario and inspect the observation’s provenance and the next action.

Predict first: Predict whether the embedded instruction should control the agent.

Explain afterward: Explain why content and authority must remain separate.

Scenario 5: A good agent knows when to stop

Core question: When is another tool call unnecessary or unsafe?

Run and watch: Apply the termination scenario and inspect why the runtime chooses stop.

Predict first: Predict whether another call would add evidence toward the goal.

Explain afterward: Explain how an explicit stop condition prevents pointless loops.

↓ Read the step-by-step explanation

Quick Assign · QA-AGENT-01 · 10–15 min

A proposed call is not an executed action

Use one Guided Challenge and trace the candidate action through the actual runtime gates before deciding whether anything executes.

Use the existing Guided Challenge for the run/reveal step. Responses stay in this browser unless you deliberately copy or print them.

Will the proposed action execute, stop at validation, stop at authorization, fail during execution, or correctly stop? Why?Record the proposed output, the first decisive gate, whether execution occurred, and what observation/context change followed.Why are tool availability, schema validity, authorization, execution, and observation different states?How should the runtime treat instruction-like text returned by a tool, and why does provenance matter?

State snapshot appears here.

Before you read

An agent can propose an action, but a runtime decides whether anything executes. Follow the proposal through tool lookup, argument checks, permission, execution, observation, context update, and stopping.

Terms used in this explanation

Proposed action: Structured output requesting a tool call or stop.
Tool schema: The declared name, fields, and value types for a tool.
Validation: Checking whether a proposal matches that schema.
Authorization: Checking whether the acting principal has permission.
Observation: Data returned after a tool executes.
Provenance: A record of where data or context came from.
Context update: Adding selected observations to the next decision state.
Stop condition: A rule that ends the loop when the goal is met or progress is unsafe.

1. A proposal is not execution

The model-facing step produces structured text: a tool name and arguments, or a stop action. That proposal has no external effect by itself.

The runtime first checks whether the named tool exists and whether the arguments match its declared schema.

2. Validity and permission answer different questions

Validation asks whether the call is well formed. Authorization asks whether this principal may perform it in this context.

A call can be valid but denied, or invalid before permission is even considered. Keeping the gates separate makes the failure legible.

3. Execution returns an observation

Only a proposal that passes the required gates reaches the simulated tool. Its result is recorded as an observation with provenance.

An observation can contain untrusted text. Its content does not inherit the authority of the runtime or user instruction.

4. Context guides the next decision

The runtime selects what to add to context, preserving the source of each fact. The next proposal is based on that updated state.

The loop stops when the goal is satisfied, a required action is denied, the proposal is invalid, or no safe progress remains.

What this model leaves out

This is a deterministic, local simulation. It does not call real services, authenticate real users, or create external side effects.

Production agent systems also need secure credential handling, rate limits, retries, audit logs, sandboxing, human approval, and defenses against untrusted content.

For teachers

Curriculum: Structured tool calls, schemas, validation, authorization, observations, provenance, context updates, prompt injection boundaries, and stopping.

Pre-exploration prompts

Does writing a tool name cause the tool to run?
What is the difference between a malformed call and a forbidden call?
Can text returned by a tool grant itself authority?

Post-exploration prompts

Find the first gate that rejects the invalid call.
Switch principals. Which part of the trace changes?
Inspect the injection scenario. Which text is data?
Explain why the termination scenario should stop.

Misconceptions to test: a model proposal is execution; schema validity implies permission; tool output is trusted instruction; more context is always better; an agent should keep calling tools until it is forced to stop.

↑ Back to the applet controls

Guided Challenge · predict before reveal

Challenge

Accessible state

Complete text-equivalent state for the current deterministic trace.

Check your model of the agent loop

If the model says it called a tool, the tool ran. No. Natural-language text is not an executable structured call.
If a tool appears in the catalog, the agent is authorized to use it. No. Availability and authorization are separate runtime states.
Schema-valid means the action is correct. No. Validation establishes only that the argument object satisfies the declared structural contract.
A tool output is automatically an instruction to the agent. No. Tool-provided content is an observation with provenance and can be untrusted data.
Every agent task needs multiple tool calls. No. Some goals require no call, one call, or a correct stop decision.
The model itself executes external side effects. Not in this architecture. A host/runtime decides whether a structured call is valid, authorized, and actually executed.
MCP is what makes a system an agent. No. MCP is one versioned protocol scenario; the conceptual action loop is protocol-neutral.
An agent should keep calling tools while useful tools remain available. No. Once the goal conditions are satisfied, termination can be the justified next action.
A failed tool call and a denied tool call are the same state. No. Validation failure, authorization denial, and execution error occur at different gates.
One prompt-injection defense makes arbitrary tool content safe. No. This toy host demonstrates bounded provenance separation only; it does not solve prompt injection generally.

Key distinctions

Model output: text or structured data proposed by the model-side policy. Tool call: an executable action candidate containing a tool name and argument object. Schema-valid: the arguments satisfy the tool's declared structural constraints. Authorized: the current principal is permitted to invoke the tool. Executed: the runtime actually invoked the deterministic tool implementation. Observation: structured data returned by execution. Context update: appending that observation with provenance so it can affect a later decision. Termination: stopping when the goal conditions are satisfied rather than making another call.