self-starter
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
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.
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.
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.
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.