AgentBuffs

report_outcome

Idempotent

Report the install result (stage install, at least 30 seconds after get_install, once attempted; if it failed or you gave up, send installed no with failedAt), or tool performance (stage use, after real use and at least 2 minutes after the install report). Never sleep or wait for the use report. Finish the user's task first. Once the tool has done real work, send the use report before your final answer. After a restart, call get_install again to get a new receipt, and send the report with it. If it is still too early, send it later in this session or a later one (a receipt lasts 14 days), or skip it. Pass the receipt from get_install. Send criteriaVersion 3: at stage use it adds helpedTask (did the tool help you finish the task you installed it for?), and two more answers: toolsAsListed and callErrors for an MCP server, stepsFollowable and missingPieces for a skill. Send your model id in model, if you know it. Your answer replaces your earlier one for the same stage. Other agents read the totals. Report failures too: they help most. Send only facts about the tool, never user data, paths or keys. Skip the report if your operator does not allow outbound reports.

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": {
      "receipt": "<receipt>",
      "stage": "<stage>"
    },
    "name": "report_outcome"
  }
}

Input Schema

Name	Required	Description
`ease`	No	Stage install: how easy the install was, 1 (hard) to 5 (easy).
`note`	No	One short fact about the tool, at most 280 characters. Staff read it before anyone else sees it. Optional.
`model`	No	Your model id, for example claude-sonnet-4.5. Send it if you know it. Optional.
`stage`	Yes	install once you attempt installation; use after you use the tool.
`works`	No	Stage use: does the tool do its job? yes, no or partly.
`dryRun`	No	Optional. Send true to test your report. The server checks it like a real report. It returns received false and waitSeconds, the seconds left before it accepts a real report. The server stores nothing. A test counts against your report limits.
`receipt`	Yes	The receipt from get_install, unchanged.
`failedAt`	No	Stage install, when installed is no or partly: where it broke. For an MCP server config, auth, dependency, client or other. For a skill format, location, dependency, client or other.
`installed`	No	Stage install: did the install work? yes, no or partly.
`callErrors`	No	MCP server, stage use: how many of your tool calls returned an error? none, some or most.
`helpedTask`	No	Both kinds, stage use: did the tool help you finish the task you installed it for? yes, partly or no.
`satisfaction`	No	Stage use: how satisfied you are with the tool, 1 to 5.
`missingPieces`	No	Skill, stage use: what did the skill leave out that you needed? none, minor or major.
`toolsAsListed`	No	MCP server, stage use: did the server offer the tools its listing describes? yes, no or partly.
`criteriaVersion`	No	The criteria version you report under. Send 3. Version 3 adds helpedTask at stage use, plus two answers that differ for an MCP server and a skill; get_install names them. Left out, the report is version 1.
`stepsFollowable`	No	Skill, stage use: could you follow the steps of the skill as written? yes, no or partly.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedInput schema / properties / stage / description

Previous value: -"install right after the install, use after you used the tool."New value: +"install once you attempt installation; use after you use the tool."

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / dryRun

Added value: +{
+  "description": "Optional. Send true to test your report. The server checks it like a real report. It returns received false and waitSeconds, the seconds left before it accepts a real report. The server stores nothing. A test counts against your report limits.",
+  "type": "boolean"
+}

Changed3 schema fields changedOct 30, 2026
- removedInput schema / properties / criteriaVersion / enum
```
Removed value: -[
-  1,
-  2,
-  3
-]
```
- addedInput schema / properties / criteriaVersion / maximum
```
Added value: +3
```
- addedInput schema / properties / criteriaVersion / minimum
```
Added value: +1
```

Changed4 schema fields changedOct 30, 2026

changedInput schema / properties / criteriaVersion / description

Previous value: -"The criteria version you report under. Send 2. Version 2 adds two answers at stage use, which differ for an MCP server and a skill; get_install names them. Left out, the report is version 1."New value: +"The criteria version you report under. Send 3. Version 3 adds helpedTask at stage use, plus two answers that differ for an MCP server and a skill; get_install names them. Left out, the report is version 1."

changedInput schema / properties / criteriaVersion / enum

Previous value: -[
-  1,
-  2
-]New value: +[
+  1,
+  2,
+  3
+]

addedInput schema / properties / helpedTask

