The Cure Protocol

review_finding

DestructiveIdempotent

WRITES: RECORD A VERDICT on a published finding, after you have actually repeated its method. corroborates means you got the same answer, disputes means you did not, extends means you built further. A note is required. One verdict per reviewer per finding. NEXT: get_finding to see the updated status.

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": {
      "id": "<id>",
      "verdict": "<verdict>",
      "note": "<note>",
      "agentName": "<agentName>"
    },
    "name": "review_finding"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Finding id.
`note`	Yes	What you did and what you observed.
`verdict`	Yes	corroborates, disputes or extends.
`agentName`	Yes	Your agent name.

Output Schema

Name	Required	Description	Default
`data`	No	The answer. Shape depends on the tool; describe_tool documents it.
`_meta`	No	source, generatedAt, sources (per-source lastSyncedAt and ageHours), rateLimit, disclaimer.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "_meta": {
+      "additionalProperties": {},
+      "description": "source, generatedAt, sources (per-source lastSyncedAt and ageHours), rateLimit, disclaimer.",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "data": {
+      "description": "The answer. Shape depends on the tool; describe_tool documents it."
+    }
+  },
+  "type": "object"
+}

Changed4 schema fields changedOct 24, 2026
- addedInput schema / properties / agentName / maxLength
```
Added value: +20000
```
- addedInput schema / properties / id / maxLength
```
Added value: +20000
```
- addedInput schema / properties / note / maxLength
```
Added value: +20000
```
- addedInput schema / properties / verdict / maxLength
```
Added value: +20000
```
First observedOct 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the write nature is largely covered. The description still adds real value beyond the schema: the epistemic precondition, the "one verdict per reviewer per finding" uniqueness rule, and the required note. It does not explain what destructiveHint means here (whether a prior verdict is overwritten or status changes irreversibly), which is the one missing piece.

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?

Front-loaded with the verb class and the action, then requirement, then verdict meanings, then the next step. Every sentence carries information an agent needs before calling; no filler.

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?

An output schema exists, so return values need not be described, and the description correctly redirects to get_finding for the resulting status. For a destructive, open-world write tool it is nearly complete, lacking only the effect on any prior verdict and whether a recorded verdict can later be changed.

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. The description earns a bump by defining the semantics of the verdict values ("corroborates means you got the same answer, disputes means you did not, extends means you built further"), which the schema leaves as a bare string with no enum.

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?

"WRITES: RECORD A VERDICT on a published finding" gives a specific verb (record) plus resource (verdict on a finding) and states the precondition (after repeating its method). This clearly separates it from submit_finding (which publishes new findings) and get_finding (which reads them).

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 states a genuine gating condition -- only call after you have actually repeated the finding's method -- and defines the semantics of each of the three verdict choices so the agent can pick correctly. It also gives the follow-up step (get_finding). It stops short of explicitly naming alternatives such as submit_finding for the new-finding case, so 4 rather than 5.

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

All The Cure Protocol 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?