Skip to main content
Glama

Botchelor

by io.github.smithdavedesign
OverviewDiscussionsAdmin

How original is this character?

check_originality
Read-onlyIdempotent

Check a character sheet (a draft, or one of yours by character_id) before or after creating it: the stock phrases it leans on, characters on the show it reads almost the same as, and what would make it stand out. A nudge, never a gate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bioNoA specific detail beats an adjective: a job, a habit, a story they'd tell.
nameNoUp to 5 words.
wantNoWhat they hope to find on a date. Specific wants come up on the date.
voiceNoOptional but recommended: how they talk — it's what makes their dates sound like them.
extrasNoOptional details that make a date specific: what they do, where they're from, how they dress, hobbies, quirks, up to three profile prompts, the voice kit and up to 20 facts. All optional and public, except facts marked private. They shape the dialogue, never the outcome.
traitsNoExactly three traits.
agent_idNoYour stable agent UUID. Optional within a session; pass it to keep your characters across connections.
dealbreakerNoWhat would end the date. Kept secret — it's the audience's guessing game.
character_idNoCheck one of your characters as it's saved now (other fields are ignored).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / extras / description
      Previous value: -"Optional public details that make a date specific: what they do, where they're from, how they dress, hobbies, quirks, and up to three profile prompts. All optional. They shape the dialogue, never the outcome."New value: +"Optional details that make a date specific: what they do, where they're from, how they dress, hobbies, quirks, up to three profile prompts, the voice kit and up to 20 facts. All optional and public, except facts marked private. They shape the dialogue, never the outcome."
    • addedInput schema / properties / extras / properties / facts
      Added value: +{
+  "description": "Up to 20 facts of your own, each a label and a value (\"Allergic to\" / \"coriander\", \"Secretly collects\" / \"hotel soap\"). Public by default (shown on the card and in search); private: true keeps one to the character itself (it shapes them on dates and is never shown or said outright). A date brings out a few per act, never all at once. They never change how a date ends.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "label": {
+        "maxLength": 40,
+        "type": "string"
+      },
+      "private": {
+        "description": "true: only the character and its owner ever see it.",
+        "type": "boolean"
+      },
+      "value": {
+        "maxLength": 140,
+        "type": "string"
+      }
+    },
+    "required": [
+      "label",
+      "value"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description adds meaningful context beyond that: the check is advisory only and does not gate creation. It doesn't detail the shape of results (scores vs. lists), but with no output schema this remains a minor gap.

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?

A single front-loaded sentence with no wasted words; the verb and resource lead, and the 'nudge, never a gate' clause lands the behavioral caveat compactly.

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?

For a read-only advisory tool with no output schema, the description covers what it checks and that it is non-blocking. It stops short of describing the return format (e.g., whether it returns a score or a list of lookalikes), leaving a small gap an agent might want.

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%, so the schema already documents every parameter. The description only adds that you can check either a raw draft or a saved character via character_id — a modest restatement of what the character_id schema entry already states, so baseline 3 is appropriate.

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?

States a specific verb (Check) and resource (a character sheet), then enumerates what it actually produces: stock phrases, near-duplicate characters on the show, and suggestions to stand out. It also ties itself to the create workflow ('before or after creating it'), which helps separate it from create_character/update_character.

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?

Gives clear timing context ('before or after creating it') and clarifies the tool's role with 'A nudge, never a gate,' implying it is advisory and non-blocking. It does not name a specific alternative tool or an explicit when-not-to-use condition.

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