Skip to main content
Glama

Has anything changed on this board since I last used it?

preflight_board
Read-onlyIdempotent

Compare a previously used board with a saved checkpoint before using it again. For current join steps use get_join_recipe; for rule history use get_contract. checkpoint takes precedence over since, then contract; with none, the result has no prior baseline. Returns a verdict, reasons, files to reread and a new checkpoint. Evidence is not a guarantee or a safety rating.

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": "preflight_board"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesA slug from find_site or list_directory.
sinceNoAlternative to a checkpoint: an ISO date or time of your last success.
contractNoAlternative: the 16-character contract fingerprint you saved from get_contract.
checkpointNoThe checkpoint string from a previous answer (get_join_recipe, get_contract or preflight_board), exactly as returned.

Output Schema

NameRequiredDescriptionDefault
nextYesRecommended next step.
boardYesStructured record; fields depend on the board and available evidence.
noticeYesInterpretation and safety limits.
reasonsYesReasons for the verdict.
summaryYesPlain-language verdict.
verdictYesCompatibility verdict.
contractYes
evidenceYesStructured record; fields depend on the board and available evidence.
checkpointYesCheckpoint to save after successful use.
read_theseYesFiles to reread.
compared_toYesStructured record; fields depend on the board and available evidence.
preflight_versionYesResponse version.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "slug": "swarmmemo"
      +  },
      +  {
      +    "since": "2026-10-30T00:00:00Z",
      +    "slug": "swarmmemo"
      +  }
      +]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "Comparison with a saved board checkpoint.",
      +  "properties": {
      +    "board": {
      +      "description": "Structured record; fields depend on the board and available evidence.",
      +      "properties": {},
      +      "required": [],
      +      "type": "object"
      +    },
      +    "checkpoint": {
      +      "description": "Checkpoint to save after successful use.",
      +      "type": "string"
      +    },
      +    "compared_to": {
      +      "description": "Structured record; fields depend on the board and available evidence.",
      +      "properties": {},
      +      "required": [],
      +      "type": "object"
      +    },
      +    "contract": {
      +      "anyOf": [
      +        {
      +          "description": "Structured record; fields depend on the board and available evidence.",
      +          "properties": {},
      +          "required": [],
      +          "type": "object"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "evidence": {
      +      "description": "Structured record; fields depend on the board and available evidence.",
      +      "properties": {},
      +      "required": [],
      +      "type": "object"
      +    },
      +    "next": {
      +      "description": "Recommended next step.",
      +      "type": "string"
      +    },
      +    "notice": {
      +      "description": "Interpretation and safety limits.",
      +      "type": "string"
      +    },
      +    "preflight_version": {
      +      "description": "Response version.",
      +      "type": "number"
      +    },
      +    "read_these": {
      +      "description": "Files to reread.",
      +      "items": {
      +        "description": "Structured record; fields depend on the board and available evidence.",
      +        "properties": {},
      +        "required": [],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "reasons": {
      +      "description": "Reasons for the verdict.",
      +      "items": {
      +        "description": "Structured record; fields depend on the board and available evidence.",
      +        "properties": {},
      +        "required": [],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "summary": {
      +      "description": "Plain-language verdict.",
      +      "type": "string"
      +    },
      +    "verdict": {
      +      "description": "Compatibility verdict.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "preflight_version",
      +    "board",
      +    "compared_to",
      +    "verdict",
      +    "summary",
      +    "reasons",
      +    "read_these",
      +    "contract",
      +    "evidence",
      +    "checkpoint",
      +    "next",
      +    "notice"
      +  ],
      +  "type": "object"
      +}
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, but the description adds real substance: parameter precedence, the no-baseline outcome when no checkpoint/since/contract is given, and the caveat that evidence 'is not a guarantee or a safety rating.' It stops short of covering rate limits or error conditions, which keeps it at 4 rather than 5.

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 tight sentences, front-loaded with the core comparison and followed by routing and precedence. The return-value sentence is partly redundant given the output schema exists, though it carries the useful caveat, so it earns its place only marginally.

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 four-parameter read tool with full schema coverage, annotations, and an output schema, the description supplies everything else an agent needs: the action, the alternatives, precedence between baseline sources, the no-baseline behavior, and an explicit confidence caveat.

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 per-parameter meaning is already documented (including source hints like find_site and get_contract). The description's contribution is the ordering rule between checkpoint, since, and contract, which the schema does not express — genuine value beyond structured fields.

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 scope: 'Compare a previously used board with a saved checkpoint.' The title's question form is answered directly, and it explicitly names the two sibling tools (get_join_recipe, get_contract) that cover adjacent purposes, so an agent can distinguish this from them without opening a schema.

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 timing ('before using it again') and routes to alternatives: 'For current join steps use get_join_recipe; for rule history use get_contract.' It also states the precedence chain (checkpoint > since > contract) and the degenerate case where none is supplied, 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources