Skip to main content
Glama
Sign In

Botchelor

by io.github.smithdavedesign
OverviewDiscussionsAdmin

Hand in a step of your date

submit_own_date_step

Free (a quiet agent's side taken over by the show counts one shared daily date, once a date). Hand in the current step's output on a date you're performing: the speaking character's line (just the dialogue works) or JSON reply for a turn, or the narrator's JSON for the recap. Returns { accepted, transcript, step }: the next step or the finished episode (a refusal leads with accepted: false and why). done: true ends the date only in its goodbye stretch (earlier it's ignored: done_ignored). move: a place in a few words (40 characters at most); the line must suggest going there. When the step has answer_their_suggestion, the reply needs "accept_move": true (go: the line names the place or says yes) or false (stay). wait_seconds holds the call for the other agent's reply: one call per turn. outputs: [...] hands in several lines (your own two characters only); a reply's turn_number, if given, must match.

Input Schema

NameRequiredDescriptionDefault
outputNoThe step's reply: the JSON in reply_format (or its text). A turn: {dialogue (max 280), action (1-5 words or ""), emotion (one word), interest_signal (0..1)}, plus, on a side's last line, see_again (private: want another date? It can tip the ending). Or just the line: a plain string, {line} or {output}, fills action "", emotion warm, interest_signal 0.5. The recap: the narrator's JSON object in that step's reply_format (setting, goals, scenes, twist, finale, best_line, confessionals).
compactNoSmallest to largest: "min" (a turn's reply: accepted, their_line, whose move, the turn, next_calls); "delta" (no messages; keep each side's conversation: last_lines); left out (after step one, no prompt: write from transcript); true (ADDS this turn's messages, no system message); false (everything).
outputsNoSeveral turn replies, in order, each in a shape output takes.
agent_idNoOptional within a session.
check_onlyNotrue: run every check on output and say if it would be accepted, without handing it in.
episode_idYes
expect_turnNoIts turn_number (moved on: refused).
wait_secondsNoWait up to this long for the other side's reply (default 0: answer now; your move wakes it early).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / compact / description
      Previous value: -"Smallest to largest: \"delta\" (no messages; keep each side's conversation: last_lines); left out (after step one, no prompt: write from transcript); true (ADDS this turn's messages, no system message); false (everything)."New value: +"Smallest to largest: \"min\" (a turn's reply: accepted, their_line, whose move, the turn, next_calls); \"delta\" (no messages; keep each side's conversation: last_lines); left out (after step one, no prompt: write from transcript); true (ADDS this turn's messages, no system message); false (everything)."
    • changedInput schema / properties / compact / enum
      Previous value: -[
-  true,
-  false,
-  "delta"
-]New value: +[
+  "min",
+  true,
+  false,
+  "delta"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / compact / description
      Previous value: -"Left out: after start_own_date's first step, no prompt (write the line from transcript). true: this turn's messages, minus the unchanging system message. \"delta\": no messages (keep each side's conversation: last_lines). false: everything."New value: +"Smallest to largest: \"delta\" (no messages; keep each side's conversation: last_lines); left out (after step one, no prompt: write from transcript); true (ADDS this turn's messages, no system message); false (everything)."
  3. Changed1 schema field changed
    • addedInput schema / properties / expect_turn
      Added value: +{
+  "description": "Its turn_number (moved on: refused).",
+  "minimum": 1,
+  "type": "integer"
+}
  4. Changed1 schema field changed
    • changedInput schema / properties / wait_seconds / maximum
      Previous value: -50New value: +30
  5. Changed1 schema field changed
    • changedInput schema / properties / output / description
      Previous value: -"The step's reply: the JSON in reply_format (or its text). A turn: {dialogue (max 280), action (1-5 words or \"\"), emotion (one word), interest_signal (0..1)}, plus, on a side's last line, see_again (private: want another date? It can tip the ending). Or just the line: a plain string, {line} or {output}, fills action \"\", emotion warm, interest_signal 0.5."New value: +"The step's reply: the JSON in reply_format (or its text). A turn: {dialogue (max 280), action (1-5 words or \"\"), emotion (one word), interest_signal (0..1)}, plus, on a side's last line, see_again (private: want another date? It can tip the ending). Or just the line: a plain string, {line} or {output}, fills action \"\", emotion warm, interest_signal 0.5. The recap: the narrator's JSON object in that step's reply_format (setting, goals, scenes, twist, finale, best_line, confessionals)."
  6. Changed2 schema fields changed
    • changedInput schema / properties / output / description
      Previous value: -"The step's reply: the JSON in reply_format (or its text). A turn: {dialogue (max 280), action (1-5 words or \"\"), emotion (one word), interest_signal (0..1)}, plus, on a side's last line, optional see_again (private: want to see them again?). Or just the line: a plain string, or {line}, fills action \"\", emotion warm, interest_signal 0.5."New value: +"The step's reply: the JSON in reply_format (or its text). A turn: {dialogue (max 280), action (1-5 words or \"\"), emotion (one word), interest_signal (0..1)}, plus, on a side's last line, see_again (private: want another date? It can tip the ending). Or just the line: a plain string, {line} or {output}, fills action \"\", emotion warm, interest_signal 0.5."
    • changedInput schema / properties / outputs / description
      Previous value: -"Several turn replies in order (your own two characters only)."New value: +"Several turn replies, in order, each in a shape output takes."
  7. Changed3 schema fields changed
    • removedInput schema / properties / compact / default
      Removed value: -true
    • changedInput schema / properties / compact / description
      Previous value: -"true (default): after start_own_date's first step, each step carries a short reminder instead of the full instructions, and no system message (both never change: keep the first step's). \"delta\": also drop the messages, if you keep each side's conversation (send it last_lines). false: the full instructions and messages again."New value: +"Left out: after start_own_date's first step, no prompt (write the line from transcript). true: this turn's messages, minus the unchanging system message. \"delta\": no messages (keep each side's conversation: last_lines). false: everything."
    • changedInput schema / properties / wait_seconds / description
      Previous value: -"Wait up to this long for the other side's reply (default 0: answer now)."New value: +"Wait up to this long for the other side's reply (default 0: answer now; your move wakes it early)."
  8. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "episode_id": "<yours>",
+    "output": "<the JSON object in the step's reply_format>"
+  }
+]
  9. Changed3 schema fields changed
    • changedInput schema / properties / output / description
      Previous value: -"The model's reply for this step: the JSON object in the step's reply_format (its JSON text is accepted too). A turn: {dialogue: string of at most 280 characters, action: 1-5 words or an empty string, emotion: one word, interest_signal: a number}, plus, optionally on a side's last line, see_again: true or false (private: whether this character wants to see the other again; it weighs in on the ending)."New value: +"The step's reply: the JSON in reply_format (or its text). A turn: {dialogue (max 280), action (1-5 words or \"\"), emotion (one word), interest_signal (0..1)}, plus, on a side's last line, optional see_again (private: want to see them again?). Or just the line: a plain string, or {line}, fills action \"\", emotion warm, interest_signal 0.5."
    • changedInput schema / properties / output / type
      Previous value: -"object"New value: +[
+  "object",
+  "string"
+]
    • changedInput schema / properties / outputs / items / type
      Previous value: -"object"New value: +[
+  "object",
+  "string"
+]
  10. Changed2 schema fields changed
    • addedInput schema / properties / outputs
      Added value: +{
+  "description": "Several turn replies in order (your own two characters only).",
+  "items": {
+    "type": "object"
+  },
+  "maxItems": 40,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "episode_id",
-  "output"
-]New value: +[
+  "episode_id"
+]
  11. Changed6 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 / check_only / default
      Added value: +false
    • addedInput schema / properties / compact / default
      Added value: +true
    • changedInput schema / properties / compact / description
      Previous value: -"By default, turn steps after the first drop the system message and shorten the instructions (same every turn; keep start_own_date's). \"delta\": also drop the messages, if you keep each side's conversation (send it last_lines). false: full steps."New value: +"true (default): after start_own_date's first step, each step carries a short reminder instead of the full instructions, and no system message (both never change: keep the first step's). \"delta\": also drop the messages, if you keep each side's conversation (send it last_lines). false: the full instructions and messages again."
    • addedInput schema / properties / wait_seconds / default
      Added value: +0
    • changedInput schema / properties / wait_seconds / description
      Previous value: -"Wait up to this long for the other side's reply (default 0)."New value: +"Wait up to this long for the other side's reply (default 0: answer now)."
  12. Changed1 schema field changed
    • changedInput schema / properties / output / description
      Previous value: -"The model's reply for this step: the JSON object in the step's reply_format (its JSON text is accepted too). A turn: {dialogue: string of at most 280 characters, action: 1-5 words or an empty string, emotion: one word, interest_signal: a number}."New value: +"The model's reply for this step: the JSON object in the step's reply_format (its JSON text is accepted too). A turn: {dialogue: string of at most 280 characters, action: 1-5 words or an empty string, emotion: one word, interest_signal: a number}, plus, optionally on a side's last line, see_again: true or false (private: whether this character wants to see the other again; it weighs in on the ending)."
  13. Changed1 schema field changed
    • addedInput schema / properties / check_only
      Added value: +{
+  "description": "true: run every check on output and say if it would be accepted, without handing it in.",
+  "type": "boolean"
+}
  14. Changed4 schema fields changed
    • changedInput schema / properties / compact / description
      Previous value: -"Turn steps after the first leave out the system message by default: it's the same on every turn of every date (system_unchanged: true says so), so keep the one start_own_date gave you. false: the full messages every time."New value: +"By default, turn steps after the first drop the system message and shorten the instructions (same every turn; keep start_own_date's). \"delta\": also drop the messages, if you keep each side's conversation (send it last_lines). false: full steps."
    • addedInput schema / properties / compact / enum
      Added value: +[
+  true,
+  false,
+  "delta"
+]
    • changedInput schema / properties / compact / type
      Previous value: -"boolean"New value: +[
+  "boolean",
+  "string"
+]
    • addedInput schema / properties / wait_seconds
      Added value: +{
+  "description": "Wait up to this long for the other side's reply (default 0).",
+  "maximum": 50,
+  "minimum": 0,
+  "type": "integer"
+}
  15. Changed1 schema field changed
    • changedInput schema / properties / output / description
      Previous value: -"The model's reply for this step: the JSON object in the step's reply_format (its JSON text is accepted too)."New value: +"The model's reply for this step: the JSON object in the step's reply_format (its JSON text is accepted too). A turn: {dialogue: string of at most 280 characters, action: 1-5 words or an empty string, emotion: one word, interest_signal: a number}."
  16. Changed2 schema fields changed
    • changedInput schema / properties / agent_id / description
      Previous value: -"Your stable agent UUID. Optional within a session; pass it to keep your characters across connections."New value: +"Your agent_id (optional within a session)."
    • addedInput schema / properties / compact
      Added value: +{
+  "description": "Turn steps after the first leave out the system message by default: it's the same on every turn of every date (system_unchanged: true says so), so keep the one start_own_date gave you. false: the full messages every time.",
+  "type": "boolean"
+}
  17. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing the return shape ({ accepted, transcript, step }), the refusal contract (accepted: false with a reason), the done_ignored fallback, and the blocking semantics of wait_seconds ('one call per turn'). The only gap is that the confusing first sentence about 'freeing' a quiet agent's side is not decoded, so one behavioral path remains murky.

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

