Spoolis

Spool creation

create_spool

Create a production Spool (the agreement object) from structured terms and acceptance criteria. Use when both parties will participate in the agreement lifecycle; do not use for one-call unilateral verification. This persists a proposed agreement and may send the counterparty invite reported in the response handoff block. The type field defaults to the person or business service path, while agent selects the agent settlement rail. Conditions may declare verification_method third_party with an external_judge so verification consumes your own evaluator's bound result instead of Spoolis judging those conditions. Production only: set SPOOLIS_API_KEY; not available in the no-key sandbox.

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": {
      "parties": "<parties>",
      "value": "<value>",
      "deliverable": "<deliverable>",
      "terms": "<terms>",
      "conditions": "<conditions>"
    },
    "name": "create_spool"
  }
}

Input Schema

Name	Required	Default
`type`	No	service
`terms`	Yes
`value`	Yes
`parties`	Yes
`finality`	No
`agreement`	No
`economics`	No
`conditions`	Yes
`deliverable`	Yes
`gated_action`	No
`dispute_policy`	No
`gated_action_note`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

addedInput schema / properties / finality

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "correction": {
+      "additionalProperties": false,
+      "properties": {
+        "allowed": {
+          "type": "boolean"
+        },
+        "requires_authority": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "allowed",
+        "requires_authority"
+      ],
+      "type": "object"
+    },
+    "on_silence": {
+      "enum": [
+        "keep",
+        "hold",
+        "reject"
+      ],
+      "type": "string"
+    },
+    "reopen": {
+      "additionalProperties": false,
+      "properties": {
+        "allowed": {
+          "type": "boolean"
+        },
+        "by": {
+          "items": {
+            "enum": [
+              "buyer",
+              "provider",
+              "third_party"
+            ],
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "until": {
+          "enum": [
+            "final",
+            "never"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "allowed",
+        "by",
+        "until"
+      ],
+      "type": "object"
+    },
+    "window": {
+      "additionalProperties": false,
+      "properties": {
+        "after": {
+          "enum": [
+            "acceptance",
+            "evidence",
+            "period_end"
+          ],
+          "type": "string"
+        },
+        "duration_iso8601": {
+          "pattern": "^P(?=\\d|T\\d)",
+          "type": "string"
+        }
+      },
+      "required": [
+        "after",
+        "duration_iso8601"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "window",
+    "reopen",
+    "correction",
+    "on_silence"
+  ],
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A4.1/5.0

Behavior5/5

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

While annotations already indicate readOnlyHint=false and destructiveHint=false, the description adds significant behavioral context: it persists a proposed agreement, may send a counterparty invite, describes type-field routing behavior, explains third_party verification consuming a bound evaluator result, and clearly states the API-key requirement for production. This goes well beyond the annotations and effectively discloses side effects and environment constraints.

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?

The description is six sentences totaling roughly 130 words. It is front-loaded with the primary purpose in the first sentence, then moves to usage and side effects. Each sentence earns its place by conveying a distinct piece of behavioral or contextual information. It is slightly longer than strictly necessary, but the density of useful information justifies the length.

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?

Given the high complexity (12 params, nested objects, no output schema), the description does a solid job of covering usage, side effects, type behavior, conditions behavior, and environment constraints. However, it lacks any details about the response format (only a vague 'reported in the response handoff block') and does not mention error cases or prerequisites for the no-key sandbox beyond saying it's unavailable. These are minor gaps for a tool this complex.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate for parameter meanings across 12 params. It provides useful context for 'type' (defaults and agent settlement rail) and 'conditions' (third_party with external_judge), and references 'structured terms and acceptance criteria' which likely maps to 'terms' and 'conditions'. However, it does not address parties, value, deliverable, finality, economics, dispute_policy, or other parameters. This leaves too much unexplained for a tool with zero coverage.

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 clearly states the verb ('Create'), the resource ('production Spool (the agreement object)'), and the input ('structured terms and acceptance criteria'). It also differentiates from related tools by specifying when to use it ('when both parties will participate in the agreement lifecycle') and when not to ('do not use for one-call unilateral verification'). This is specific and distinguishes it from siblings like verify_spool.

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?

The description gives explicit guidance on when to use the tool ('when both parties will participate...') and when not to ('do not use for one-call unilateral verification'). It also mentions the production-only prerequisite (setting SPOOLIS_API_KEY). However, it does not explicitly name an alternative tool (e.g., verify_spool) as a fallback for unilateral verification, which would make it a 5.

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

All Spoolis 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?