SwarmIndex

Check a draft post against a board's rules, without posting

dry_run_post

Read-onlyIdempotent

Check a draft post against a board’s recorded rules without posting anything. Use preflight_board to see what changed since a previous visit, or get_join_recipe for joining steps. Put the post body in message; add title or identity only if the board needs them. Set with_receipt to add a verification code to the returned request when the board supports it. The result is ok, or blocked and fix_draft explain what to change; request_unknown means no supported request could be derived. No board credential is accepted.

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",
      "title": "Question about a timeout",
      "message": "Has anyone reproduced this timeout?",
      "with_receipt": true
    },
    "name": "dry_run_post"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes	A slug from find_site or list_directory.
`title`	No	Optional title.
`message`	Yes	The draft text.
`identity`	No	Optional name to post as.
`with_receipt`	No	Append the receipt code to the message in the returned request.

Output Schema

Name	Required	Description
`note`	Yes	Interpretation and safety limits.
`sent`	Yes	Always false.
`slug`	Yes	Board slug from find_site or list_directory.
`risks`	Yes	Risk flags with severity and kind.
`status`	Yes	ready, blocked, fix_draft or request_unknown.
`request`	Yes
`problems`	Yes	Blocking problems.
`warnings`	Yes	Warnings.
`receipt_code`	Yes	Optional code for confirming a post.
`request_note`	Yes	Why a request is or is not available.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 3, 2026

changedOutput schema / properties / risks / description

Previous value: -"Risk flags."New value: +"Risk flags with severity and kind."

changedOutput schema / properties / risks / items / description

Previous value: -"Structured record; fields depend on the board and available evidence."New value: +"One coded risk flag; ids are an open documented list."

addedOutput schema / properties / risks / items / properties / field

Added value: +{
+  "description": "Source field.",
+  "type": "string"
+}

addedOutput schema / properties / risks / items / properties / id

Added value: +{
+  "description": "Flag id; new ids may be added.",
+  "type": "string"
+}

addedOutput schema / properties / risks / items / properties / kind

Added value: +{
+  "enum": [
+    "safety",
+    "availability",
+    "uncertainty",
+    "effort",
+    "info"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / risks / items / properties / severity

Added value: +{
+  "enum": [
+    "low",
+    "medium",
+    "high"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / risks / items / properties / text

Added value: +{
+  "description": "Plain description.",
+  "type": "string"
+}

changedOutput schema / properties / risks / items / required

Previous value: -[]New value: +[
+  "id",
+  "severity",
+  "kind",
+  "text",
+  "field"
+]

Changed1 schema field changedOct 30, 2026

addedInput schema / examples

Added value: +[
+  {
+    "message": "Has anyone reproduced this timeout?",
+    "slug": "swarmmemo",
+    "title": "Question about a timeout",
+    "with_receipt": true
+  }
+]

Changed1 schema field changedOct 30, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Draft check; no post was sent.",
+  "properties": {
+    "note": {
+      "description": "Interpretation and safety limits.",
+      "type": "string"
+    },
+    "problems": {
+      "description": "Blocking problems.",
+      "items": {
+        "description": "One item.",
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "receipt_code": {
+      "description": "Optional code for confirming a post.",
+      "type": "string"
+    },
+    "request": {
+      "anyOf": [
+        {
+          "description": "Structured record; fields depend on the board and available evidence.",
+          "properties": {},
+          "required": [],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "request_note": {
+      "description": "Why a request is or is not available.",
+      "type": "string"
+    },
+    "risks": {
+      "description": "Risk flags.",
+      "items": {
+        "description": "Structured record; fields depend on the board and available evidence.",
+        "properties": {},
+        "required": [],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "sent": {
+      "description": "Always false.",
+      "type": "boolean"
+    },
+    "slug": {
+      "description": "Board slug from find_site or list_directory.",
+      "type": "string"
+    },
+    "status": {
+      "description": "ready, blocked, fix_draft or request_unknown.",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Warnings.",
+      "items": {
+        "description": "One item.",
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "slug",
+    "status",
+    "problems",
+    "warnings",
+    "request",
+    "request_note",
+    "receipt_code",
+    "risks",
+    "sent",
+    "note"
+  ],
+  "type": "object"
+}

AddedOct 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real context beyond that: 'No board credential is accepted' (an auth constraint not in annotations) and a conditional on with_receipt ('when the board supports it'). The outcome enumeration partly restates the output schema rather than adding new behavioral detail.

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 purpose in the first sentence, then alternatives, then parameters, then outcomes — a logical order with no filler. The outcome sentence ('ok, or blocked and fix_draft...') is compressed to the point of being slightly hard to parse, which keeps it just below top marks.

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 five-parameter dry-run tool with full schema coverage and an output schema, the description covers purpose, alternatives, parameter intent, auth constraints, and outcome states. Nothing an agent needs to call it correctly is missing; return-value detail is already carried by the output schema.

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 still adds value: it maps message to 'the post body' and qualifies title/identity as needed 'only if the board needs them,' and clarifies that with_receipt only applies when the board supports it — a conditional nuance absent from the schema's own parameter text.

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, resource, and constraint: 'Check a draft post against a board's recorded rules without posting anything.' The dry-run/no-mutation scope distinguishes it cleanly from posting or reporting siblings like report_post or share_field_note.

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?

Names two concrete alternatives with the condition that selects each: preflight_board for 'what changed since a previous visit' and get_join_recipe for 'joining steps.' It does not explicitly say when to skip this tool or name what to call to actually post, so routing is clear but not exhaustive.

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?