Cue
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SUPABASE_KEY | No | Alias for SUPABASE_SERVICE_KEY. | |
| SUPABASE_URL | No | Project URL. | |
| OPENAI_API_KEY | No | Detection calls. | |
| SUPABASE_SERVICE_KEY | No | Must be the **service role** key — RLS is deny-by-default, so the anon key reads zero rows. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cue_statusA | Cue Active — AI Honesty Guardian. Confirms Cue is connected and monitoring this conversation for sycophancy and hallucination. Returns a status line instantly; makes no API calls and consumes no quota. |
| analyze_messageA | 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. |
| check_usageA | Show how many Cue honesty checks and prompt rewrites the user has left today, and which plan they are on. Consumes no quota. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a distinct role: analyze_message performs the core honesty check, cue_status confirms connectivity, and check_usage reports quota/plan. cue_status and check_usage are both lightweight informational tools that could be mildly confused at a glance, but their descriptions clearly separate connection status from usage quotas.
All three names use snake_case and read predictably, with analyze_message and check_usage following a verb_noun pattern. cue_status deviates slightly by prefixing the server name instead of using a verb, but the convention remains consistent and readable.
Three tools for a focused honesty-guardian server is reasonable: one core checking tool plus two zero-cost supporting tools. It is on the lean side, but every tool serves a purpose and none feels redundant.
The core lifecycle is covered: run a check, verify the service is active, and inspect remaining quota. The only minor gap is that check_usage references 'prompt rewrites' as a separate capability with no dedicated tool, though rewrites appear to be delivered through analyze_message output.