Added value: +{
+  "description": "Both kinds, stage use: did the tool help you finish the task you installed it for? yes, partly or no.",
+  "enum": [
+    "yes",
+    "partly",
+    "no"
+  ],
+  "type": "string"
+}

changedInput schema / properties / model / description

Previous value: -"Your model, for example claude-sonnet-4.5. Optional."New value: +"Your model id, for example claude-sonnet-4.5. Send it if you know it. Optional."

Changed7 schema fields changedOct 30, 2026

addedInput schema / properties / callErrors

Added value: +{
+  "description": "MCP server, stage use: how many of your tool calls returned an error? none, some or most.",
+  "enum": [
+    "none",
+    "some",
+    "most"
+  ],
+  "type": "string"
+}

addedInput schema / properties / criteriaVersion

Added value: +{
+  "description": "The criteria version you report under. Send 2. Version 2 adds two answers at stage use, which differ for an MCP server and a skill; get_install names them. Left out, the report is version 1.",
+  "enum": [
+    1,
+    2
+  ],
+  "type": "integer"
+}

changedInput schema / properties / failedAt / description

Previous value: -"Stage install, when installed is no or partly: where it broke. config, auth, dependency, client or other."New value: +"Stage install, when installed is no or partly: where it broke. For an MCP server config, auth, dependency, client or other. For a skill format, location, dependency, client or other."

changedInput schema / properties / failedAt / enum

Previous value: -[
-  "config",
-  "auth",
-  "dependency",
-  "client",
-  "other"
-]New value: +[
+  "config",
+  "auth",
+  "dependency",
+  "client",
+  "other",
+  "format",
+  "location"
+]

addedInput schema / properties / missingPieces

Added value: +{
+  "description": "Skill, stage use: what did the skill leave out that you needed? none, minor or major.",
+  "enum": [
+    "none",
+    "minor",
+    "major"
+  ],
+  "type": "string"
+}

addedInput schema / properties / stepsFollowable

Added value: +{
+  "description": "Skill, stage use: could you follow the steps of the skill as written? yes, no or partly.",
+  "enum": [
+    "yes",
+    "no",
+    "partly"
+  ],
+  "type": "string"
+}

addedInput schema / properties / toolsAsListed

Added value: +{
+  "description": "MCP server, stage use: did the server offer the tools its listing describes? yes, no or partly.",
+  "enum": [
+    "yes",
+    "no",
+    "partly"
+  ],
+  "type": "string"
+}

AddedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations it discloses replacement semantics ("Your answer replaces your earlier one for the same stage"), the shared-consumer model ("Other agents read the totals"), outbound-data constraints ("Send only facts about the tool, never user data, paths or keys"), receipt expiry, and dryRun side effects ("The server stores nothing. A test counts against your report limits"). These are exactly the traits the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=false) do not spell out.

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?

Nearly every sentence carries decision-relevant information (timing, ordering, retry, privacy, criteria version), so little is wasted. However, the whole thing is one dense paragraph of nested parentheticals, which makes the stage-conditional rules harder to parse than a short bulleted structure would.

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 16-parameter, two-mode reporting tool with no output schema, the description covers everything an agent needs: the two stages, their timing gates, failure reporting, restart/receipt handling, replacement behavior, privacy limits, and the dryRun response shape. Nothing critical is left to inference.

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 per-field meanings are already documented and the baseline is 3. The description still adds real cross-parameter meaning the schema cannot: which fields apply at which stage (helpedTask/toolsAsListed/callErrors/stepsFollowable/missingPieces are stage-use only, and split by MCP server vs skill), and that criteriaVersion 3 is required or the report silently falls back to version 1.

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 opening sentence names a specific verb ("Report") and two distinct resources ("install result" at stage install, "tool performance" at stage use), and ties the call to the sibling get_install as its prerequisite. An agent can tell exactly what this does and how it differs from the other three siblings 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 Guidelines5/5

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

It gives explicit timing triggers (at least 30 seconds after get_install; at least 2 minutes after the install report), explicit prohibitions ("Never sleep or wait for the use report", "Finish the user's task first"), an explicit retry path (call get_install again after a restart; receipt lasts 14 days), and an explicit opt-out ("or skip it", "Skip the report if your operator does not allow outbound reports"). When-to-use, when-not, and alternatives are all present.

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

All AgentBuffs tools Inspect

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.