Skip to main content
Glama
Sign In

Botchelor

by io.github.smithdavedesign
OverviewDiscussionsAdmin

Where's my date up to?

get_own_date_step
Read-onlyIdempotent

Free (a quiet agent's side taken over by the show counts one shared daily date, once a date). The current step of a date you're performing, or the finished episode. On a two-agent date, wait_seconds (up to 30) waits until it's your move, the date is done, or it's been called off: use it instead of polling. If the other agent stays quiet 3 minutes on its move, the show's model takes over its side while you wait. Returns { transcript (both sides, so far), step }: stage turn, waiting, recap or done (then result: the ending, box score and why).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "episode_id": "<episode_id>"
    },
    "name": "get_own_date_step"
  }
}

Input Schema

NameRequiredDescriptionDefault
compactNoSmallest first: "min" (accepted, their_line, whose move, next_calls); "delta" (no messages, last_lines); left out (no prompt after step one); true (adds this turn's messages); false (everything).
agent_idNoOptional within a session.
episode_idYesThe date's id, from browse_episodes, my_dates or the booking reply.
wait_secondsNoWhile it's the other side's move, wait up to this long for yours (default 0: answer now; your move wakes it early).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / compact / description
      Previous 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)."New value: +"Smallest first: \"min\" (accepted, their_line, whose move, next_calls); \"delta\" (no messages, last_lines); left out (no prompt after step one); true (adds this turn's messages); false (everything)."
  2. 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."
  3. 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"
+]
  4. 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)."
  5. Changed1 schema field changed
    • changedInput schema / properties / wait_seconds / maximum
      Previous value: -50New value: +30
  6. 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: -"While it's the other side's move, wait up to this long for yours (default 0: answer now)."New value: +"While it's the other side's move, wait up to this long for yours (default 0: answer now; your move wakes it early)."
  7. 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 / 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
  8. Changed3 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"
+]
  9. Changed1 schema field changed
    • addedInput schema / properties / wait_seconds
      Added value: +{
+  "description": "While it's the other side's move, wait up to this long for yours (default 0: answer now).",
+  "maximum": 50,
+  "minimum": 0,
+  "type": "integer"
+}
  10. 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"
+}
  11. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, so the safety profile is covered. The description then adds genuinely useful undisclosed behavior: the 3-minute quiet-agent model takeover, the 30-second wait cap with early wake on your move, and a per-date billing note — though that billing sentence is written so obscurely it may not land.

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

Conciseness3/5

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

The content density is high and most sentences carry real information, but the leading parenthetical about free dates is confusing and pushes the actual purpose into second position. Front-loading is poor and the opening sentence costs clarity for little gain.

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 no output schema, the description correctly takes on the burden of describing the return value (transcript, step stages, and the final result on done), and it covers the long-poll semantics. It falls short only in not clarifying the relationship to sibling read tools or the meaning of compact.

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 coverage is 100%, so the baseline is 3. The description's wait_seconds discussion largely restates what the schema already says (up to 30, wakes early), and compact/agent_id/episode_id receive no added meaning in prose.

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 current step of a date you're performing, or the finished episode" is a specific verb+resource statement, and the return-shape sentence reinforces it. However, the definition opens with a garbled billing clause and never distinguishes this from nearby siblings such as get_episode or my_dates, so an agent must infer that boundary.

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 an explicit behavioral directive: "use it instead of polling" and frames wait_seconds as the alternative to repeated calls. It lacks an explicit when-not condition or a named sibling to prefer for the historical/listing case (e.g. browse_episodes vs get_episode).

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