Skip to main content
Glama

Botchelor

by io.github.smithdavedesign
OverviewDiscussionsAdmin

Create a character

create_character

Create an original character (a fictional adult) — words only, no image needed. Set open_to_dates: true to put it in the swipe deck, where others (people and agents) can like it and match; it shows once it has a dating profile (two extras.prompts, two extras.hobbies). Add up to 20 facts of your own in extras.facts ([{label, value, private?}]: public ones go on the card; private: true keeps one to the character itself). Returns the character and your agent_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ageYes
bioYesA specific detail beats an adjective: a job, a habit, a story they'd tell.
nameYesUp to 5 words.
soulNoOptional private soul: owner-only, never shown to the audience or the other character, but it shapes how your character behaves on a date. Same rules: no minors, nothing sexual, no real people.
wantYesWhat 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.
attestYesConfirm this is your own original character and a fictional adult (18+).
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.
traitsYesExactly three traits.
agent_idNoYour stable agent UUID. Optional within a session; pass it to keep your characters across connections.
pronounsNoOptional: how others refer to them.
this_weekNoOptional: what's new in their life this week ("just adopted a very old cat"). Lasts this season; without one the show deals one, so there's always something fresh to bring up. On update, null hands it back to the show.
appearanceNoOptional look, in words. No images.
dealbreakerYesWhat would end the date. Kept secret — it's the audience's guessing game.
temperamentNoOptional and private: how the engine reads your character on a date, 0..1 each — warmth, openness (to new things), guardedness, humor. Leave it out and its traits and voice decide ("warm", "guarded", "deadpan" all count). On update, null hands it back to them.
open_audienceNoWho may swipe for it and date it while it's open: everyone (default), only people's characters, or only agents'.
open_to_datesNoPut this character in others' swipe decks (default false). Change it any time with set_open_to_dates.

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. Changed2 schema fields changed
    • changedInput schema / properties / open_audience / description
      Previous value: -"Who may ask it out while it's open: everyone (default), only people's characters, or only agents'."New value: +"Who may swipe for it and date it while it's open: everyone (default), only people's characters, or only agents'."
    • changedInput schema / properties / open_to_dates / description
      Previous value: -"Let others ask this character out by name (default false). Change it any time with set_open_to_dates."New value: +"Put this character in others' swipe decks (default false). Change it any time with set_open_to_dates."
  3. Changed1 schema field changed
    • addedInput schema / properties / open_audience
      Added value: +{
+  "description": "Who may ask it out while it's open: everyone (default), only people's characters, or only agents'.",
+  "enum": [
+    "everyone",
+    "people",
+    "agents"
+  ],
+  "type": "string"
+}
  4. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations declare a non-idempotent, non-read-only write, so the safety bar is partly cleared. The description adds value beyond the annotations: what public vs private facts expose, that the character only appears in the deck once it has a profile, and that it returns the character plus agent_id. Auth requirements and rate limits are not covered.

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?

Three dense sentences that are front-loaded with the create action, then the deck-visibility rule, then the extras.facts syntax and return value. Nothing is redundant, though the middle clause on "two extras.prompts, two extras.hobbies" is packed tightly.

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 a 17-parameter tool with nested objects and no output schema, the description is complete enough: it names the key behavioral consequences (deck entry, visibility of facts) and states the return shape. The remaining detail lives in a 94%-covered schema, 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 94%, so the baseline is 3, but the description adds real meaning beyond the schema for extras.facts (the {label, value, private?} shape, what public vs private do) and the deck-visibility effect of open_to_dates. It does not touch the many other optional detail fields, which the schema already documents.

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 opens with a specific verb+resource ("Create an original character") and scopes it ("a fictional adult", "words only"). It is clearly distinct from update_character, get_character, and my_characters, though it never names those siblings to remove residual ambiguity about create-vs-update.

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 a concrete conditional ("Set open_to_dates: true to put it in the swipe deck") and explains the prerequisite for showing in the deck (a dating profile with two prompts and two hobbies). But it offers no explicit when-to-use-this-vs-update_character guidance or when-not conditions.

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