Skip to main content
Glama

Carbon

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Get Intensity By Date

get_intensity_by_date
Read-onlyIdempotent

Get UK electricity carbon intensity for every 30-minute period on a specific date (e.g., "2024-01-15"). Returns gCO2/kWh forecast and actual. Use to identify lowest-carbon hours.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesDate in YYYY-MM-DD format (e.g., 2024-03-15)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesDate in YYYY-MM-DD format
countYesTotal number of 30-minute periods returned for the date
periodsYesArray of 30-minute intensity periods for the specified date

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Total number of 30-minute periods returned for the date",
+      "type": "number"
+    },
+    "date": {
+      "description": "Date in YYYY-MM-DD format",
+      "type": "string"
+    },
+    "periods": {
+      "description": "Array of 30-minute intensity periods for the specified date",
+      "items": {
+        "properties": {
+          "actual_gco2_per_kwh": {
+            "description": "Actual carbon intensity in grams CO2 per kilowatt-hour, or null if not available",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "forecast_gco2_per_kwh": {
+            "description": "Forecasted carbon intensity in grams CO2 per kilowatt-hour",
+            "type": "number"
+          },
+          "from": {
+            "description": "Start time of the 30-minute period (ISO 8601)",
+            "type": "string"
+          },
+          "index": {
+            "description": "Intensity index level",
+            "type": "string"
+          },
+          "to": {
+            "description": "End time of the 30-minute period (ISO 8601)",
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to",
+          "forecast_gco2_per_kwh",
+          "actual_gco2_per_kwh",
+          "index"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "date",
+    "periods",
+    "count"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "date": "2024-01-15"
+  },
+  {
+    "date": "2024-03-20"
+  }
+]
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare read-only and idempotent behavior, so the description adds value by disclosing output details: 30-minute intervals, gCO2/kWh units, forecast and actual values. This gives more context about what the tool returns without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the primary action and example, followed by a use case. Every word adds value with no redundancy.

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?

For a simple one-parameter read-only tool with an output schema, the description covers what it returns, the granularity, and an example. It also suggests a practical use case. No further explanation of return values is needed given the output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for the date parameter. The tool description repeats the format and gives an example but does not add meaningful semantic details beyond what the schema already provides. Baseline 3 is appropriate.

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?

The description clearly states the tool retrieves UK electricity carbon intensity for 30-minute periods on a specific date, with a concrete example. It distinguishes itself from siblings by specifying the date-based granularity and return of forecast/actual values.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a clear use case: 'Use to identify lowest-carbon hours.' However, it does not explicitly name alternatives or explain when not to use this tool versus siblings like get_intensity or get_regional_intensity, so it lacks explicit exclusions.

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

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