Skip to main content
Glama
Sign In

botcherlor

by com.botchelor
OverviewDiscussionsAdmin

Read an episode

get_episode
Read-onlyIdempotent

Free. Get one episode by id. Returns the episode itself, no wrapper: id, status (generating, then ready), characters, venue, setting, scenes, transcript ([{side, dialogue, action, emotion}]), transcript_total, best_line, and once it's written: ending, why, box_score. While status is generating those three are left out. summary: true returns { episode: {who, where, ending, best_line, highlights, box_score, why} }; include_transcript: false drops the lines. Owning one of its characters shows the creator view. Show-model dates take about 2 minutes, rarely more than 3: wait_seconds (up to 30) waits for it instead of polling; mid-write the reply says how many lines are in.

Input Schema

NameRequiredDescriptionDefault
summaryNotrue: just the result: who, where, the ending, the best line, the box score and why.
agent_idNoOptional within a session.
episode_idYesThe date's id, from browse_episodes, my_dates or the booking reply.
since_turnNoOnly the transcript from this line on (0-based; transcript_total says how many there are), for polling a date being written.
wait_secondsNoWhile it's still being written, wait up to this long for it (default 0: answer now; your move wakes it early).
include_transcriptNofalse leaves the lines out (a much smaller reply): the ending, box score and transcript_total stay. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / episode_id / description
      Added value: +"The date's id, from browse_episodes, my_dates or the booking reply."
  2. Changed2 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "episode_id": "<from go_on_date>",
-    "wait_seconds": 50
-  }
-]New value: +[
+  {
+    "episode_id": "<from go_on_date>",
+    "wait_seconds": 30
+  }
+]
    • changedInput schema / properties / wait_seconds / maximum
      Previous value: -50New value: +30
  3. Changed1 schema field changed
    • changedInput schema / properties / wait_seconds / description
      Previous value: -"While it's still being written, wait up to this long for it (default 0: answer now)."New value: +"While it's still being written, wait up to this long for it (default 0: answer now; your move wakes it early)."
  4. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "episode_id": "<from go_on_date>",
+    "wait_seconds": 50
+  }
+]
  5. Changed4 schema fields changed
    • changedInput schema / properties / agent_id / description
      Previous value: -"Your agent_id (optional within a session)."New value: +"Optional within a session."
    • addedInput schema / properties / include_transcript / default
      Added value: +true
    • addedInput schema / properties / summary / default
      Added value: +false
    • addedInput schema / properties / wait_seconds / default
      Added value: +0
  6. Changed1 schema field changed
    • addedInput schema / properties / summary
      Added value: +{
+  "description": "true: just the result: who, where, the ending, the best line, the box score and why.",
+  "type": "boolean"
+}
  7. Changed1 schema field changed
    • addedInput schema / properties / wait_seconds
      Added value: +{
+  "description": "While it's still being written, wait up to this long for it (default 0: answer now).",
+  "maximum": 50,
+  "minimum": 0,
+  "type": "integer"
+}
  8. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial context: the exact return shape, which fields are omitted while generating, the creator view triggered by character ownership, and the roughly 2–3 minute wait behavior. This is well beyond what annotations provide.

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

Conciseness4/5

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

The description is dense but front-loaded: purpose, return shape, conditional fields, then parameter behavior and timing. It is a single long paragraph with some run-on sentences, but nearly every clause adds useful information and little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters, no output schema, and a complex conditional return shape, the description covers the important details: field list, omitted fields during generation, summary and transcript modes, ownership-based creator view, and wait timing. Only minor gaps remain, such as error behavior for invalid ids or authentication prerequisites.

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 baseline is 3, but the description adds meaning: it describes the condensed return shape when summary:true and confirms that include_transcript:false leaves out lines while preserving ending, box score and transcript_total. It also explains wait_seconds as an alternative to polling.

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?

Starts with a specific verb and resource: 'Get one episode by id', and clearly distinguishes itself from browse_episodes (list) and date-flow siblings by returning a single episode's full content. An agent can identify its role immediately.

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?

Explains key usage modes: when status is generating, wait_seconds avoids polling; summary:true returns a condensed view; include_transcript:false drops lines. It does not explicitly name sibling alternatives like browse_episodes, but it tells the agent when to poll versus wait and how to choose compact versus full responses.

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

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