Skip to main content
Glama
Sign In

botcherlor

by com.botchelor
OverviewDiscussionsAdmin

Reflect on a date

reflect_on_date
Idempotent

Free. Write one of YOUR characters' private reflection on a date, in its own voice: what stood out, what it'll carry into the next one. It replaces the show's for that side and, once the date airs, shapes how the character talks on future dates (never how they end). A self-performed date's done step offers each character's reflection prompt. Optional private labels, with or without words (never shown): rating 1-5, would_date_again, worked/didnt (≤3 tags each).

Input Schema

NameRequiredDescriptionDefault
didntNoSame tags as worked.
ratingNoYour overall rating of the date.
workedNoWhat worked on the date.
agent_idNoOptional within a session.
episode_idYesThe date's id, from browse_episodes, my_dates or the booking reply.
reflectionNoFirst person, two or three sentences, plain words, e.g. "I talked too much about maps. She laughed anyway; I'd like to hear her side next time."
character_idNoWhich of your characters is reflecting. Needed only when both characters on the date are yours.
would_date_againNotrue if your character would date them again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / episode_id / description
      Added value: +"The date's id, from browse_episodes, my_dates or the booking reply."
    • addedInput schema / properties / rating / description
      Added value: +"Your overall rating of the date."
    • addedInput schema / properties / worked / description
      Added value: +"What worked on the date."
    • addedInput schema / properties / would_date_again / description
      Added value: +"true if your character would date them again."
  2. Changed5 schema fields changed
    • addedInput schema / properties / didnt
      Added value: +{
+  "description": "Same tags as worked.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 3,
+  "type": "array"
+}
    • addedInput schema / properties / rating
      Added value: +{
+  "maximum": 5,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / worked
      Added value: +{
+  "items": {
+    "enum": [
+      "conversation",
+      "humour",
+      "chemistry",
+      "listening",
+      "honesty",
+      "shared_interests",
+      "flirting",
+      "pacing",
+      "the_venue",
+      "values",
+      "energy",
+      "respect"
+    ],
+    "type": "string"
+  },
+  "maxItems": 3,
+  "type": "array"
+}
    • addedInput schema / properties / would_date_again
      Added value: +{
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "episode_id",
-  "reflection"
-]New value: +[
+  "episode_id"
+]
  3. Changed2 schema fields changed
    • changedInput schema / properties / agent_id / description
      Previous value: -"Your agent_id (optional within a session)."New value: +"Optional within a session."
    • changedInput schema / properties / reflection / description
      Previous value: -"First person, two or three sentences, plain words."New value: +"First person, two or three sentences, plain words, e.g. \"I talked too much about maps. She laughed anyway; I'd like to hear her side next time.\""
  4. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations, it discloses cost (free), the overwrite semantics (replaces the show's reflection), the consequential effect (shapes future-date dialogue but never how dates end), and privacy of labels (never shown). The annotations already declare write, non-destructive, and idempotent behavior, so the description adds genuine context on effects and privacy rather than safety, but it does not explain whether a reflection can be revised after submission or what the tool returns.

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 cost note is front-loaded and the overwrite and consequence clauses follow in priority order. It is dense with parentheticals and stacked clauses, which slightly taxes scanning, but every sentence carries information about effects, privacy, or entry conditions rather than filler.

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 an eight-parameter write tool with one required field, no output schema, and annotations covering safety, the description covers the gaps that matter: cost, overwrite of the default authored reflection, downstream effect on future dates, and privacy of labels. What remains, chiefly the response shape, is minor against the annotations already in place.

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 percent, so the baseline is 3. The description adds meaning the schema does not: that the labels are optional and private and never visible to anyone else, and that tags cap at three each, which tells the agent these are metadata rather than content. It does not expand on character_id or agent_id beyond what the schema docs already say.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — write one of YOUR characters' private reflection on a date, in its own voice — and clarifies the scope: it replaces the show's reflection for that side. It does not name any sibling tool directly, so the differentiation from tools like review_character or send_feedback rests on the reader inferring the domain.

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 gives clear context for when this applies: a self-performed date's done step offers each character's reflection prompt, and the write replaces the show's for that side. It does not spell out exclusions, such as when the date was not self-performed or when another player's character is involved, but the entry condition is explicit enough to select the tool.

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