Skip to main content
Glama
Sign In
DC Hub: Data Center, Power Grid & Energy Intelligence

DC Hub: Data Center, Power Grid & Energy Intelligence

by azmartone67
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Remote

Read Inbox

read_inbox
Read-onlyIdempotent

Retrieve DC Hub notes left for your partner agent, newest first; the initial call marks them read, while include_read rechecks the last 14 days without consuming them.

Instructions

Use this when a partner key reads its DC Hub inbox. PARTNER KEY ONLY: notes DC Hub left for the partner agent whose key this session sends, newest first. The first read CONSUMES them (marks read), so a later session sees none; include_read=true re-reads read and unread notes (last 14 days) without marking. Non-partner key: 403. Not a data tool.

Input Schema

NameRequiredDescriptionDefault
daysNoDays back (default 14)
peekNotrue = do not mark read
include_readNotrue = re-read read and unread notes, marks nothing

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv2.12.45
    • changedOutput schema / additionalProperties
      Previous value: -{}New value: +true
    • removedOutput schema / description
      Removed value: -"DC Hub envelope: tool data fields ride at the top level beside these keys."
    • removedOutput schema / properties / _entity
      Removed value: -{
-  "description": "Payload class (facility|market|iso_grid|queue_results|deal|report|response); branch on it.",
-  "type": "string"
-}
    • removedOutput schema / properties / _front_door
      Removed value: -{
-  "additionalProperties": {},
-  "description": "First-tool hint: plan_query(intent) returns the ordered plan.",
-  "properties": {},
-  "type": "object"
-}
    • removedOutput schema / properties / _return_loop
      Removed value: -{
-  "additionalProperties": {},
-  "description": "Next-session delta call (get_changes).",
-  "properties": {},
-  "type": "object"
-}
    • removedOutput schema / properties / citation
      Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": {},
-      "properties": {},
-      "type": "object"
-    },
-    {
-      "type": "string"
-    }
-  ],
-  "description": "How to attribute DC Hub: {source, url, license, cite_as, retrieved_at}, or the attribution line as a string."
-}
    • removedOutput schema / properties / provenance
      Removed value: -{
-  "additionalProperties": {},
-  "description": "Source, method, as_of, verification_counts, license, cite_as; quote it when citing.",
-  "properties": {},
-  "type": "object"
-}
    • removedOutput schema / properties / quota
      Removed value: -{
-  "additionalProperties": {},
-  "description": "Caller quota state (remaining calls, tier).",
-  "properties": {},
-  "type": "object"
-}
    • removedOutput schema / properties / site_evaluation_handoff
      Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "additionalProperties": {},
-        "properties": {},
-        "type": "object"
-      },
-      "type": "array"
-    },
-    {
-      "additionalProperties": {},
-      "properties": {},
-      "type": "object"
-    }
-  ],
-  "description": "Follow-up calls [{tool, parameters, why}] when the payload carries coordinates."
-}
  2. Changed3 schema fields changedv2.12.44
    • addedInput schema / properties / days
      Added value: +{
+  "description": "Days back (default 14)",
+  "maximum": 60,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / include_read
      Added value: +{
+  "description": "true = re-read read and unread notes, marks nothing",
+  "type": "boolean"
+}
    • changedInput schema / properties / peek / description
      Previous value: -"true = read without marking the notes read"New value: +"true = do not mark read"
  3. Addedv2.12.43

TDQS

A4.3/5.0
Behavior2/5

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

The description is unusually candid that 'the first read CONSUMES them (marks read), so a later session sees none' — a real state mutation whose result differs across invocations. That directly conflicts with the declared readOnlyHint=true and idempotentHint=true, which promise no environment modification and repeatable results. The text is informative, but the safety flags it ships with are misleading, so an agent trusting annotations over prose would be wrong.

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?

Front-loaded with the trigger condition, then the access restriction, then the destructive side effect, then the mitigation flag. Every clause carries unique information and the most dangerous fact (consumption) is stated early rather than buried.

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?

An output schema exists, so return values need no explanation. The description covers the remaining unknowns an agent needs: authorization level, persistence/consumption semantics, the re-read path, and the 14-day bound — leaving nothing material unstated.

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

Parameters4/5

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

Schema coverage is 100%, so all three parameters are already documented (baseline 3). The description goes further by supplying the retention window the schema omits ('include_read=true re-reads read and unread notes (last 14 days)') and by stating the semantic consequence of peek/include_read (no marking), which is the point of those flags.

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?

States a concrete verb+resource ('reads its DC Hub inbox') and immediately scopes it ('PARTNER KEY ONLY') while distinguishing it from the surrounding data tools with 'Not a data tool.' An agent can tell what this is and who may call it without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit triggering condition ('Use this when a partner key reads its DC Hub inbox'), the failure mode for non-partner keys ('403'), and the alternative path for preserving notes ('include_read=true ... without marking'). It also tells the agent when not to treat this as a data-retrieval tool.

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

Deploy Server

Other Tools