FUNCTION TOOLS · APPROVAL AND EFFECT WORKBENCH
Email tool: review intent before an effect
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
Choose operator, review the synthetic email and approve that exact payload. Step to the final gate and verify that precisely one message appears in the mock outbox.
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.
Verify an outbox effect without sending mail
Keep Email and its valid example. As viewer, finish the seven gates: the role gate rejects the mutation and the outbox stays empty. Choose operator and finish again: approval is still required. Approve the exact payload and finish to create email-1 for learner@example.test. Restart and finish again with the same mutation key; there must still be one message, with the original receipt reused. This experiment executes an in-memory append only. The reserved example.test recipient constraint intentionally prevents this fixture from representing a general email-address validator or a mail delivery service.
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.
Test a changed intention and a redacted response
After the first success, edit the subject. The old approval no longer applies. Approve the new payload while retaining intent-1: the idempotency gate rejects reuse because that key already belongs to the old subject. Change the key to intent-2, approve again and inspect two outbox records. Select the redaction hook and approve again: returned recipient becomes a redacted marker, while the stored message retains learner@example.test. Loading the boundary example rejects an outside.test address before execution. These cases separate intent binding, duplicate prevention and output filtering; none tests SMTP, message deliverability, authentication or mailbox authorization.
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.