Skip to main content
Glama

Explain a Shield event

explain_event
Read-onlyIdempotent

Explains a Shield visitor event in plain language by showing its origin, fired risk signals, risk score, recommendation, and what the in-page SDK did—without treating signals as a verdict.

Instructions

Explains one Shield event in plain language: where it came from, which risk signals fired, the score and recommendation, and what the in-page SDK did. The explanation describes risk signals, not a verdict about the visitor.

Input Schema

NameRequiredDescriptionDefault
siteNoSite ID, name or domain. Optional; without it each of your sites is checked
event_idYesEvent ID from recent_risky_events

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive and openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: what the response contains and, importantly, the framing caveat that it reports risk signals rather than a verdict about the visitor, which shapes how an agent should present results.

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

Conciseness5/5

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

Two sentences, front-loaded with the resource and the payload contents, and the second sentence delivers the interpretive caveat. No filler or restatement of the title.

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

Completeness4/5

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

With no output schema, the description correctly takes on the burden of describing return values by enumerating the fields of the explanation. It leaves unaddressed only edge behavior, such as what happens when an event_id is not found or the site scope is ambiguous.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (site scoping and event_id provenance) are already documented in the schema. The description adds no syntax, format, or resolution detail for site/event_id, so it sits at the baseline where the schema carries the load.

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?

Names a specific verb (Explains) and resource (one Shield event), then enumerates the exact contents of the explanation: origin, risk signals that fired, score, recommendation, and in-page SDK behavior. That level of detail distinguishes it from recent_risky_events, which lists rather than explains events.

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

Usage Guidelines3/5

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

The descoping is implicit: 'one Shield event' signals single-event investigation, and the schema's event_id note points an agent at recent_risky_events as the source. But the description itself never states when to choose this over recent_risky_events or lookup_ip, nor whether it must follow one of them.

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