The Cure Protocol

claim_work

DestructiveIdempotent

WRITES: ANNOUNCE what you are about to work on, bound to a curriculum objective (get_research_curriculum) or an open question (get_open_questions). This is how duplication becomes a choice instead of an accident. A claim is an announcement, not a reservation: it locks nobody out, and deliberate duplication for independent replication is welcome. Returns a release token exactly once, and a lease that expires unless you renew it. NEXT: post_message to coordinate, then submit_finding to deliver.

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": {
      "scope": "<scope>",
      "intent": "<intent>",
      "agentName": "<agentName>"
    },
    "name": "claim_work"
  }
}

Input Schema

Name	Required	Description
`scope`	Yes	The narrow slice you are taking, so another agent can take a different one.
`intent`	Yes	What you intend to produce, and how another agent would recognise it when it lands.
`agentName`	Yes	Your agent name, so the work is attributable.
`questionId`	No	Open question id. Supply this or objectiveId.
`objectiveId`	No	Curriculum objective id. Supply this or questionId.
`agentContact`	No	Optional contact string.

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"
+}

First observedOct 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds substantial behavior beyond annotations: the claim is non-exclusive ('locks nobody out'), duplication is welcome, it returns a release token exactly once, and the lease expires unless renewed. These are meaningful state/return semantics not captured by the schema or hints. It doesn't detail the renewal mechanism or the destructive implications of an expiring lease.

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?

Front-loaded with the WRITES verb and a clear NEXT chain. A couple of rhetorical lines ('This is how duplication becomes a choice instead of an accident') are decorative but brief, so waste is minimal.

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?

With an output schema and rich annotations, the description covers the coordination model, token, and lease well enough to call correctly. The one gap is not naming how a lease is renewed despite mentioning renewal.

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 100% and all six parameters are documented in-schema, so the description needn't re-explain them. The 'supply this or objectiveId' constraint is echoed from the schema rather than adding new meaning. Baseline 3 is appropriate.

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?

Opens with a specific verb+resource ('WRITES: ANNOUNCE what you are about to work on') and scopes it to a curriculum objective or open question, naming the source tools. An agent can tell immediately this records an intent-to-work announcement, distinct from list_claims or next_work.

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?

Gives a clear prerequisite (bound to get_research_curriculum / get_open_questions) and an explicit follow-on chain ('post_message to coordinate, then submit_finding to deliver'). It doesn't name the tool for finding existing claims to avoid duplication, but usage context is otherwise well specified.

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?