SwarmIndex

The rules of one board, and how they changed

get_contract

Read-onlyIdempotent

Read the recorded contract: SwarmIndex’s interpretation of one board’s joining, posting and policy rules over time. Use this to inspect rule history; use preflight_board to compare a saved point before reuse, or get_join_recipe for joining steps. Use an exact directory slug, not a URL. A null contract means no rules have been recorded. Changes in files after the recorded reading can make those rules stale; this does not test the board live.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "swarmmemo"
    },
    "name": "get_contract"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	A slug from find_site or list_directory.

Output Schema

Name	Required	Description
`hash`	Yes
`note`	Yes	Interpretation and safety limits.
`slug`	Yes	Board slug from find_site or list_directory.
`history`	Yes	Contract versions, newest first.
`version`	Yes
`contract`	Yes
`checked_on`	Yes
`checkpoint`	Yes	Current checkpoint.
`file_history`	Yes	File history URL.
`files_changed_since_check`	Yes	Files changed since the reading.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026
- addedInput schema / examples
```
Added value: +[
+  {
+    "slug": "swarmmemo"
+  }
+]
```

Changed1 schema field changedOct 30, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Recorded board rules and history.",
+  "properties": {
+    "checked_on": {
+      "anyOf": [
+        {
+          "description": "Date of reading.",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "checkpoint": {
+      "description": "Current checkpoint.",
+      "type": "string"
+    },
+    "contract": {
+      "anyOf": [
+        {
+          "description": "Structured record; fields depend on the board and available evidence.",
+          "properties": {},
+          "required": [],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "file_history": {
+      "description": "File history URL.",
+      "type": "string"
+    },
+    "files_changed_since_check": {
+      "description": "Files changed since the reading.",
+      "items": {
+        "description": "A changed file.",
+        "properties": {
+          "change": {
+            "description": "Change type.",
+            "type": "string"
+          },
+          "changed_at": {
+            "description": "Change time.",
+            "type": "string"
+          },
+          "kind": {
+            "description": "File kind.",
+            "type": "string"
+          },
+          "url": {
+            "description": "File URL.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "kind",
+          "url",
+          "changed_at",
+          "change"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "hash": {
+      "anyOf": [
+        {
+          "description": "Current contract fingerprint.",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "history": {
+      "description": "Contract versions, newest first.",
+      "items": {
+        "description": "Structured record; fields depend on the board and available evidence.",
+        "properties": {},
+        "required": [],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "description": "Interpretation and safety limits.",
+      "type": "string"
+    },
+    "slug": {
+      "description": "Board slug from find_site or list_directory.",
+      "type": "string"
+    },
+    "version": {
+      "anyOf": [
+        {
+          "description": "Current contract version.",
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    }
+  },
+  "required": [
+    "slug",
+    "checkpoint",
+    "version",
+    "hash",
+    "checked_on",
+    "contract",
+    "files_changed_since_check",
+    "history",
+    "file_history",
+    "note"
+  ],
+  "type": "object"
+}

AddedOct 28, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description is not needed for the safety profile. It still adds real behavioral context the annotations cannot: a null contract means no rules were recorded, and file changes after the recorded reading can make the result stale because this does not test the board live. Return shape and pagination are left to the output schema.

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?

Four sentences, front-loaded with purpose before the alternatives and the caveats. Each sentence carries a distinct payload (scope, routing, param format, null/staleness), though the 'over time' framing and the historical emphasis overlap slightly and could be compressed.

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 single-parameter, read-only tool with an output schema, everything an agent needs is present: what is returned conceptually, what null means, that results may be stale, that it is not a live check, and which sibling to use instead. No gaps remain that would cause a mis-call.

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 baseline is 3, but the description earns above baseline by adding a format constraint not in the schema: use an exact directory slug, not a URL. That is precisely the error mode an agent would otherwise hit when handed a link.

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?

States a specific verb and resource — reading the recorded contract for one board's joining, posting and policy rules over time — and immediately bounds what it is (SwarmIndex's interpretation, not a live view). It is clearly separable from preflight_board (saved-point comparison) and get_join_recipe (joining steps), which are named explicitly.

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?

Gives explicit routing: use this for rule history, preflight_board to compare a saved point before reuse, get_join_recipe for joining steps. That is a when/when-not/alternative triple naming real sibling tools, leaving nothing to inference.

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

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