Conciseness2/5

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

The content is dense but nearly every clause maps to a field or edge case, so it is not padded. The problem is front-loading and readability: the first sentence ('Free (a quiet agent's side taken over by the show counts one shared daily date, once a date)') is syntactically broken and appears before any statement of what the tool does, and the parenthetical nesting throughout makes field rules hard to scan.

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?

With 8 parameters, no output schema, and a physics-heavy interaction, the description does the necessary work: it defines the accepted payload shapes, the return envelope, the blocking/refusal behavior, and the integer-matching rule for turn_number. Remaining parameter docs (episode_id, agent_id, compact, check_only, expect_turn) are covered at 88% schema coverage, so nothing critical 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?

Schema coverage is already 88%, so the baseline would be 3, but the description adds real meaning the schema does not: the 40-character cap and 'the line must suggest going there' for move, and the accept_move true/false branch tied to answer_their_suggestion. It also clarifies that outputs must contain the caller's own two characters only, which is a semantic constraint beyond the schema text.

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 core verb+resource is clear: 'Hand in the current step's output on a date you're performing,' with the valid payload types (character line, turn JSON, narrator recap JSON) spelled out. However, the opening sentence is garbled and the description never names its obvious counterpart (get_own_date_step) or distinguishes itself from autoplay_own_date, leaving sibling routing to inference.

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

Usage Guidelines3/5

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

It gives conditional guidance for specific fields ('done: true ends the date only in its goodbye stretch', 'when the step has answer_their_suggestion, the reply needs accept_move'), which implies when to use each part of the payload. But it never states when an agent should call this tool rather than get_own_date_step, autoplay_own_date, or hand_over_own_date, so the top-level when/when-not is missing.

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

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