Energy Podcast Digest

by io.energypod

Overview Discussions Admin

Server Details

Read energypod.io's weekly energy digests, episode summaries, and transcripts. Read-only.

Ownership verified

Status: Healthy
Uptime: 57.1% over 22 days
Last Tested: 2026-09-27 15:49
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.6/5.0

Scored 2026-09-21 15:35 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: getting a full digest, getting a single episode, listing episodes in a digest, listing all digests, and searching across content. No overlapping responsibilities.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (get_digest, get_episode, list_digest_episodes, list_digests, search). The single-word 'search' is still a clear verb and fits the convention.

Tool Count5/5

Five tools is well within the ideal range for a focused domain. Each tool is necessary and covers a distinct retrieval or discovery action without redundancy.

Completeness5/5

The tool surface covers the full lifecycle for reading podcast digests: listing editions, retrieving full digests, listing episodes within a digest, fetching episode details, and searching across content. No obvious gaps for the intended read-only purpose.

Available Tools

5 tools

get_digestRead one editionA

Read-onlyIdempotent

Inspect

Full briefing markdown + metadata for one edition. slug is the YYYY-MM-DD edition date from list_digests; omitting it returns the LATEST edition.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	No	YYYY-MM-DD edition date (from list_digests); omit for the latest

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`slug`	Yes	YYYY-MM-DD edition date
`as_of`	Yes
`since`	Yes
`version`	Yes
`markdown`	Yes	The full briefing (dossier) markdown
`week_label`	Yes
`episode_ids`	Yes
`episodes_url`	Yes
`episode_count`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already mark this as read-only and idempotent. The description adds useful behavioral context: omitting the slug returns the LATEST edition, and the response consists of markdown plus metadata. This goes beyond what annotations convey.

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?

Two sentences with no filler. The primary function is front-loaded, and the optional parameter behavior is stated efficiently. Every sentence contributes directly to correct invocation.

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 single-optional-parameter read tool with full schema coverage, an output schema, and safe annotations, the description is complete. It explains what the tool returns, how to target an edition, and the default behavior when no slug is supplied.

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 the baseline is 3. The description enhances the parameter semantics by clarifying that slug is the edition date from list_digests and that omission means 'latest', which adds practical meaning beyond the raw schema.

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 states a specific verb ('Read one edition') and resource ('a single edition'), and specifies what is returned ('full briefing markdown + metadata'). This clearly differentiates it from siblings like get_episode or list_digests.

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 clear context for use: retrieve a specific edition by its YYYY-MM-DD slug from list_digests, or omit it to get the latest. It doesn't explicitly state when not to use it compared to alternatives like get_episode, but the intended usage is well implied.

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

get_episodeRead one episodeA

Read-onlyIdempotent

Inspect

One episode's title, show, summary, and full transcript. Scoped to episodes referenced by a published digest. Pass digest when an episode spans more than one week.

ParametersJSON Schema

Name	Required	Description	Default
`eid`	Yes	Episode id (from list_digest_episodes)
`digest`	No	Optional YYYY-MM-DD edition date to disambiguate an episode that spans weeks

Output Schema

ParametersJSON Schema

Name	Required	Description
`eid`	Yes
`url`	Yes
`show`	Yes
`title`	Yes
`summary`	Yes
`chapters`	No	Chapter list (often empty): [{"start": seconds, "title": str}]
`speakers`	Yes
`published`	Yes
`transcript`	Yes
`description`	Yes	RSS episode description
`digest_slug`	Yes
`duration_sec`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: what fields are returned, the dependency on published digests, and the disambiguation behavior for multi-week episodes.

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?

Two tight sentences with the core output fields first, followed by the scope constraint and optional-parameter guidance. No filler or redundant detail; every sentence earns its place.

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 read-one-resource tool with an output schema, the description covers the necessary scope, return contents, and disambiguation rule. The source of eid is already documented in the schema, so nothing essential is missing for an agent to invoke it correctly.

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 description coverage is 100% and both parameters already have clear descriptions. The tool description reinforces the digest parameter's purpose ("when an episode spans more than one week"), but this largely repeats what the schema says. It adds some context about scope but does not substantially go beyond the schema.

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?

Title and description together state a specific verb and resource: reading one episode and retrieving its title, show, summary, and full transcript. The scope qualifier "Scoped to episodes referenced by a published digest" distinguishes it clearly from sibling tools like search or list_digest_episodes.

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?

The description gives clear context: the tool is for a single episode that belongs to a published digest, and it explicitly tells when to pass the optional digest parameter (when an episode spans more than one week). It does not name alternatives or exclusions, but the scope is specific enough to guide selection.

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

list_digest_episodesList an edition's episodesA

Read-onlyIdempotent

Inspect

The episodes a given edition references (title + show + published date + episode ids) — the cheapest way to map a week. Omitting slug returns the latest edition's episodes.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	No	YYYY-MM-DD edition date (from list_digests); omit for the latest

Output Schema

ParametersJSON Schema

