Skip to main content
Glama

AlertForge

by io.github.lasan713
OverviewDiscussionsAdmin

Plan scenes for a design-approved overlay pack

plan_overlay_pack

Requires an approved AlertForge account connection. OAuth-aware clients should start AlertForge's secure authorization flow and ask the user only to sign in and approve. Setup: https://alertforge.ai/ai-agents#agent-setup. Normalizes and prices scenes to add to a DESIGN-APPROVED project WITHOUT spending any credits or creating anything. Requires projectId from a project whose Style Sheet has been approved via approve_design_sheet -- every scene inherits that project's approved look (visual identity comes entirely from the Style Sheet; there is no theme/reference input here anymore). Calling this without a valid approved projectId returns a structured design_sheet_required error (with the product's 3 onboarding questions and the exact tool sequence to follow) instead of guessing a theme -- see plan_design_sheet. Returns a planId (valid 24 hours, single-use) plus the exact credit cost and a human-readable summary -- SHOW that summary and cost to the user and get their confirmation before calling create_overlay_pack with this planId. Call list_scene_kinds first to see which scene kinds are creatable -- including alert-pack, which crops the identity from this project's Style Sheet and creates the selected production overlay alerts, plus the four sheet-pack kinds (panel-pack, label-pack, sub-badge-pack, emote-pack): each sheet kind renders ONE themed sheet and crops it into individual tile PNGs (a Twitch panel set, activity-feed labels, subscriber badges, or channel emotes) -- pass per-tile overrides via tileTexts on that scene entry; list_scene_kinds' tileInputs reports each kind's exact slot count and whether labels are locked to fixed vocabulary.

Input Schema

NameRequiredDescriptionDefault
scenesYesThe scenes to include. Call list_scene_kinds first -- this tool rejects any kind that isn't creatable.
projectIdYesA design-approved project id -- from create_design_sheet, after approve_design_sheet has succeeded on it. Required.
durationSecNoDefault animation length in seconds for scenes that don't set their own.
imageQualityNoDefault quality for scenes that don't set their own.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: no credits are spent, nothing is created, the returned planId is single-use and valid 24 hours, and a missing approval yields a structured `design_sheet_required` error rather than a guessed theme. This resolves the tension with readOnlyHint=false by explaining the operation is a priced, non-mutating plan.

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 content is valuable but delivered as one dense run-on with stacked em-dashes and parentheticals, making it hard to scan. It is front-loaded with account setup rather than the core plan-then-confirm contract, and the scene-kind enumeration late in the paragraph could be tightened or deferred to list_scene_kinds.

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?

Covers everything an agent needs for a mutating-adjacent planning tool with no output schema: prerequisites, error semantics, the returned planId/cost/summary, the required user confirmation step, and the successor tool. No material gap remains.

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 already 100%, so the description is not obligated to document parameters, but it adds real cross-reference value: projectId's provenance via approve_design_sheet, that visual identity comes entirely from the Style Sheet (no theme/reference input), and how `tileTexts` maps onto sheet-pack scene kinds with fixed slot counts.

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?

States a specific verb and resource ('normalizes and prices scenes') and immediately contrasts with the sibling that actually creates content: it does so 'WITHOUT spending any credits or creating anything'. An agent can distinguish plan_overlay_pack from create_overlay_pack without opening either schema.

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?

Explicitly prescribes ordering — call list_scene_kinds first, obtain projectId from an approve_design_sheet-approved project, show the returned summary and cost to the user and get confirmation before calling create_overlay_pack. It also names the fallback (plan_design_sheet) when the prerequisite is missing, so the when/when-not decision is fully covered.

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

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