Interaction Settings

Configure response payloads, global tool arguments, protocols, and webhooks

Interaction Settings control how your server processes and returns tool call results. You set defaults at the server level and optionally override them per integration. These settings are separate from security policies (side effects, redaction) which are configured in the Policy tab.

Server-Level Settings

Open your server’s settings (gear icon in the server dropdown) and go to the Interaction tab.

Enabled Protocols

Choose which transport protocols your server accepts:

  • MCP (Model Context Protocol) – JSON-RPC 2.0 over SSE. Enabled by default.
  • JSON-RPC 2.0 – Stateless HTTP POST. Enable this for legacy apps or cURL testing.

Webhooks

Receive real-time notifications when events occur on your server:

  1. Toggle Enable Webhook
  2. Enter your Webhook URL (e.g. https://your-server.com/webhook)
  3. Enter a Secret for signature verification
  4. Select which events trigger notifications:
    • Tool Created / Tool Updated
    • Tool Call Completed / Succeeded / Failed
    • Integration Added / Removed

Response Payload

Control what metadata DataGrout includes in tool call responses:

  • Include DataGrout metadata – Attach _meta.datagrout to responses
  • Include receipt – Include credit receipt (composite when inner tools are used) in the metadata
  • Include cost estimate – Include pre-execution cost estimate with per-component breakdown
  • Include CTC details – Include Cognitive Trust Certificate data (viewer URL, assurances, certificate chain). Enabled by default.
  • Include execution summary – Include a single natural-language sentence summarising billing, savings, and CTC status. Useful for agent planning. Enabled by default.

Turn these off if your agent doesn’t use cost tracking and you want smaller payloads. An agent that only needs directional cost/trust awareness can disable everything except the execution summary for a minimal-overhead _meta.datagrout containing just one sentence.

When gateway parameters like refract or chart are used, the receipt becomes a composite receipt showing per-component charges and savings. Each inner tool charges independently; the gateway folds all receipts together to prevent double-billing.

Global Tool Arguments

Add optional parameters to every tool on your server. These parameters modify how results are processed after execution.

  • Refract (default: on) – Adds a refract parameter to reshape output via prism.refract
  • Chart (default: off) – Adds a chart parameter to generate charts via prism.chart
  • Demux (default: off) – Adds demux and demux_mode parameters to broadcast calls across servers

Discovery, perform, and flow tools always have all three options regardless of these settings.

Integration-Level Overrides

Override server defaults for a specific integration:

  1. Open the integration’s detail page
  2. Go to the Interaction tab
  3. Toggle Override server defaults on this integration
  4. Configure the Response Payload and Global Tool Arguments sections

When the override is off, the tab shows the server defaults (read-only). When enabled, changes apply only to that integration.

Click Reset to Server Defaults to clear overrides and revert to the server configuration.

Cadence — Intelligent Loop Detection

Cadence prevents identical tool calls from executing in a loop while allowing legitimate retries and repeated queries. It operates on two layers:

Layer 1: Consequence-Aware Session Tracking (always active)

Cadence automatically classifies every tool by its declared side-effect metadata:

  • Read tools (queries, lookups) — allowed up to 3 identical calls without any intervening state change. Warning at 4, blocked at 6.
  • Write tools (create, update) — allowed once. A second identical call without state change triggers a confirmation gate with the original receipt ID.
  • Destructive tools (delete, send) — hard blocked after 1 execution per session.

“State change” means any other tool completed between the two identical calls. This detects whether the world changed — if it did, the repeat is legitimate. If nothing changed, it’s a loop.

This layer requires no configuration. Tiers are derived from existing tool annotations.

Layer 2: Time-Window Backstop (configurable)

The traditional debounce mechanism provides a secondary defense layer. Configure per-outcome rules to block repeat executions within a time window.

By default, the server ships with one rule:

  • Success (200) – 60-second window

This means a successful call cannot be re-executed with the same arguments for 60 seconds. Failed calls are not blocked by the time window, so legitimate retries go through immediately.

Adding Time-Window Rules

In the Interaction tab of your server settings, the Cadence section shows the current rule list. Use the form at the bottom to add rules:

  1. Select a response type (Success or Error)
  2. Enter the window in seconds (5–300)
  3. Click Add

You can add multiple rules. For example, to also throttle error retries:

  • Success (200) – 60s
  • Error – 10s

Disabling the Time-Window Backstop

Toggle the checkbox off to rely only on Cadence’s session-aware detection. The consequence-tier tracking cannot be disabled — it’s a safety mechanism that protects against agent loops regardless of timing.

Related