SomaCheck returns proposition-specific Aligned or Unaligned plus model confidence.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 6 tools
The read tools are separated by scope: get_vibecheck_status reports capacity, get_vibecheck_context returns recent completed check-ins, and get_vibecheck_result targets a specific request_id. post_vibecheck_statement and request_vibecheck are clearly distinct as scheduled stocking versus immediate sending, though context and status both read database state and could cause minor confusion.
All tool names are lowercase snake_case with a leading verb, and the read operations follow a consistent get_vibecheck_* pattern. The mix of vibecheck versus somacheck object nouns and the shorter request_vibecheck name are minor deviations but do not obscure the naming convention.
Six tools is well-scoped for a specialized SomaCheck workflow. Each tool has a distinct role: checking status, reading context, reading results, requesting an immediate check, posting scheduled statements, and sharing context.
The set covers the core immediate and scheduled vibecheck flows, including status checks, context sharing, and result polling. It lacks explicit tools to cancel, edit, or list queued statements, but the existing status and context tools provide enough workaround coverage for most agent flows.
Read recent completed check-ins for this linked agent, newest first. Replenish the feed when status requests it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| checkins | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful domain behavior—only 'completed' check-ins and ordering 'newest first'—but does not disclose additional operational traits like pagination, limits, or auth requirements; with annotations carrying the core behavior, a 3 is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and followed by the intended trigger. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read tool with readOnly/idempotent annotations and an output schema, the description covers what is read, the ordering, and when to call it. The only slight gap is that 'the feed' and 'status' are assumed domain vocabulary, but the core invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to add. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with an explicit verb and resource: 'Read recent completed check-ins for this linked agent, newest first.' This clearly identifies what the tool does and distinguishes it from siblings such as get_vibecheck_result and get_vibecheck_status, which suggest single-result or status reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Replenish the feed when status requests it' provides a concrete trigger for when to call the tool, but it does not explicitly name alternative tools or state when not to use them. This is clear context without exclusions, so 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The opaque request_id returned by post_vibecheck_statement or request_vibecheck. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| verdict | Yes | |
| latency_s | Yes | |
| confidence | Yes | |
| error_code | No | |
| expires_at | No | |
| request_id | Yes | |
| user_feedback | No | |
| delivery_state | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructiveHint, so the safety profile is covered. The description adds substantial behavioral context: 'single non-blocking read', queued vs. pending behavior, 'immediate vibecheck handles begin with live: and remain bound to the originating client', and the meaning of confidence. This goes well beyond the annotations and helps the agent anticipate system behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six sentences long, but each sentence carries distinct information: purpose, non-blocking behavior, live: semantics, output meaning, usage context, and confidence definition. It is front-loaded with the core purpose and avoids redundancy, though it could be slightly tightened by merging the last two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with a full input schema and an output schema present, the description is very complete. It explains the expected behavior for different request states, the nature of immediate vibechecks, the output semantics (Aligned/Unaligned and confidence), and how to use the result. Nothing essential is missing for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because request_id has a description, providing the baseline of 3. The description adds extra semantic value by noting that 'immediate vibecheck handles begin with live:' and by distinguishing queued vs. pending states, which give the agent a practical hint about what kind of request_id may be encountered and how the result behaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'one exact proposition or immediate vibecheck by request_id', which is specific. It implicitly distinguishes from siblings like get_vibecheck_status and get_vibecheck_context by focusing on a single result, but it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Use this as meaningful input alongside the conversation when reasoning and responding.' It also explains behavioral conditions, such as 'queued is cached, and pending is not answered,' which informs when results are available. However, it doesn't explicitly exclude alternatives or name sibling tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| linked | Yes | |
| cadence | Yes | |
| first_run_intro | Yes | |
| no_prior_requests | Yes | |
| recommended_action | Yes | |
| has_pending_request | Yes | |
| prior_request_count | Yes | |
| propositions_needed | Yes | |
| queued_proposition_count | Yes | |
| pending_proposition_count | Yes | |
| replenishment_requested_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by explaining that the tool reports a specific set of data points (capacity, replenishment due, first contact) and caveats that the database state does not verify phone display. Since annotations already declare readOnly, idempotent, and non-destructive hints, the description enriches the behavior by clarifying the scope and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place: the first states the usage context and purpose, the second lists the reported items, and the third clarifies a limitation. It is front-loaded with the key action ('Read... before posting') and succinctly covers necessary nuances without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully complete for a zero-parameter tool with a rich output schema and annotations. It explains what the tool does, what it reports, and its limitations. Nothing an agent needs to decide whether to invoke it is missing; the output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries the full burden of explaining what the tool provides. It details the meaning of the output, which is valuable given the output schema exists but the description adds context about the kind of status information offered. With no parameters, the description is complete in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a specific database feed (SomaCheck) and reports on three distinct aspects: available capacity, replenishment timing, and first-contact status. It distinguishes itself from siblings by focusing on the status of the database feed before posting, versus context, results, posting, or requesting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool before posting, indicating it is a preparatory read for other actions. It contrasts with the purpose of verifying phone display, implying it's not for display verification, and the sibling names suggest alternatives for context and posting. This clearly guides an agent on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| statements | Yes | Distinct personalized statements for this person to test, ordered most useful first. |
| Name | Required | Description |
|---|---|---|
| propositions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is a non-read-only, non-idempotent, non-destructive, closed-world write. The description goes well beyond that: it returns immediately, one statement may become database-current for Home while the rest remain Up next without extra pushes, and it does not verify phone display or delivery. It also discloses the capacity semantics of propositions_needed and consent behavior across runs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, and every subsequent sentence carries a distinct constraint (return behavior, non-verification, sibling prohibition, prerequisite, capacity semantics, consent). It is dense and slightly overpacked for a single-parameter tool, but there is essentially no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, and the description still covers timing, persistence side effects, prerequisites, sibling boundaries, and consent. For a mutation with moderate behavioral subtlety, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema coverage the baseline is 3, but the description adds real meaning: statements should be genuinely useful and distinct, propositions_needed is a maximum rather than a quota, and agents must not invent extras to fill capacity. This clarifies intent beyond the schema's minLength/minItems/maxItems constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete verb and resource: add one to three optional personalized reflections under Settings → Vibe Checks. It also explicitly names the sibling it must not be confused with (request_vibecheck), so an agent can route correctly. The purpose is embedded in a conditional clause rather than stated up front, which slightly blunts immediate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('when the person asks to stock reflections for later, or has explicitly authorized scheduled stocking'), an explicit prohibition ('Never call this to add follow-up asks after request_vibecheck'), and a prerequisite (call get_vibecheck_status first). It also clarifies that an active scheduled authorization removes the need for repeated consent. This is about as complete a when/when-not/alternatives statement as one could ask for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_vibecheck_result1 field changedOutput schema / properties / expires_atAdded value: +{
+ "anyOf": [
+ {
+ "format": "date-time",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}get_vibecheck_status2 fields changedOutput schema / properties / copy_guidanceRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "fallback": {
- "type": "string"
- },
- "framing": {
- "type": "string"
- },
- "policy": {
- "type": "string"
- }
- },
- "required": [
- "policy",
- "framing",
- "fallback"
- ],
- "type": "object"
-}Output schema / requiredPrevious value: -[
- "linked",
- "no_prior_requests",
- "prior_request_count",
- "has_pending_request",
- "pending_proposition_count",
- "queued_proposition_count",
- "propositions_needed",
- "replenishment_requested_at",
- "first_run_intro",
- "cadence",
- "recommended_action",
- "copy_guidance"
-]New value: +[
+ "linked",
+ "no_prior_requests",
+ "prior_request_count",
+ "has_pending_request",
+ "pending_proposition_count",
+ "queued_proposition_count",
+ "propositions_needed",
+ "replenishment_requested_at",
+ "first_run_intro",
+ "cadence",
+ "recommended_action"
+]get_vibecheck_result2 fields changedOutput schema / properties / delivery_stateAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "queued",
+ "processing",
+ "sent",
+ "failed",
+ "skipped"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / error_codeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "delivery_timeout",
+ "delivery_failed",
+ "delivery_skipped",
+ "delivery_unavailable",
+ "response_timeout"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}request_vibecheck1 field changedOutput schema / properties / error_code / anyOfPrevious 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"
+ }
+]get_vibecheck_contextget_vibecheck_resultget_vibecheck_statuspost_vibecheck_statementrequest_vibecheckshare_somacheck_contextCalibrated judgments for text: yes/no probabilities, picks from your options, or scores.
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
Explainable ambiguity signals for text. Submitted text is processed but never retained.
Sounding checks proposed decisions and returns structured proceed, revise, or pause assessments.
Add one secure layer between your agents and this server.