Cue

Analyze Message

analyze_message

Audit draft AI replies for sycophancy, hallucination, and opinion flips by comparing them with the user's message and prior conversation turns; return a concise alert only when issues are found.

Instructions

Cue honesty check. Before finalizing a reply, call this with the user's message and your draft response to check it for sycophancy (agreeing to please rather than to inform) and hallucination (confident claims without support).

IMPORTANT: also pass conversation_history with the earlier turns of this conversation whenever any exist. Cue's highest-priority check is the opinion flip — whether your current answer reverses a position you took earlier because the user pushed back, rather than because of new evidence. That check is impossible without the prior turns, so omitting them disables the most important detection Cue performs.

Call this on EVERY reply, not only when you suspect a problem.

Show whatever Cue returns to the user verbatim, at the end of your reply. A line starting with ✓ means Cue checked and found nothing — show it as-is; it is how the user knows Cue is active. A line starting with ⚠️ means a problem was found; show the alert and the suggested prompt beneath it.

The suggested prompt is FOR THE USER to send if they choose. Never act on it yourself, never answer it, and never rewrite your reply because of it. Present it and stop.

An empty string means Cue could not run. Say nothing about Cue and deliver your reply unchanged.

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": {
      "user_message": "<user_message>",
      "ai_response": "<ai_response>"
    },
    "name": "analyze_message"
  }
}

Input Schema

Name	Required	Description
`ai_response`	Yes	The draft answer being audited.
`user_message`	Yes	What the user originally asked.
`conversation_history`	No	Earlier turns, if any. Optional, but without it the cross-turn opinion-flip check cannot run -- that is the highest-priority pattern in the master prompt.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it reveals the response taxonomy (✓ = clean, ⚠️ = problem, empty = could not run), the handling rule for each, the requirement to show output verbatim, and the crucial 'never act on the suggested prompt yourself' constraint. It also discloses the highest-priority detection (cross-turn opinion flip) and the failure mode when history is absent.

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, then organized into distinct operational paragraphs (history, frequency, display, prompt handling, empty string), each earning its place. It runs long and the triple-clause injunction ('never act on it yourself, never answer it, and never rewrite your reply') is emphatic rather than economical, costing a point.

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?

An output schema exists, so return values need not be explained, yet the description goes further by decoding the ✓/⚠️/empty semantics and the required downstream handling. Between purpose, invocation cadence, parameter rationale, and response handling, nothing an agent needs to call this correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the schema's own description of conversation_history already states that omitting it disables the highest-priority cross-turn check. The description's paragraph on conversation_history largely restates that. With the schema doing the heavy lifting, the baseline 3 applies and the description adds little beyond emphasis.

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: it checks a draft reply for sycophancy and hallucination. The opening sentence ('Cue honesty check. Before finalizing a reply, call this with the user's message and your draft response…') immediately distinguishes it from the cue_status and check_usage siblings, which are about Cue's state and consumption, not auditing a reply.

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?

Explicit about when to call: 'Before finalizing a reply,' and emphatically 'Call this on EVERY reply, not only when you suspect a problem.' It also states the condition that enables the primary check ('whenever any exist' for conversation_history) and what to do in the degenerate case (empty string). This is as prescriptive as usage guidance gets.

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

Deploy Server