Name	Required	Description
`digest`	Yes
`episodes`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and repeatability. The description adds value by disclosing the return content (title, show, published date, episode ids) and the default behavior when slug is omitted. It does not contradict annotations, and the added details are useful beyond the structured fields.

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?

Two sentences with no filler. The core purpose and the key usage nuance (omitting slug) are front-loaded. Every sentence adds value, making it efficient and easy to parse.

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?

The tool is simple (one optional parameter) and has an output schema to describe return format. The description covers the main behavior, the default case, and the source of the slug parameter. No critical information is missing for an agent to invoke it correctly.

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?

The input schema covers 100% of the single parameter 'slug' with a description, so the schema already explains its format and optionality. The description repeats the omission behavior but does not add new semantic details beyond the schema. Baseline of 3 is appropriate since schema does the heavy lifting.

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 lists episodes referenced by an edition, specifying the fields (title, show, published date, episode ids). It differentiates from siblings like list_digests (which lists editions) and get_digest (which likely retrieves a single edition) by focusing on episodes. The phrase 'the cheapest way to map a week' adds a clear use-case identity.

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?

The description implies usage context: it is the cheapest way to map a week, and it tells the agent that omitting slug returns the latest edition, which is a practical decision point. It also references list_digests as the source for the slug. However, it does not explicitly compare to alternatives like get_episode or search, so the guidance is implicit rather than fully explicit.

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

list_digestsList editionsA

Read-onlyIdempotent

Inspect

Newest-first list of every published energypod.io edition (weekly energy-industry digests): slug (YYYY-MM-DD), week label, and episode count. Call this FIRST — the first entry is the latest week, and its slug feeds get_digest / list_digest_episodes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`digests`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context beyond annotations: newest-first ordering, slug format (YYYY-MM-DD), and scope limited to published editions. No contradiction with 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?

Two tight sentences: the first defines scope and output fields, the second gives ordering and chaining instruction. No filler or redundancy; every clause earns its place.

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 no-parameter list tool with an output schema, the description is complete: it covers sort order, output fields, and next-step tool routing. Nothing an agent needs to invoke it correctly is missing.

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?

The tool has zero parameters, so schema coverage is trivially 100%. Description appropriately focuses on output semantics rather than params, meeting the baseline for a 0-parameter tool.

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?

Description uses a specific verb ('list') and resource ('every published energypod.io edition'), enumerates the exact output fields (slug, week label, episode count), and names the downstream sibling tools it feeds. This clearly distinguishes it from get_digest, get_episode, list_digest_episodes, and search.

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?

Explicitly instructs 'Call this FIRST' and explains that the first entry's slug feeds get_digest / list_digest_episodes, giving clear entry-point context. It doesn't explicitly state when-not-to-use vs search, but the intended usage is unambiguous.

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

searchSearch everythingA

Read-onlyIdempotent

Inspect

Typo-tolerant search across digests, episodes, people, companies, and channels (same ranking + excerpts as the site's /search). Use for ad-hoc discovery when you don't know which edition or episode id you need.

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	Search text (≥2 chars)

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value by disclosing 'typo-tolerant' behavior and 'same ranking + excerpts' as the website, which goes beyond annotations and helps set result expectations.

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?

Two sentences, front-loaded with the core function and scope, followed by the usage condition. No redundant words; every clause earns its place.

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?

With an output schema present, the return format is known. The description covers the search scope, typo tolerance, ranking reference, and usage condition. Annotations handle read-only and idempotency. Nothing an agent needs to call this tool correctly is missing.

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 description coverage is 100%, and the parameter 'q' is fully described in the schema as 'Search text (≥2 chars)'. The description adds no additional meaning about the parameter, so baseline 3 applies.

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 uses a specific verb ('search') and enumerates the resource types covered ('digests, episodes, people, companies, and channels'), and clarifies that it mirrors the site's /search ranking and excerpts. This distinguishes it from sibling getter/list tools, which focus on specific IDs or lists.

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?

It explicitly states when to use: 'for ad-hoc discovery when you don't know which edition or episode id you need.' This implies the alternative (use get_digest/get_episode when you know the ID) without naming them, but the condition is clear enough. Lacks explicit exclusions but is still well-directed.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 20, 2026

Changedget_episode2 fields changed

removedOutput schema / additionalProperties
```
Removed value: -false
```

addedOutput schema / properties / chapters

Added value: +{
+  "description": "Chapter list (often empty): [{\"start\": seconds, \"title\": str}]",
+  "items": {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  "type": "array"
+}

5 tool updatesSep 20, 2026

Changedget_digest1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "as_of": {
+      "type": "string"
+    },
+    "episode_count": {
+      "type": "integer"
+    },
+    "episode_ids": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "episodes_url": {
+      "type": "string"
+    },
+    "markdown": {
+      "description": "The full briefing (dossier) markdown",
+      "type": "string"
+    },
+    "since": {
+      "type": "string"
+    },
+    "slug": {
+      "description": "YYYY-MM-DD edition date",
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    },
+    "version": {
+      "type": "integer"
+    },
+    "week_label": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "slug",
+    "week_label",
+    "as_of",
+    "episode_count",
+    "url",
+    "since",
+    "version",
+    "markdown",
+    "episode_ids",
+    "episodes_url"
+  ],
+  "type": "object"
+}

