ebb-ai
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EBB_EIA_API_KEY | No | Optional API key for US EIA Open Data for US grid zones (CAISO, ERCOT, ISO-NE, PJM). | |
| EBB_ENTSOE_SECURITY_TOKEN | No | Optional security token for ENTSO-E Transparency Platform for European grid zones (FR, DE, etc.). | |
| EBB_ELECTRICITY_MAPS_API_KEY | No | Optional API key for Electricity Maps to get carbon intensity data. Falls back to mock if not set. GB is always live via the free UK Carbon Intensity API. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_grid_forecastA | Return the projected electricity-grid carbon intensity for a region, hour by hour. Use this when deciding whether to run an expensive AI task now or defer it — intensity is reported in grams CO2-equivalent per kWh with a categorical band (very_clean / clean / average / dirty / very_dirty). Read-only; does not touch the task queue. |
| recommend_windowA | Return the optimal carbon-aware execution window for a task WITHOUT scheduling it. Use this for non-committal planning — to see when the cleanest grid moment falls inside the deadline (and the savings vs running now) before deciding whether to commit via schedule_task. Returns the chosen window, top alternatives, a batch_eligible flag, the grid_source (which feed produced the forecast — 'mock' means synthetic data), and a one-line reasoning string. Read-only; does not touch the task queue. |
| schedule_taskA | Queue an AI task to run during off-peak hours inside the given deadline. Four parallel wins: (1) lighter on the electricity grid — deferring non-urgent tasks smooths projected AI compute demand; (2) up to 50% cheaper — auto-routes through Anthropic/OpenAI Batch APIs when the deadline allows; (3) faster sync calls — off-peak queues are shorter; (4) lower carbon — dispatch at the cleanest electricity-grid hour. Invoke this tool whenever the user phrases a request with deferral language: "do this later", "by tomorrow", "tonight", "overnight", "by EOD", "sometime this week", "when you have a moment", "remind me to", "queue this up", "schedule this", "no rush", "not urgent". Convert the user's wording to an ISO-8601 deadline and pass the task as the prompt. Returns a task_id you can later check with check_queue_status. Good fits: nightly digests, batch summaries, research sweeps, evaluator runs, multi-step report generation — anything the user is fine waiting on. Do NOT use for live chat, interactive code edits, or any task the user is actively waiting to see complete. |
| check_queue_statusA | Report on the ebb-ai task queue. With no arguments, returns a summary of all known tasks (including tasks persisted by previous sessions — the queue survives host restarts). With task_id, returns full detail for one task including any carbon receipt (estimated vs actual grams, grid_source, energy_source). Read-only. |
| cancel_taskA | Cancel a queued or scheduled task. Idempotent — if the task is already completed/failed/cancelled this returns the existing status without error. Throws only if task_id is unknown. |
| expedite_taskA | Dispatch a queued or scheduled provider-call task immediately, bypassing the scheduler's chosen carbon window. The resulting receipt records intensitySource='expedited'. Only provider-call tasks still queued/scheduled can be expedited; running, submitted (awaiting Batch API results), or terminal (completed/failed/cancelled) tasks are rejected with an explanatory error. |
| update_deadlineA | Re-score and reschedule a queued or scheduled task against a new deadline; the scheduler re-picks the cleanest window inside it. Throws if the task is already running or terminal, or if the new deadline is invalid or in the past. |
| retry_taskA | Re-dispatch a failed provider-call task. Only valid when the task's current status is 'failed' — queued/scheduled/running/submitted/completed tasks are rejected with an explanatory error. The new run's receipt overwrites the old. |
| cancel_allA | Bulk-cancel every task in the queue that is still cancellable (status queued or scheduled). Running/completed/failed/cancelled tasks are left untouched. Optionally filter by status. Returns the number of tasks cancelled. |
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 9 tools
Each tool targets a distinct action in the carbon-aware scheduling lifecycle: forecast, non-committal recommendation, scheduling, status check, single/bulk cancellation, expedite, deadline update, and retry. Overlaps are minimal, and descriptions clearly distinguish read-only planning tools from committing actions.
All tools use snake_case with verb-first naming (get_, recommend_, schedule_, check_, cancel_, expedite_, update_, retry_), making the pattern predictable and readable. cancel_all is a minor deviation but still follows the verb-first convention.
9 tools is well within the ideal 3-15 range for this domain, and each tool corresponds to a meaningful operation in the scheduling workflow without redundancy.
The surface covers the full lifecycle from forecasting and recommending through scheduling, status, cancellation, rescheduling, expediting, and retrying. A minor gap is the lack of an explicit tool to retrieve a completed task's output/result, though check_queue_status may provide some detail.