Skip to main content
Glama
devbux

subq-snap-mcp

by devbux
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Snap: decide (typed questions over a state)

snap_decide

Get typed, probabilistic answers to choice, score, and true/false questions about text, JSON, or images in one call, enabling routing, triage, moderation, and risk scoring.

Instructions

Ask SubQ's Snap decision model one or more typed questions (choice, score and/or noul) about a state in a single call. Returns typed answers with probabilities. The state may be text or structured JSON, and up to 4 images may accompany it; every question sees the state and every image.

Input Schema

NameRequiredDescriptionDefault
modelNoOptional Snap model id override (default: subq-snap-1.1).
stateYesThe situation to decide about: text, a JSON object, or a JSON array.
imagesNoUp to 4 images for this request. PNG, JPEG, or WebP, base64-encoded with no data: prefix; at most 4 MiB decoded each, 8 MiB in total. Every question in the request sees every image.
questionsYesMap of question name (up to 100 characters) to typed question; 1-128 questions. Each question has a type (choice | score | noul), instructions, and criteria: choice = object of option label -> description (string, structured object/array, or null; 2-255 options); score = array of 2-10 ordered level descriptions; noul = optional object of true/false descriptions. Instructions may be text or structured JSON.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.2
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / images / items / additionalProperties
      Removed value: -false
    • removedInput schema / properties / questions / additionalProperties / additionalProperties
      Removed value: -false
    • changedInput schema / properties / questions / additionalProperties / required
      Previous value: -[
-  "type"
-]New value: +[
+  "type",
+  "instructions"
+]
    • addedInput schema / properties / questions / propertyNames
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / properties / state / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  }
+]
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose that answers come back typed with probabilities (useful since there is no output schema) and that every question sees every image. It omits auth/model-selection behavior, cost or latency characteristics, and error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with the core action and return value front-loaded, then the inputs. No filler and nothing redundant that isn't contextual.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with nested question objects and no output schema, the description covers what the tool does and the nature of the response (typed answers with probabilities). The precise shape of returned answers is left unstated, which is the main remaining gap.

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 already spells out model override, state shapes, image constraints and question structure in detail. The description adds only mild restatement (text or structured JSON state, up to 4 images, shared visibility), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (ask/decide) and resource (SubQ's Snap decision model) with the question types enumerated, which implicitly distinguishes it from the single-type siblings snap_choice, snap_score and snap_noul. It doesn't explicitly say 'use this to batch mixed question types instead of the specialized tools,' so sibling differentiation is left partly to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'in a single call' hints that this is the batching variant of the sibling tools, and the listed question types imply it can replace combining snap_choice/snap_score/snap_noul. However, there is no explicit when-to-use/when-not statement or named alternative, so an agent must infer the routing rule.

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

Deploy Server

Other Tools