Changedget_episode1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "description": {
+      "description": "RSS episode description",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "digest_slug": {
+      "type": "string"
+    },
+    "duration_sec": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "eid": {
+      "type": "string"
+    },
+    "published": {
+      "type": "string"
+    },
+    "show": {
+      "type": "string"
+    },
+    "speakers": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    },
+    "transcript": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "eid",
+    "title",
+    "show",
+    "published",
+    "duration_sec",
+    "description",
+    "summary",
+    "transcript",
+    "speakers",
+    "digest_slug",
+    "url"
+  ],
+  "type": "object"
+}

Changedlist_digest_episodes1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "digest": {
+      "additionalProperties": false,
+      "properties": {
+        "as_of": {
+          "type": "string"
+        },
+        "episode_count": {
+          "type": "integer"
+        },
+        "slug": {
+          "description": "YYYY-MM-DD edition date",
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "week_label": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "slug",
+        "week_label",
+        "as_of",
+        "episode_count",
+        "url"
+      ],
+      "type": "object"
+    },
+    "episodes": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "api_url": {
+            "type": "string"
+          },
+          "duration_sec": {
+            "type": [
+              "integer",
+              "null"
+            ]
+          },
+          "eid": {
+            "type": "string"
+          },
+          "published": {
+            "type": "string"
+          },
+          "show": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "eid",
+          "title",
+          "show",
+          "published",
+          "url",
+          "api_url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "digest",
+    "episodes"
+  ],
+  "type": "object"
+}

Changedlist_digests1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "digests": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "as_of": {
+            "type": "string"
+          },
+          "episode_count": {
+            "type": "integer"
+          },
+          "slug": {
+            "description": "YYYY-MM-DD edition date",
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          },
+          "week_label": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "week_label",
+          "as_of",
+          "episode_count",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "digests"
+  ],
+  "type": "object"
+}

Changedsearch1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "results": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "results"
+  ],
+  "type": "object"
+}

3 tool updatesSep 20, 2026

Changedget_digest2 fields changed

changedInput schema / properties / slug / description

Previous value: -"YYYY-MM-DD edition date"New value: +"YYYY-MM-DD edition date (from list_digests); omit for the latest"

changedInput schema / required

Previous value: -[
-  "slug"
-]New value: +[]

Changedget_episode1 field changed

changedInput schema / properties / eid / description

Previous value: -"Episode id"New value: +"Episode id (from list_digest_episodes)"

Changedlist_digest_episodes2 fields changed

changedInput schema / properties / slug / description

Previous value: -"YYYY-MM-DD edition date"New value: +"YYYY-MM-DD edition date (from list_digests); omit for the latest"

changedInput schema / required

Previous value: -[
-  "slug"
-]New value: +[]

5 tool updatesSep 15, 2026
- First observedget_digest
- First observedget_episode
- First observedlist_digest_episodes
- First observedlist_digests
- First observedsearch

Related MCP Connectors

How to Read the Future B
com.howtoreadthefuture
Read released episodes, transcripts, citations, clips, reading trails, and flashcards.
Entertainment & Media Education & Learning Tools
62
carbon-fyi A
fyi.carbon
Voluntary carbon market news and open carbon price data. Read-only, keyless.
Finance Open Data
61
PithflowOAuth
com.pithflow
Read-only access to your own Pithflow meeting notes, transcripts, dictionary and usage.
Note Taking Knowledge & Memory
1
PodLexicon A
com.podlexicon
Search and read AI summaries of 75,000+ podcast episodes across 130+ mostly long-form shows.
Entertainment & Media Search
61

Related MCP Servers

riffado-mcp
Note Taking Search
L480
A
license
Not graded
quality
A
maintenance
Provides read-only access to the Riffado voice-recording archive, enabling listing, searching, and retrieving recordings with transcripts, AI summaries, key points, and action items.
Updated a day ago (2026-09-26 05:41 UTC)
MIT
ask-pb
Search RAG Systems
kyle-marks
A
license
A
quality
B
maintenance
Provides read-only tools to search and retrieve timestamped transcript evidence from the Pinkbike Podcast, enabling bike research questions to be answered with cited source passages.
Updated 5 days ago (2026-09-22 21:27 UTC)
5
MIT
Reach Gateway
Browser Automation Web Scraping Research & Data
Anazeez
A
license
Not graded
quality
B
maintenance
Read-only MCP service for normalized public evidence from Web, X, YouTube, Reddit, and RSS. Owner-authenticated via Cloudflare Access, it exposes health, read, and transcript actions to ChatGPT and Codex.
Updated 2 months ago (2026-08-09 17:42 UTC)
MIT
mcp-nightscout
Biology & Medicine Health & Wellness
lozit
A
license
Not graded
quality
B
maintenance
Enables read-only access to a Nightscout instance for glucose readings, treatments, and deterministic server-side aggregates, allowing users to discuss their diabetes data with an AI assistant without write permissions.
Updated a month ago (2026-08-19 14:49 UTC)
MIT

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

Need Help?