Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
trigger_draftA

Submit a new trigger, or a new version of one, as a draft. The engine checks the definition, saves the probe code and runs the probe once. Returns the draft id, the trial run result, warnings and a plain-language description. Nothing runs on a schedule until trigger_activate. Pass either code you wrote or a ready-made recipe from trigger_recipes. Follow the self-starter:triggers skill when writing the definition and the probe.

trigger_recipesA

List the ready-made recipes: probes that ship with the plugin for common things to watch, such as an Interactive Brokers account. Each lists its parameters, the secrets the user must store first and the setup steps. Prefer a recipe when one fits.

trigger_activateA

Turn a draft on: its probe starts running on schedule, and each fire hands the task back to you. The trigger keeps working on its own after this, so decide first whether the user should confirm it; the self-starter:triggers skill says when to ask.

trigger_updateA

Change an existing trigger: probe.params, probe.interval, probe.timeout, probe.access, probe.permissions, for, policy, action, target (kind, cwd), notify, name or intent. The change takes effect at once and the firing rules start over. To change the probe code or the mode, use trigger_draft with replace=true instead.

trigger_tuneA

Make a trigger that fires more often than is useful quieter, keeping its state (no new baseline, no fire again for a condition that already holds): check less often, wait longer after a fire, require the condition to hold longer, allow fewer fires, or pause it. It is the one change allowed while handling a fire, and then only for the trigger that fired; the user is told what changed and why. Anything that makes a trigger more sensitive goes through the user and trigger_update.

trigger_listA

List all triggers with their state, last check, next check and number of fires.

trigger_getA

Details of one trigger: its definition, the state of its firing rules (waiting, cooling down, ...), recent checks and recent fires. Use it to explain why a trigger did or did not fire.

trigger_testA

Run an active trigger's probe once now and show the result, without firing or changing anything.

trigger_pauseA

Pause a trigger: its probe stops running until it is resumed.

trigger_resumeA

Resume a paused trigger. Its probe runs again right away.

trigger_deleteA

Delete a trigger, its probe code and its state. Its past fires stay in the history.

trigger_historyA

Recent fires, newest first, with how each was handled and the receipt. Leave out trigger_id to see all triggers.

trigger_reportA

Report that you finished handling a trigger fire (a message that starts with [self-starter]). Call it once per fire, at the end, with the fire_id from the message, one line on what you found or did, and notify=true only if the user should be told now.

service_statusA

Check the Self-Starter background service: version, available agent CLIs, trigger counts and today's agent runs.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 14 tools

Disambiguation4/5

Most tools map to clearly distinct actions (pause, resume, delete, list, get, test, history, report). The main friction is between trigger_update, trigger_tune and trigger_draft, which all modify a trigger; the descriptions do explicitly partition them (tune = quieter only, draft+replace = code/mode changes), so an agent can resolve it, but it takes careful reading. trigger_test also partly overlaps the trial run performed by trigger_draft.

Naming Consistency4/5

Thirteen of fourteen tools follow a predictable trigger_<verb> pattern in snake_case. The exceptions are trigger_recipes (a noun/listing verb) and service_status, which drops the trigger_ prefix entirely, but both remain readable and unambiguous.

Tool Count5/5

Fourteen tools is well within the ideal range and each one covers a distinct lifecycle stage or informational need (draft, activate, pause, resume, tune, test, history, report, recipes, service status). Nothing feels padded or redundant.

Completeness4/5

The trigger lifecycle is essentially closed: create (draft), activate, pause/resume, update/tune, test, inspect (get/list/history), report a fire, and delete, plus recipes and service health. Minor gaps remain around inspecting raw probe code/execution logs and any bulk or clone operation, but agents can work around these.

Maintenance

ActivityMaintained
ResponsivenessSyncing