Skip to main content
Glama
Sign In

The Cure Protocol

by com.negativeresistance
OverviewDiscussionsAdmin

run_twin_benchmark

Read-only

Run two or three nominal reaction models against identical observations. Read twin_benchmark_guide first. Returns raw per-species errors against simple baselines, failed-candidate diagnostics, replay manifests and unobserved disagreement points. Stateless, no model fitting or automatic ratification.

Input Schema

NameRequiredDescriptionDefault
experimentsYes2 or 3 run_twin_experiment inputs (competing mechanisms) that share the same context, units, species, arms, dataset and observations.

Output Schema

NameRequiredDescriptionDefault
dataNoThe answer. Shape depends on the tool; describe_tool documents it.
_metaNosource, generatedAt, sources (per-source lastSyncedAt and ageHours), rateLimit, disclaimer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / experiments / description
      Added value: +"2 or 3 run_twin_experiment inputs (competing mechanisms) that share the same context, units, species, arms, dataset and observations."
  3. Changed1 schema field changed
    • changedInput schema / properties / experiments / items / properties / model / properties / timeUnit / enum
      Previous value: -[
-  "second",
-  "minute",
-  "hour"
-]New value: +[
+  "second",
+  "minute",
+  "hour",
+  "week"
+]
  4. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavioral context: it is stateless, performs no model fitting and no automatic ratification, so the agent knows not to expect a verdict. It also enumerates the output payload (raw errors, baselines, diagnostics, manifests). Minor gaps: no mention of cost, determinism or runtime.

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?

Four short sentences, front-loaded with the action, then the prerequisite, then outputs, then hard boundaries. Every sentence carries information; nothing repeats the title or schema.

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 complex nested-schema tool with an output schema present, the description covers the prerequisite reading, the statelessness and the no-ratification boundary. The return values are also summarized, which is optional given the output schema, so the remaining gaps are minor.

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 description coverage is 100% and the experiments parameter carries its own description, so the schema does the heavy lifting. The tool description adds almost nothing about parameter semantics beyond the 2–3 experiment count, which the schema already encodes, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run two or three nominal reaction models against identical observations') and pins the cardinality the schema enforces (minItems 2, maxItems 3). The competitive-comparison framing implicitly separates it from run_twin_experiment, but no sibling is named outright.

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 an explicit prerequisite ('Read twin_benchmark_guide first') and the usage context (comparing competing mechanisms on shared data) is clear from the first sentence. It stops short of stating when NOT to use it, e.g. for a single model run, which the sibling run_twin_experiment covers.

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 toolsInspect
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