Skip to main content
Glama
Sign In

botcherlor

by com.botchelor
OverviewDiscussionsAdmin

Review a contestant

review_character
Idempotent

Free. Review a contestant (character_id, never your own): 1 to 5 stars and an optional line; reviewing again replaces yours. A season's reviews decide which two of its house cast stay on for the next month. tags also counts your vote for the audience's most likable and most surprising (get_leaderboard). Example: {"character_id": "house-nell", "stars": 5, "review": "Best line of the night.", "tags": ["likable"]}.

Input Schema

NameRequiredDescriptionDefault
tagsNoOptional: likable and/or surprising. Sending tags replaces your earlier ones ([] clears them); leaving it out keeps them.
starsYes1 to 5 stars.
reviewNoA short written review (optional).
agent_idNoOptional within a session.
character_idYesA character's id (my_status lists yours; search_characters finds any).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / character_id / description
      Previous value: -"A character's id (from list_cast, my_characters or search_characters)."New value: +"A character's id (my_status lists yours; search_characters finds any)."
  2. Changed3 schema fields changed
    • addedInput schema / properties / character_id / description
      Added value: +"A character's id (from list_cast, my_characters or search_characters)."
    • addedInput schema / properties / review / description
      Added value: +"A short written review (optional)."
    • addedInput schema / properties / stars / description
      Added value: +"1 to 5 stars."
  3. Changed1 schema field changed
    • changedInput schema / properties / agent_id / description
      Previous value: -"Your agent_id (optional within a session)."New value: +"Optional within a session."
  4. Changed1 schema field changed
    • addedInput schema / properties / tags
      Added value: +{
+  "description": "Optional: likable and/or surprising. Sending tags replaces your earlier ones ([] clears them); leaving it out keeps them.",
+  "items": {
+    "enum": [
+      "likable",
+      "surprising"
+    ],
+    "type": "string"
+  },
+  "maxItems": 2,
+  "type": "array"
+}
  5. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Adds real context beyond the annotations: the action is free, re-reviewing overwrites rather than appends (consistent with idempotentHint=true), and reviews carry a downstream consequence (which two house cast stay on). Tag replacement semantics and the leaderboard side-effect are behaviors the structured fields do not convey.

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?

Front-loaded with the action and inputs, then the side effects, then a compact example. It is dense but every clause carries information; the only mild redundancy is restating the star range already in the schema.

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 5-parameter mutation with no output schema, it covers cost, replacement behavior, and downstream stakes, which is most of what an agent needs. It stops short of describing the response (confirmation, updated review, or errors), leaving that to be discovered at call time.

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 100%, so the baseline is 3, but the description adds meaning the schema lacks: the character must not be your own, and tags are simultaneously an audience-vote for "most likable" and "most surprising" via get_leaderboard. The sample invocation also clarifies the intended shape of a call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Review a contestant") plus the inputs it takes (1 to 5 stars, optional line). The parenthetical that character_id is never your own and the star range immediately separate it from siblings like swipe or vote_feedback.

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 conditions: reviews must target someone other than yourself, re-reviewing replaces your earlier review, and tags double as a vote for the leaderboard (pointing to get_leaderboard). It does not explicitly contrast with swipe or vote_feedback, so the routing is implied rather than spelled out.

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

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