goodbotbad.bot

Submit a transcript for the crowd to rule on

submit_transcript

Submit an AI prompt and the response it produced to goodbotbad.bot, where people vote good bot or bad bot on it. NOTHING IS PUBLISHED BY THIS CALL. It creates a draft and returns a URL; a human has to open that URL and confirm before anything becomes visible, and you should show them the URL. There is deliberately no note parameter — the note is the human's account of why the exchange is worth posting, they write it on that page, and it is not something to compose for them. Secrets and API keys are detected and the submission is refused outright. Personal data — an email address, a phone number, a home directory path — is redacted before storing and named in the reply; show your human what was removed along with the URL. Quote the prompt verbatim if you can; if the real input was too large or is not recoverable, describe it in objective instead and say so. If the transcript is larger than 65536 bytes, send manifest INSTEAD of turns — a role, a byte count and a short label per turn, and no bodies — and the server will ask your human which passages to send. Do not send the bodies and let the server reject them: that has already disclosed them. To submit a repair for a failure already on the site, pass its id as fixes — a fix is a rewritten prompt and the better response it produced, so its verdict is good, and it waits on two people rather than one: a moderator screens it, and whoever posted the failure decides whether it repairs it. If the reply asks for token usage, it is asking your human and not you — they read it off their own client, which you cannot see. Put what they say in inputResponses.usage and send the whole call again with the requestState; it attaches to the draft that already exists rather than making a second one. Never supply a figure of your own, and skipping is a fine answer.

Input Schema

TableJSON Schema

Name	Required	Description
`fixes`	No	The id of a published post the crowd ruled bad bot, if this transcript is the repair of it. The id search_posts and get_post return.
`model`	Yes	The model or product that produced it, as its own name.
`title`	Yes
`turns`	No	The exchange in order. Omit when sending a manifest. Use role `attachment` for an image or file that was part of the exchange — its body describes what was there, since only text is stored.
`usage`	No	Token counts, if your client has genuine API metadata. Omitted is better than guessed.
`verdict`	Yes	Your human's ruling, not yours.
`category`	Yes
`manifest`	No	Describes an oversized transcript without sending it: role, bytes and a short label per turn.
`source_url`	No
`requestState`	No	Echo back untouched from a previous inputRequired reply.
`inputResponses`	No	Answers to a previous inputRequired reply.

Output Schema

TableJSON Schema

Name	Required	Description
`fixes`	No	The id of the failure this repairs, if it is a repair.
`state`	No	`draft` on submission. Later legs report where the post has since got to.
`post_url`	No	The post's own address. It answers 404 until your human confirms; after that anyone holding it can read the post. Share this one, never the draft URL.
`draft_url`	No	Where your human confirms it. Nothing is published until they do.
`public_id`	No
`redactions`	No	What was redacted before storing, named so your human knows what changed. Empty when nothing was.
`usage_source`	No	`attested` when a human typed the figures. Null when they declined.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 23, 2026

addedOutput schema / properties / post_url

Added value: +{
+  "description": "The post's own address. It answers 404 until your human confirms; after that anyone holding it can read the post. Share this one, never the draft URL.",
+  "type": "string"
+}

First observedAug 18, 2026

TDQS

A5/5.0

Behavior5/5

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

The description goes far beyond the annotations. Annotations say readOnlyHint=false and destructiveHint=false, but the description discloses that the call is not published, returns a URL requiring human confirmation, detects and refuses secrets, redacts personal data and names it in the reply, and explains the two-person rule for fixes. It also clarifies the token usage flow, explicitly stating the agent must never supply its own figures. These are critical behavioral traits that the annotations alone would 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While long, every sentence earns its place. The description is front-loaded with the primary purpose and the critical 'nothing is published' caveat, then moves through the manifest path, the fixes flow, and the token usage workflow. It avoids redundancy and uses direct imperative sentences ('Quote the prompt verbatim', 'Never supply a figure of your own') that are actionable. The density is high but justified by the tool's complexity.

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 tool with 11 parameters, 4 required, nested objects, and an output schema, this description covers all major usage scenarios: standard submission, oversized transcripts via manifest, repair via fixes, and the interactive token-usage flow. It addresses security (secrets, redaction), human involvement (URL confirmation, note composition), and edge cases (oversized prompts). No significant operational gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 73%, the description adds substantial meaning to parameters beyond what the schema provides. It explains the `manifest`/`turns` tradeoff, the role of `fixes`, the `objective` fallback for non-recoverable prompts, the `attachment` role description, and the purpose of `inputResponses.usage`. It also clarifies that `verdict` and `category` are the human's ruling, not the agent's. This is exactly the kind of contextual enrichment that helps an agent call correctly.

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 opens with a clear verb+resource: 'Submit an AI prompt and the response it produced to goodbotbad.bot' and immediately establishes the purpose of crowd voting. It distinguishes itself from siblings (complete_pair, get_post, search_posts) by being the only tool that creates submissions, and it explicitly notes it creates a draft rather than publishing, which is a key differentiator.

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 when-to-use guidance: it specifies when to use `turns` vs `manifest` (oversized transcripts), when to use `fixes` (repair of a failure), and when to use `inputResponses` (token usage from the human). It also states a clear don't: 'Do not send the bodies and let the server reject them: that has already disclosed them.' This is model usage guidance, not just a restatement of purpose.

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

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?