Leadpoet

Return a queued message to review

returnQueuedMessageToReview

Destructive

Stops one queued message before it sends and returns it to Review with its saved content for editing. Its approval is removed, so it needs a new approval before it can send. It is tied to the revision that was read; after a conflict, read it again before retrying.

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": {
      "params": "<params>"
    },
    "name": "returnQueuedMessageToReview"
  }
}

Input Schema

Name	Required	Description	Default
`body`	No
`params`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses the key side effects: approval is stripped and a fresh approval is required, and content is preserved for editing. It also surfaces optimistic-concurrency behavior via the revision/conflict note, though it omits permission or error-surface details.

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?

Three short sentences with the action, consequence, and conflict handling in that order — well front-loaded and free of filler. The final sentence is slightly opaque because no revision parameter appears in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It fully covers the state transition and approval consequences for a destructive mutation, which is the hardest information to infer. It is incomplete on the input contract, though: with no param documentation and no output schema, an agent still does not know what to pass or what a successful return looks like.

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?

Schema coverage is 0% and the description names neither messageId nor the optional body field, so it adds no meaning about what identifier to supply. The mention of 'the revision that was read' is not mapped to any visible parameter, which may even mislead about how conflicts are passed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (stops/returns) and resource (one queued message) plus the destination state (Review) with saved content for editing. It is clear in isolation, but it never distinguishes itself from close siblings like cancelQueuedMessage, skipMessage, or denyMessage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies the use case (pull a queued message back for editing rather than sending) and gives a real conditional workflow rule: after a conflict, re-read before retrying. However, it offers no guidance on when to choose this over cancelQueuedMessage or skipMessage, which an agent facing several queued-message tools needs.

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

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