Skip to main content
Glama

Ask AI

by com.ask-ai-data-connector
OverviewDiscussionsAdmin

set_intervention

TRIGGER: Call WITHOUT asking whenever the user applies or ships a fix. 'Fix' covers any shipped change — SEO/copy/ads/UX/ops, AND code/schema/connector changes. Distinct from save_insights (which captures observations) — this is for tracking actions: 'I changed X, hypothesised Y, will measure at dates [a,b,c]'. Auto-captures the most recent matching snapshots as baseline (for each {store, metric} in trackedMetrics), so you don't have to manually record baselines first. Use complete_intervention later to capture the post-fix snapshots and compute deltas. INPUT-MINIMAL EXAMPLE: set_intervention({store: 'acme-store-us', type: 'technical_seo', description: 'Applied hreflang fix to product pages', trackedMetrics: ['organic_clicks', 'organic_ctr'], checkDates: ['2026-06-07','2026-07-07','2026-08-07']}). For code/connector fixes use type: 'connector_fix' or similar. Pass linkedInsightIds when this intervention closes the loop on existing insights. After saving, tell the user in one line what you logged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesCategory of intervention.
notesNoFree-text context (excluded scope, caveats, etc.).
storeNoThe store/region this fix applies to. Either short ('acme-store-us') or full ('acme-store-us.myshopify.com') — both normalize.
watchNoOptional threshold watch evaluated on every get_briefing, so a breach SURFACES rather than being recomputed by hand each time. Shape: {metric:'orders'|'revenue', windowDays: 1-90, op:'lt'|'lte'|'gt'|'gte', threshold: number, note?: string}, e.g. {metric:'orders', windowDays:3, op:'lt', threshold:55}. Windows cover COMPLETE days only; an unsupported metric is rejected here rather than silently never firing.
_offsetNoPagination offset. If a response includes _pagination.hasMore=true, use _offset to fetch the next page.
appliedAtNoISO date (YYYY-MM-DD) the fix was ACTUALLY applied, for logging it retroactively (default: now). The baseline auto-lookup only considers snapshots within 60 days BEFORE this date — pass the real date so a retroactive log can still find an older-but-correct baseline instead of one anchored to today. Also anchors the auto-assigned checkDates horizon when checkDates isn't given. Must not be in the future.
checkDatesNoISO dates (YYYY-MM-DD) for planned check-ins, e.g. ['2026-06-07','2026-07-07','2026-08-07']. Stored for the dashboard / reminders; not enforced by the system.
hypothesisNoWhy you think it'll work (e.g. 'US property losing clicks to UK; hreflang should restore correct routing').
descriptionYesWhat was actually changed (e.g. 'Added hreflang tags to all PDPs to fix country-mismatch issue').
trackedMetricsNoMetrics to track for before/after comparison. Each entry is either a canonical metric key string (e.g. 'organic_clicks') OR an object {metric, segment?, source?} for dimensional pinning. Use the object form when a (metric, store) pair has snapshots across multiple segments or sources — otherwise the auto-baseline lookup is ambiguous and the call rejects with a list of candidates. Examples: ['cvr','aov'] (works when each metric has only one snapshot per store), [{metric:'organic_clicks',segment:'non_branded',source:'search-console'},{metric:'cvr',source:'ga4'}] (explicit dimensions per metric).
expectedMetricsNoOptional. Per-metric expectation, e.g. {organic_clicks: {deltaPercent: 15, direction: 'up'}}. Used at completion time to flag whether outcomes met expectations.
linkedInsightIdsNoInsights this intervention is acting on (the original finding(s) that prompted it). Captured for traceability — they're not modified.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / watch
      Added value: +{
+  "description": "Optional threshold watch evaluated on every get_briefing, so a breach SURFACES rather than being recomputed by hand each time. Shape: {metric:'orders'|'revenue', windowDays: 1-90, op:'lt'|'lte'|'gt'|'gte', threshold: number, note?: string}, e.g. {metric:'orders', windowDays:3, op:'lt', threshold:55}. Windows cover COMPLETE days only; an unsupported metric is rejected here rather than silently never firing.",
+  "type": "object"
+}
  2. Added
  3. Removed
  4. Added

TDQS

A4.7/5.0
Behavior4/5

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

The description clearly states side effects: it auto-captures baseline snapshots per {store, metric} in trackedMetrics, logs the intervention, and instructs the agent to tell the user one line after saving. It also notes the 60-day baseline window and the rejection behavior when auto-baseline lookup is ambiguous, which goes beyond the annotations (which are absent). Minus one because it doesn't explicitly state the destructive/read-only profile, but with no annotations at all, the description carries a reasonable burden and covers most observable behaviors.

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 description is detailed but front-loaded, with the most important trigger and distinction at the start, and a concrete example near the beginning. It's long, but most sentences carry operational value: the example, baseline behavior, and per-parameter notes all earn their place. A small deduction for some redundancy (e.g., 'Distinct from save_insights...' appears before and the auto-baseline detail is repeated in appliedAt).

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?

For a 12-parameter, mutation-like tool with nested objects and no output schema or annotations, the description covers the call trigger, the post-call behavior, baseline semantics, parameter edge cases, and the relationship to sibling tools. There is no output schema, but the description still explains the outcome well enough ('After saving, tell the user in one line what you logged').

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?

Despite 100% schema description coverage, the tool description actively adds meaning to several parameters: trackedMetrics gets an object/string distinction with an ambiguity rejection note, appliedAt gets a 60-day baseline context and retroactive logging guidance, watch gets a threshold-watch behavior explanation, and checkDates gets a 'not enforced' clarification. These go well beyond the schema and materially help an agent construct correct calls.

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 names a specific verb ('set') and resource ('intervention'), defines the trigger explicitly ('Call WITHOUT asking whenever the user applies or ships a fix'), and clarifies what counts as a fix with examples. It also contrasts with the sibling tool save_insights and references complete_intervention, making its purpose distinct.

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?

The description gives an explicit trigger condition, explicitly distinguishes from save_insights, explains when to use complete_intervention later, and includes an input-minimal example. It also covers enough edge conditions (code/connector fixes, linkedInsightIds, after-saving behavior) to be practically actionable.

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

All Ask AI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources