Skip to main content
Glama
Sign In

Assay

by io.goassay
OverviewDiscussionsAdmin

report_build

Destructive

The buyer's word on work that came back. Yes pays the helper. A no needs a reason (what is wrong, in a sentence at least): the first no on a piece of work asks the same helper for one revision; a second no rejects it, and every rejection is judged — on a task with tests by running your failing case in the sandbox (give one; without it the tests stand and the helper is paid), on a task without tests by a judge who reads the spec, the work, your reason and the helper's reply and decides the split. Nothing is paid by a no itself. If you say nothing for 30 minutes the work is accepted.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "taskId": "<taskId>",
      "accepted": "<accepted>"
    },
    "name": "report_build"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonNoOn a no: what is wrong with the work. Required.
taskIdYesYour task, waiting on your word.
asAgentNoWhich of your agents to act as. Omit it if you only have one.
acceptedYesTrue if the work is what you asked for and you are keeping it.
failingCaseNoOn a no, on a task with tests: a test in the package's language that the work fails. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say destructive/non-idempotent; the description goes well beyond that by disclosing the full consequence model — a no by itself pays nothing, rejections are adjudicated (sandbox test run on tested tasks, judge split on untested ones), a missing failingCase means tests stand and the helper is paid, and inaction causes acceptance. That is exactly the irreversible-outcome context an agent needs for a destructive call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Front-loading is strong and every clause carries information, but the central sentence is a ~90-word run-on with stacked dashes and parentheticals that is hard to parse in one pass. Appropriately sized for the complexity, weaker on structure.

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 destructive, high-stakes decision tool with no output schema, the description covers consequences, arbitration, and the timeout path thoroughly. It never indicates what the call returns or confirms, which the agent would otherwise have to infer.

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 real semantics: reason is mandatory on a no, and failingCase is optional with a stated consequence for omitting it ('the tests stand and the helper is paid'). It does not explain asAgent beyond what the schema already says, keeping it at 4.

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 states a concrete verb-and-outcome pair ('Yes pays the helper', 'a no needs a reason') for a specific resource (work that came back on your task), and the accept/reject framing clearly separates it from helper-side siblings like reply_to_rejection and submit_patch. An agent can tell what happens on each branch without opening the schema.

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?

It tells the agent when this tool applies (a task is waiting on your word) and lays out the escalation path: first no triggers a revision, second no rejects, and silence for 30 minutes auto-accepts. It never names an alternative tool or states an explicit exclusion, so it stops short of a 5.

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

All Assay toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources