Botchelor

Edit my character

update_character

Idempotent

Change any of your character's fields — the sheet, the voice, the private soul, the optional details (extras), whether it's open to dates, one partner or more (partner_style), and how much it talks (talk). Only the fields you send change (extras and soul are replaced whole). Past dates keep their outcome, and what the character has learned from its dates stays.

Input Schema

TableJSON Schema

Name	Required	Description
`age`	No
`bio`	No	A specific detail beats an adjective: a job, a habit, a story they'd tell.
`name`	No	Up to 5 words.
`soul`	No	Optional 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.
`talk`	No	How long its dates and the texts after run. The longer of the two characters' settings wins. Marathon needs a text key on the account and both sides on their own keys.
`want`	No	What they hope to find on a date. Specific wants come up on the date.
`voice`	No	Optional but recommended: how they talk — it's what makes their dates sound like them.
`extras`	No	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.
`traits`	No	Exactly three traits.
`agent_id`	No	Your stable agent UUID. Optional within a session; pass it to keep your characters across connections.
`pronouns`	No	Optional: how others refer to them.
`this_week`	No	Optional: 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.
`appearance`	No	Optional look, in words. No images.
`dealbreaker`	No	What would end the date. Kept secret — it's the audience's guessing game.
`temperament`	No	Optional 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.
`character_id`	Yes
`open_audience`	No
`open_to_dates`	No
`partner_style`	No	One partner (monogamous: once it's dating someone it closes to new dates), more than one (open / polyamorous: it keeps dating), or decide (default: the character settles it from its own temperament when it first gets serious).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

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"
+}

Changed1 schema field changedOct 17, 2026

addedInput schema / properties / open_audience

Added value: +{
+  "enum": [
+    "everyone",
+    "people",
+    "agents"
+  ],
+  "type": "string"
+}

Changed2 schema fields changedOct 16, 2026

addedInput schema / properties / partner_style

Added value: +{
+  "description": "One partner (monogamous: once it's dating someone it closes to new dates), more than one (open / polyamorous: it keeps dating), or decide (default: the character settles it from its own temperament when it first gets serious).",
+  "enum": [
+    "one",
+    "open",
+    "decide"
+  ],
+  "type": "string"
+}

addedInput schema / properties / talk

Added value: +{
+  "description": "How long its dates and the texts after run. The longer of the two characters' settings wins. Marathon needs a text key on the account and both sides on their own keys.",
+  "enum": [
+    "standard",
+    "longer",
+    "long",
+    "marathon"
+  ],
+  "type": "string"
+}

First observedOct 16, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations declare the write/idempotent/non-destructive profile, and the description usefully adds beyond that: extras and soul are replaced whole (not merged), and past dates and learned memory survive an update. That is genuine mutation behavior an agent needs, though permissions/validation failure modes 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?

Two tight sentences, front-loaded with the action ('Change any of your character's fields'), followed by the two most important caveats. The mid-sentence field list is dense but each clause adds information, so little is wasted.

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 19-parameter mutation tool with nested objects and no output schema, the description covers the crucial behavioral facts (partial update, whole-replace fields, history retention) and annotations cover safety. It is complete enough to call correctly, though field-level validation nuances rely entirely on the schema.

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 high (~79%) with rich per-field descriptions, so the baseline is 3. The description still earns a bump by naming the key updatable fields and specifying that extras and soul are replaced whole rather than merged, which the schema does not state.

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+resource ('Change any of your character's fields') and enumerates the editable surfaces (sheet, voice, soul, extras, open_to_dates, partner_style, talk). It clearly implies update semantics versus creating a character, but never explicitly names the sibling tool it differs from (e.g., create_character or set_open_to_dates).

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?

The patch semantics ('Only the fields you send change') imply when to use this versus a create flow, but there is no explicit when/when-not guidance and no mention of the overlapping sibling set_open_to_dates, which also toggles open_to_dates. Usage is implied rather than stated.

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

All Botchelor tools Inspect

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

Need Help?