Loading ToolBench
Model Context Protocol server for carbon-aware AI task scheduling. Exposes tools for forecasting electricity-grid carbon intensity, recommending optimal execution windows, and scheduling tasks to run during the cleanest grid hours.
Strong domain-specific tool design with clear naming (verb_noun pattern), comprehensive parameter schemas, and detailed descriptions. All 10 tools have explicit input schemas with types and descriptions. Descriptions average ~180 chars, within the 10-1024 baseline. However, output schemas are not documented in the visible code, error handling lacks recovery guidance, and some parameter relationships (e.g., candidates/route_weights interdependency) could be more explicit. No tool annotations (readOnlyHint/destructiveHint) visible despite clear risk classifications. Security is well-handled (no secrets in params), but confirmation patterns for irreversible ops (schedule_task, cancel_all) are absent.
Cancel all queued and scheduled tasks in the queue. Running and completed tasks are not affected. Returns the count of cancelled tasks.
Cancel a single queued or scheduled task by ID. If the task is already running or completed, the cancellation is rejected. Returns the updated task record.
Inspect the task queue: list all tasks (optionally filtered by status), or fetch the full record and signed carbon receipt for one task by ID.
Move a queued task to the front of the queue so it runs at the next available window (within its deadline). If the task is already scheduled or running, the request is rejected.
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.
Output schemas not documented. Tools return complex objects (signed receipts, task records, routing decisions) but visible code does not show return type definitions. LLMs cannot plan downstream calls without knowing response structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible despite clear risk classifications (READ_ONLY, WRITE, REVERSIBLE). Agents cannot infer safety properties without explicit hints.
Irreversible operations (schedule_task, cancel_all) lack dry-run or confirmation patterns. Agents can enqueue tasks or cancel entire queues without preview or user confirmation, risking unintended side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Planning-only: return the cleanest execution window within a deadline for a hypothetical task, without enqueuing it. Useful for previewing carbon impact before committing. Returns the window, its carbon intensity band, and estimated grams CO2-equivalent.
Retry a failed task: re-enqueue it with the same prompt and deadline (or a new deadline if provided). The scheduler will pick a new window and dispatch again. If the task is queued, scheduled, or running, the retry is rejected.
Enqueue a task to run at the cleanest grid hour within a deadline. The scheduler picks the window, dispatches the provider call at that time, and records a signed carbon receipt. Supports dry-run preview, cross-provider routing, and carbon-budget enforcement.
OpenClaw-only: configure how task results are delivered when they complete — chat, Telegram, webhook, file, queue, or OS notification. Only available on the OpenClaw plugin host.
Update the deadline for a queued or scheduled task. The new deadline must be in the future and at least 1 minute away. If the task is already running or completed, the update is rejected.
Parameter interdependencies not fully documented. 'candidates' and 'route_weights' in schedule_task are mutually dependent (route_weights only apply when candidates has >=2 entries), but this constraint is buried in descriptions rather than explicit.
Error handling lacks recovery guidance. No visible error responses that tell LLMs what to do next (e.g., 'Task not found. Call check_queue_status() to list available tasks'). Agents will not know how to self-correct on failures.