SomaCheck Vibecheck

Request a Vibecheck

request_vibecheck

DestructiveIdempotent

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 concrete context about the current user or task; if no relevant context is available, ask a concise clarification before calling. Preserve the person's supplied first-person wording verbatim. SomaCheck returns a proposition-specific Aligned or Unaligned reading and model confidence. Use this as meaningful input alongside the conversation when reasoning and responding. Confidence describes the classifier’s uncertainty. 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. 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.

Input Schema

TableJSON Schema

Name	Required	Description
`statement`	Yes	One plain-language statement starting with I or My for the person to test. Preserve their supplied first-person wording verbatim. Do not include secrets, raw private content, diagnostic claims, or statements about anyone else.
`consent_basis`	Yes	Use user_requested_vibecheck when the person asks for a vibecheck. Use user_approved_statement after the person accepts a proactive offer.
`idempotency_key`	Yes	A new UUID for this logical ask. Reuse the same UUID only to retry the exact same statement; retries will not create another phone request.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`state`	Yes
`verdict`	Yes
`confidence`	Yes
`error_code`	Yes
`expires_at`	Yes
`request_id`	Yes
`user_feedback`	No
`cooldown_until`	Yes
`delivery_state`	Yes
`idempotent_replay`	Yes
`continuation_transport`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 14, 2026

changedOutput schema / properties / error_code / anyOf

Previous value: -[
-  {
-    "enum": [
-      "link_revoked",
-      "upgrade_required",
-      "setup_required",
-      "request_conflict",
-      "vibecheck_pending",
-      "rate_limited",
-      "live_ask_unavailable",
-      "backend_unavailable",
-      "connection_failed"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "delivery_timeout",
+      "delivery_failed",
+      "delivery_skipped",
+      "delivery_unavailable",
+      "response_timeout",
+      "link_revoked",
+      "upgrade_required",
+      "setup_required",
+      "request_conflict",
+      "vibecheck_pending",
+      "rate_limited",
+      "live_ask_unavailable",
+      "backend_unavailable",
+      "connection_failed"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

First observedSep 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses the 45-second wait, pending status handling, idempotency semantics (never duplicate request), confidence interpretation, and the Aligned/Unaligned return readings. These go well beyond the annotations, adding essential runtime behavior without contradicting destructiveHint or idempotentHint.

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?

The description is long but every clause adds necessary constraints or usage context, and it is logically organized into action, selection, restrictions, and polling. It could be tightened slightly, but remains well-structured and non-redundant.

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?

Covers every aspect needed to invoke correctly: purpose, statement selection, consent, idempotency, clarification fallback, polling flow, prohibited use cases, and expected response meaning. With the output schema present, nothing an agent needs is missing.

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?

The schema already covers all three parameters at 100%, and the description enriches them further: statement selection guidance (I/My from context, verbatim preservation), consent_basis usage mapping to user-requested vs proactive, and idempotency_key reuse only for exact retries. This exceeds the schema's own property descriptions.

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 states a specific action ('Send one statement to the person's phone') and target (SomaCheck vibecheck), and clearly differentiates from sibling tools (get_vibecheck_result, get_vibecheck_status, post_vibecheck_statement) by focusing on initiating a request rather than retrieval or submission.

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?

Explicitly specifies when to call (person asks or proactive offer after acceptance), how to choose a statement (I/My from concrete context, ask clarification if absent), and when not to call (during employment/eligibility decisions). Also details the polling flow with get_vibecheck_result every 15 seconds while pending.

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

All SomaCheck Vibecheck 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?