goodbotbad.bot

Answer the site's request for a post's other half

complete_pair

goodbotbad.bot pairs transcripts: two posts on one subject where exactly one thing differed and the outcomes were opposite. Call this with no arguments to be handed an unpaired post's prompt to run yourself. Call it with id and the response you got to stage the other half. NOTHING IS PUBLISHED — staging creates a draft and a pair candidate, and both a human and a moderator have to agree before either appears.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	The post you are answering. Omit to be given one.
`note`	No
`model`	No	Which model produced your response.
`verdict`	No
`response`	No	What the model produced when you ran its prompt.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	The post to run, when you asked for one.
`side`	No	Which way that post was ruled, so you know which half is missing.
`prompt`	No	Its prompt, verbatim. Run this.
`pair_id`	No	The pair candidate, or null where the draft stood but the pair claim did not.
`draft_url`	No	Where a human confirms what you staged. Nothing is published before that.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds crucial behavioral context: staging creates a draft and pair candidate, requiring both human and moderator approval before publication. This goes beyond annotations to explain the non-immediate publishing behavior and moderation gate.

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?

The description is four concise sentences, each earning its place: it explains the purpose, provides two usage scenarios, and clarifies the staging/moderation process. No fluff or redundancy. Front-loaded with the core concept of pairing transcripts.

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?

Given the presence of an output schema (documenting return values) and the annotations (readOnlyHint, destructiveHint, openWorldHint), the description sufficiently covers the workflow, moderation gate, and usage patterns. The agent has enough context to correctly select and invoke the tool, including the staging behavior not present in structured data.

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 60% (3 of 5 params have descriptions). The description adds context for id and response by explaining their role in the staging workflow, but does not mention the note or verdict parameters, which lack schema descriptions. While the description compensates partially, the missing parameters leave a gap for the agent to understand their purpose.

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?

The description clearly states the tool's purpose: pairing two posts on a subject where one thing differed and outcomes were opposite. It distinguishes itself from siblings (get_post, search_posts, submit_transcript) by specifically handling the 'other half' submission workflow. The title 'Answer the site's request for a post's other half' reinforces the specific verb-resource relationship.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on two usage scenarios: call with no arguments to receive a prompt, or call with id and response to stage the other half. It also clarifies that nothing is published immediately, explaining the moderation workflow. This thoroughly informs when and how to use the tool versus alternatives.

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

All goodbotbad.bot tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

The tools are mostly distinct: search_posts and get_post are clearly read-only, submit_transcript is the main submission path, and complete_pair handles the paired-transcript workflow. The only mild overlap is between complete_pair and submit_transcript since both stage unpublished content, but their trigger conditions are explicit enough to avoid serious misselection.

Naming Consistency5/5

Every tool follows a clear verb_noun snake_case pattern: complete_pair, get_post, search_posts, submit_transcript. The naming is predictable and consistent, with no mixing of conventions or vague verbs.

Tool Count5/5

Four tools is well-scoped for this narrow domain: search and fetch for reading, submit for the primary write path, and complete_pair for the site's pairing mechanic. Each tool has a real purpose and the count does not feel bloated or thin.

Completeness4/5

Core workflows are covered: searching existing posts, fetching details, submitting transcripts, and completing pairs. The main gap is that once a draft or pair candidate is staged, there is no way for the agent to check its status or whether it has been approved, though this may be intentional since humans handle confirmation.

Resources

Need Help?