Skip to main content
Glama
Sign In

WebinarIgnition

by com.webinarignition
OverviewDiscussionsAdmin

Check whether the webinar emails really arrive

wi_check_mail_delivery
Idempotent

It measures whether email from the site really sends, whether it lands in the inbox instead of the spam folder, and how fast it goes out, with one plain verdict for each point. Take it when a host says people did not get a mail. "Half of them say nothing arrived." Careful: a fresh measurement sends real email from the host's site, which is why this one is not read only. It measures only when the stored result is missing or older than 24 hours, and runs again only when it is told to. Nothing on the webinar changes. Side effect: it sends real email from your site. Words hosts use: mail not arriving, spam folder, delivery test, inbox

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "webinar_id": "<webinar_id>"
    },
    "name": "wi_check_mail_delivery"
  }
}

Input Schema

NameRequiredDescriptionDefault
runNotrue measures again now instead of reading the stored result. Sends real email.
siteNoWhich connected site is meant when this chat has more than one: the address exactly as wi_get_connector_status lists it under sites. Leave it out while only one site is connected.
forceNotrue measures even when a recent result exists.
session_idNoFrom an earlier turn (weiter · texte · stand).
webinar_idYesThe webinar (campaign) id, as wi_list_webinars returned it.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / site
      Added value: +{
+  "description": "Which connected site is meant when this chat has more than one: the address exactly as wi_get_connector_status lists it under sites. Leave it out while only one site is connected.",
+  "type": "string"
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

It goes well beyond the annotations by disclosing that a fresh measurement sends real email from the host's site, explains why readOnlyHint is false, states that nothing on the webinar itself changes, and describes the 24-hour cache with re-run only on explicit instruction. That is exactly the side-effect and cost information an agent needs before invoking a non-read-only tool.

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

Conciseness3/5

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

The core facts are front-loaded well, but the real-email side effect is stated twice ("a fresh measurement sends real email from the host's site" and "Side effect: it sends real email from your site"), and the orphaned quote "Half of them say nothing arrived." adds noise. The trailing keyword list is useful for matching but pushes the definition toward padding.

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?

With an output schema present, return values need no explanation, and the description covers what the tool measures, when it re-measures, what it destroys (nothing on the webinar) and what it actually sends (real email). Nothing an agent needs in order to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning the schema does not: the caching rule explains when a call actually re-measures versus returns a stored result, which is the semantics behind the `run` and `force` flags. Site selection and session_id are still only explained in the schema, so it stops short of a 5.

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 concrete verb and resource set: it measures whether email really sends, whether it lands in the inbox versus spam, and how fast it goes out, with one verdict per point. That distinguishes it clearly from sibling mutation tools like wi_send_webinar_test_email or wi_resend_webinar_mails, which act on mail rather than measure delivery.

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

Usage Guidelines4/5

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

It gives a crisp trigger: "Take it when a host says people did not get a mail," plus host phrasings ("mail not arriving, spam folder, delivery test, inbox") that map natural language to this tool. It also states the caching condition (only measures when the stored result is missing or older than 24 hours). It never names the closest sibling alternative (e.g. sending a test email), so the routing is strong but not fully comparative.

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

All WebinarIgnition 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