FUNCTION TOOLS · APPROVAL AND EFFECT WORKBENCH
Tool plugin policy: transform or reject a call
Edit real JSON arguments, inspect policy gates and watch an approved local function change a synthetic ledger.
Scroll the tool gateway horizontally to inspect every gate and ledger counter. The gate caption, output and synthetic ledger below provide text alternatives.
Request being reviewed
Your experiment
Compare no hook, block mutations and redact output. Explain which policy prevents a side effect and which only changes the returned representation.
Each gate takes eight inspection seconds, or use Next gate. Only reaching the final stage applies the planned local effect. Restart preserves the ledger; Reset synthetic ledger clears this page’s fictional state.
Returned output
Inspect the synthetic ledger
This browser-only gateway uses six handcrafted functions, not an ADK/Gemini service implementation. No emails, calendar invitations, network requests, real files, database queries or arbitrary code are executed. Email recipients are restricted to example.test; virtual files are two allowlisted map keys; arithmetic uses named operators, never eval. Calendar intervals use one synthetic day and no time zones or recurrence. Search is literal matching over three fixture sentences. Approval, role rules, hooks and receipt storage are illustrative application policies, not production security controls. Redaction changes two output fields only and is not a privacy or compliance guarantee. The ledger is held in page memory and is lost on reload. Function-tool concepts · Action-confirmation concepts.
Inspect a fixed dispatch contract
This lab is a local tool gateway with six preinstalled functions. The selector dispatches to known schemas and implementations; it does not discover, download, register or execute arbitrary plugins. Begin with Calculator and divide twelve by three: viewer permission is sufficient and the output is four. Change the divisor to zero and inspect rejection at execution after schema validation succeeds. Load the malformed example to fail at the earlier schema gate. Comparing the first failed gate shows why parsing, argument validation and function execution are separate responsibilities.
Build the exact request
Tool chooses one of six fixed local functions. Email appends to a synthetic outbox; calendar adds an interval to a fixture schedule; file and database access two allowlisted names; search ranks three local text records; calculator performs one arithmetic operation. Example loads a valid request, malformed JSON or a tool-specific boundary violation and replaces the editor. Arguments JSON is then the actual source of truth. Extra fields, incorrect types and values outside each documented bound are rejected. The displayed request and returned output are literal text; HTML inside an argument does not become executable markup. No function calls a remote service.
Apply policy before the effect
Role chooses viewer or operator. Mutations require operator permission and approval of the exact selected tool and payload. Approve exact payload toggles approval; changing a request or policy clears it. A read-only request needs no approval under this particular fixture policy. Hook can block mutations before execution or redact email recipients and file content from the returned output afterwards. Redaction does not erase the original value from the internal ledger. Irrelevant options are disabled. These deliberately separate controls let you locate the first rejected gate instead of interpreting every denial as a schema error.
Use hooks without confusing their scope
Select File and submit a read of /workspace/notes.txt with no content field. Viewer can read Original notes. A write to that same virtual path requires operator role and exact-payload approval. The before-tool blocking hook rejects a mutation even when permission and approval would otherwise allow it. Remove that hook, approve and run to change the in-memory file; read it back to verify the actual effect. The boundary example uses an unapproved path and is rejected by the schema. This is an allowlist over two virtual names, not a filesystem sandbox, operating-system permission check or general path traversal defense.
Distinguish rewind, replay and reset
Mutation key identifies one intended effect. With deduplication enabled, the same key and payload return a stored receipt without applying another mutation. Reusing that key with different arguments is rejected. A new key represents a new intention even when its payload is identical. Disable deduplication only after a successful mutation to observe duplicate synthetic effects. Restart rewinds inspection and retains the ledger and current approval; it is not an undo button. Reset synthetic ledger clears all fixture effects and receipts, restores deduplication and clears approval. No receipts survive a page reload, and there is no claim of durable exactly-once delivery.
Follow all seven gates
Play run and Pause inspect schema, before-hook, role, approval, idempotency, execution and after-hook, at eight viewing seconds per gate. Next gate advances one gate; Speed changes playback pace; Restart begins the current request again. Even a rejected plan has seven inspectable rows, with later rows marked skipped. Effects are committed to the displayed synthetic ledger only after the final inspection stage. Returned output appears then as well. Editing an input resets the inspection and pauses it, which prevents an old plan from finishing against new arguments. Read the text caption and ledger alongside the diagram; success here means the local contract completed, not that an email arrived or a production plugin was installed.