Skip to main content
Glama

Step 3 — Call through FragGate

fraggate_call

Execute a known catalog slug+op through the FragGate single door (CallEnvelope → FragGate → Lamb Lens → SweepGate → Sentinel → Provenance → ChainLock-IN → DecisionGATE → AZPIPE → Internal Domain Layer → optional ASE → RoseClock → TemporalLock → ChainLock-OUT → ForgeReceipts → Return). Default exec path — not discovery and not a raw session. Use this when fraggate_list and fraggate_describe already identified a live allowlisted op. Do not use it for discovering names, inspecting one capability without exec, or raw session plumbing; use fraggate_list, fraggate_describe, or (only if asked) runtime_run / runtime_session_exec instead. Side effects are operation-dependent (read, write, or refuse). May reach an open world when the target op does (for example AZBrowser ethical_search); many ops stay isolate-local. Unknown names refuse FG-HALLUC-TOOL. Stub, local-only, and Remain-OFF verbs refuse FG-STUB / FG-LOCAL-ONLY / FG-GATE-REFUSE / FG-LAMB-REFUSE. FragGate is THE single door. Required: op. Also pass slug or name. Extra top-level keys other than name/slug/product/tool/op/verb/claim/proposal/ground/payload/session_id/id become the op payload when payload is omitted. UI aliases (list_modules, place, genesis_boot, hold, airlock, home, classify, doctor, pair) forward to catalog ops. Mutation requires confirm=true (runtime gate) or dry_run=true (preview only, no write). confirm and dry_run stay optional on inputSchema.required. Returns status, result, receipt, engine_slug, engine_op, engine_digest, ran_in, provenance, refusal, and limitations. Not the full FragGate door. Empty fraggate_list is discovery (hashed LIVE_OPS). Catalog LIVE_OPS slugs (40): 4dmap, ark, azai, azbot, azbrowser, azchat, azclce, azcoherence, azhub, aziel-corpus, azieltether, azinterface, azmail, aznet, azos, azvpn, chronolock, codelock, decisiongate, embryolock, employeelock, foldlock, forgereceipts, glossafilter, godlock, mialock, miragegrid, mmconsensus, peacelock, postking, shadowlock, spectrallock, staticclock, temporallock, toolbench, trajectorylock, vibelock, whistlelock, zkattest, zsolver. Compact product-verify tokens (not a second allowlist): allowlist.azhub LIVE_OPS: health, skill, region_list, place_module, remove_module, tether_declare, tether_cut, tether_list, blank_key_status, list_modules, place. allowlist.azinterface LIVE_OPS: health, skill, genesis_status, site_state_get, site_state_set, integrity_check, witness_list, page_cycle_status, genesis_boot, hold. allowlist.azbrowser LIVE_OPS: ethical_search, lamb_lens_search, navigate, airlock_ingest, airlock, home, tab_open, tab_list, receipt_list, verify, receipt_verify, sandbox_status, sandbox_render, health, skill, vpn. allowlist.azvpn LIVE_OPS: health, skill, doctor, limitation, describe, open, status, list, close, send, recv, pull, peers, attach. allowlist.aznet LIVE_OPS: health, doctor, pair_status, pair, garden_list, stamp, verify_hash, memorial_list, memorial_append, receipt_verify, skill. UI aliases forward to catalog ops. EmbryoLock LIVE_OPS health/skill/doctor/verify-hash/policy/limitation; wipe/scorch/unlock stay FG-STUB on the public mesh.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYesRequired public allowlisted op from fraggate_describe (for example fold-preview, ethical_search, blank_key_status). UI aliases (list_modules, place, genesis_boot, hold, airlock, home, classify, doctor, pair) forward to catalog ops. Unknown ops refuse FG-UNKNOWN-OP; stubs refuse FG-STUB.
nameNoOptional registry display name (for example FoldLock, EmbryoLock, AZHub). Use name or slug — one is enough. Combined name/op forms such as foldlock/fold-preview are accepted by the door parser. Unknown names refuse FG-HALLUC-TOOL.
slugNoOptional catalog slug (lowercase a-z0-9-, for example foldlock, embryolock, azhub). Alternative to name. Prefer the slug returned by fraggate_list or GET /v1/software.
claimNoOptional DecisionGATE proposal attached to this call. Also runs automatically inside the door even when omitted (defaults). Freedom without clarity is chaos.
confirmNoDocumented confirmation flag. Optional in inputSchema.required (connector refresh must not break). tools/call still refuses MCP-CONFIRM-REQUIRED when confirm is missing or false unless dry_run=true (preview, no write).
dry_runNoOptional preview flag. When true, return a would-mutate preview and do not write. Alternative to confirm=true. Does not mutate.
payloadNoOptional op payload object. Shape is engine-specific (see fraggate_describe). Malformed fields are refused by the engine, not by this door schema. If omitted, leftover top-level keys are used as the payload.
attempt_nNoOptional 1-based attempt number for this call. Omitted means attempt 1 of a new request_id.
request_idNoOptional logical request id. The same value groups retries of one action on the ResultEnvelope and, for ForgeReceipts, inside the receipt hash.
correlation_idNoOptional client correlation id. Sealed inside a ForgeReceipts hash when this call mints one.
parent_receipt_idNoOptional prior attempt receipt hash. Null on the first attempt. This is not FragGate ledger prev, which stays call order only.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoFragGate or fabric code when present: FG-OK, FG-HALLUC-TOOL, FG-STUB, FG-LOCAL-ONLY, FG-UNKNOWN-OP, FG-GATE-REFUSE, FG-LAMB-REFUSE, or a module refuse such as MESH-* / AKM-*.
doorNoDoor name. The public door is fraggate.
ran_inNoExecution locale (for example aziel-runtime) when present.
resultNoFragGate body: ok, code, door, slug, op, engine_digest, ran_in, provenance, refusal, limitations, receipt, plus the engine result. Unknown names refuse FG-HALLUC-TOOL; stubs refuse FG-STUB.
statusNoHTTP-like status when present on wrappers (200 ok; 400+ error / refuse).
displayNoHuman-facing envelope. Show title and summary, then take the next input.
receiptNoOptional receipt, ledger tip, or TemporalLock/ForgeReceipts exit when the door stamped one.
refusalNoExplicit refuse object, code, or message when the door or engine refused.
engine_opNoResolved engine op when present (often inside result).
ledger_tipNoAsk/refuse ledger tip when the door stamped one.
provenanceNoProvenance / input packet when the pipeline attached one.
session_idNoRaw session id when session plumbing was used. Hidden unless the user asked for the chain.
engine_slugNoResolved engine slug when present (often inside result).
limitationsNoCapability limitations or Remain-OFF notes when present.
engine_digestNo64-hex engine_digest when a true in-process engine ran (often inside result).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with annotations present, the description adds substantial behavioral context: operation-dependent side effects, open-world vs isolate-local behavior, refusal codes for unknown/stub/local-only ops, the confirm/dry_run mutation gate, and the non-exhaustive return shape. It also clarifies that it is 'Not the full FragGate door,' which manages expectations about scope. No contradiction with annotations is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core guidance is front-loaded: purpose, usage, exclusions, mutation requirements, and return fields appear early. The description is far longer than ideal due to the exhaustive 40-slug catalog and per-product allowlists, and 'UI aliases forward to catalog ops' is repeated. Still, the extra length is mostly operational detail rather than padding, and the structure is logical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, 11 parameters, nested objects, output schema, and sibling landscape, the description is remarkably complete. It covers preconditions, selection criteria, mutation semantics, error refusals, aliases, allowed slugs, and response fields. An agent has everything needed to invoke this tool correctly and confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds significant meaning beyond the schema: it explains that leftover top-level keys become the payload, that slug/name should accompany op, that confirm/dry_run gate mutation even though they are schema-optional, and that UI aliases forward to catalog ops. This is exactly the kind of parameter behavior an agent needs to call the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Execute a known catalog slug+op through the FragGate single door.' It immediately distinguishes this tool from discovery and raw-session tools by naming fraggate_list, fraggate_describe, runtime_run, and runtime_session_exec as the alternatives. The precise pipeline and 'not discovery and not a raw session' framing leave no ambiguity about what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool ('Use this when fraggate_list and fraggate_describe already identified a live allowlisted op') and when not to use it, naming the exact siblings to use instead. This is exemplary routing guidance that directly reduces agent mis-selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources