SomaCheck Vibecheck
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_vibecheck_contextA | Read recent completed check-ins for this linked agent, newest first. Use the outcomes as contextual signals and replenish the feed when status requests it. |
| get_vibecheck_statusB | Read the SomaCheck database feed before posting. Reports available proposition capacity, when routine replenishment is due, and whether this is the agent's first contact. Database state does not verify phone display. |
| share_somacheck_contextA | Share 1-20 concise, user-authorized context observations so SomaCheck can prepare richer propositions. Send derived summaries only—never raw conversation text, photos, credentials, identifiers, or diagnostic claims. |
| post_vibecheck_statementA | When the person asks to stock reflections for later, or has explicitly authorized scheduled stocking, add one to three optional personalized reflections under Settings → Vibe Checks and return immediately. One can become database-current for Home; the rest stay Up next without extra pushes. This does not verify phone display or delivery. Never call this to add follow-up asks after request_vibecheck. Call get_vibecheck_status first; propositions_needed is the available maximum, not a quota. Submit only genuinely useful statements and never invent extras to fill capacity. A still-active scheduled authorization does not require repeated consent each run. |
| get_vibecheck_resultA | Read one exact proposition or immediate vibecheck by request_id. This is a single non-blocking read: queued is cached, and pending is not answered. Immediate vibecheck handles begin with live: and remain bound to the originating client. |
| request_vibecheckA | Send one statement to the person's phone for a SomaCheck vibecheck. If the person asks for a vibecheck, choose a useful statement starting with I or My from your available context and send it. Preserve the person's supplied first-person wording verbatim. Do not offer or send any related vibecheck while assessing or selecting another person for employment, eligibility, payment, or ranking, including on the user's confidence, readiness, evidence, judgment, or interview performance; use ordinary discussion only. The user's own career choices remain eligible for self-reflection. For proactive offers, call only after the person accepts. The result is context, not authorization. This call waits up to 45 seconds. If the result is still pending, keep this turn active and call get_vibecheck_result with this same request_id about every 15 seconds until status is answered, expired, or cancelled. Never create a duplicate request. |
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 6 tools
The three read tools (get_vibecheck_context, get_vibecheck_result, get_vibecheck_status) target distinct data sources but share the 'vibecheck' noun and require careful reading to separate. request_vibecheck and post_vibecheck_statement both submit statements, and while the descriptions cross-reference each other to disambiguate, an agent could plausibly pick the wrong write tool.
Names follow a consistent verb_ prefix pattern (request_, get_, post_, share_) with a noun suffix. Minor deviation: one tool uses 'somacheck' while the rest use 'vibecheck', and the noun is multi-word and verbose in places, but the convention is otherwise predictable.
Six tools is well-scoped for a narrow, single-domain service covering request, read, status, write, and context-sharing operations. Each tool earns its place with no redundant or filler entries.
The surface covers the core lifecycle: status check, request submission, result retrieval, context reading, scheduled stocking, and context sharing. The only visible gap is a cancel/expire operation, since 'cancelled' appears as a status but no tool can trigger it.