Skip to main content
Glama

lu_verify_message

Replays message history against a protocol definition to validate whether the next message is allowed, returning validity, violation details, or expected step.

Instructions

Verify whether a message is valid in the context of an ongoing session.

Replays the existing message history against the protocol, then checks
whether next_message is the expected next step.

Args:
    protocol_text: Full .lu protocol definition text.
    messages: List of already-sent messages, each a dict with keys:
        sender (str), receiver (str), action (str).
        Actions are LU action names: "asks", "returns", "sends",
        "proposes", "tells". These match the verbs in .lu source files.
    next_message: The message to validate, same format as above.

Returns:
    JSON string:
      On success: {"valid": true, "step": N, "next_expected": "..."}
      On violation: {"valid": false, "violation": "...", "expected": "...", "got": "..."}
      On error: {"valid": false, "error": "..."}

Example:
    protocol_text = "protocol Ping:\n    roles: a, b\n    a asks b to ping\n    b returns pong to a\n    properties:\n        always terminates\n"
    messages = [{"sender": "a", "receiver": "b", "action": "asks"}]
    next_message = {"sender": "b", "receiver": "a", "action": "returns"}
    # Returns: {"valid": true, ...}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
protocol_textYes
messagesYes
next_messageYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

No annotations provided, so description carries full burden. It details the replay-and-check algorithm, parameter semantics, and full return format. It does not mention side effects, but as a verification tool, none are expected.

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?

Description is well-structured: purpose sentence, then detailed argument descriptions, return format, and example. Slightly lengthy due to example but front-loaded and each section earns its place.

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?

Given 3 required nested parameters with 0% schema coverage and an output schema described in text, the description provides complete information: argument formats, valid actions, return types, and a concrete example. An agent can invoke correctly.

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

Parameters5/5

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

Schema has 0% description coverage, but the description fully compensates by explaining each parameter: protocol_text is .lu protocol text, messages list with required keys, next_message same format, with example action values. Adds significant meaning beyond schema.

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 tool verifies if a message is valid given a protocol and message history, using verbs like 'verify' and 'replays'. It is distinct from siblings that check properties, list templates, or load protocols.

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 explains the context ('in the context of an ongoing session') and the process (replaying history, checking next step). It does not explicitly state when not to use or alternatives, but siblings are sufficiently different, making intended use clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rafapra3008/cervellaswarm'

If you have feedback or need assistance with the MCP directory API, please join our Discord server