How do I use subq-snap-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@subq-snap-mcp Choose the best category for this ticket: billing, technical, or account." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

subq-snap-mcp

by devbux

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

subq-snap-mcp

A standard Model Context Protocol (MCP) server that exposes SubQ's Snap decision model as typed tools — publishable to npm and runnable anywhere with npx or bunx.

npx -y @devbux/subq-snap-mcp

What is Snap?

Snap is SubQ's decision model (currently subq-snap-1.1, public preview). It never generates prose. Instead, you give it:

a state — a situation described as text or structured JSON,
up to 4 images to evaluate alongside the state, and
a set of typed questions about that state,

and Snap returns typed answers with probabilities:

Question type	You define	Snap returns
`choice`	2–255 labelled options (each with an optional description)	the chosen option, a confidence value, and a probability for every option
`score`	an ordered scale of 2–10 level descriptions	a probability-weighted score (it can fall between levels), the level legend, confidence, and per-level probabilities
`noul`	a proposition (optionally with true/false descriptions)	a probability (0..1) that the proposition is true

Because the output is structured and probabilistic rather than free text, Snap is well suited to routing, triage, moderation, risk scoring, prioritisation, and any other "decide, don't chat" step inside an agent workflow. One call can ask up to 128 questions, and every question sees the same state and every image.

Scope: this server wraps SubQ's Decisions API and Models API. The separate subq-preview chat model (Chat Completions / Responses APIs, structured outputs, function calling) is not a decision model and is out of scope here.

Related MCP server: jev

Requirements

Node.js >= 18 (or Bun) to run the server.
A SubQ API key (see Getting an API key).

Install & run

The server speaks MCP over stdio, so you normally don't run it by hand — your MCP client launches it. The commands below are how clients (or you, for a quick smoke test) start it.

npx (Node)

SUBQ_API_KEY=your-key npx -y @devbux/subq-snap-mcp

bunx (Bun)

SUBQ_API_KEY=your-key bunx @devbux/subq-snap-mcp

Global install (npm)

npm install -g @devbux/subq-snap-mcp
SUBQ_API_KEY=your-key subq-snap-mcp

Global install (Bun)

bun add -g @devbux/subq-snap-mcp
SUBQ_API_KEY=your-key subq-snap-mcp

The server starts even when SUBQ_API_KEY is not set, so clients can still list its tools; each tool call then returns a clear error naming the missing variable instead of crashing.

Getting an API key

Create an API key in your SubQ account (see docs.subq.ai), then expose it to the server as the SUBQ_API_KEY environment variable. Never commit your key to source control.

MCP client configuration

Generic (`mcpServers` JSON)

Most MCP clients (Claude Desktop, and many others) accept a configuration like this — see also examples/mcp-config.json:

{
  "mcpServers": {
    "subq": {
      "command": "npx",
      "args": ["-y", "@devbux/subq-snap-mcp"],
      "env": {
        "SUBQ_API_KEY": "YOUR_SUBQ_API_KEY"
      }
    }
  }
}

Using Bun instead:

{
  "mcpServers": {
    "subq": {
      "command": "bunx",
      "args": ["@devbux/subq-snap-mcp"],
      "env": {
        "SUBQ_API_KEY": "YOUR_SUBQ_API_KEY"
      }
    }
  }
}

Claude Code

claude mcp add subq \
  -e SUBQ_API_KEY=YOUR_SUBQ_API_KEY \
  -- npx -y @devbux/subq-snap-mcp

Cursor / VS Code

Cursor and VS Code use the same mcpServers JSON shape above (Cursor: .cursor/mcp.json or Settings → MCP; VS Code: .vscode/mcp.json uses a top-level "servers" key with the same per-server fields). Paste the generic config and replace the placeholder key.

Configuration

Environment variable	Default	Description
`SUBQ_API_KEY`	(unset)	Bearer API key for the SubQ API. Required for tool calls; the server still starts without it.
`SUBQ_BASE_URL`	`https://api.subq.ai`	Base URL of the SubQ API.
`SUBQ_SNAP_MODEL`	`subq-snap-1.1`	Snap model id to request. Can be overridden per call with the tools' optional `model` argument. Use `snap_list_models` to see what your key can access.

Tools

All tools return the SubQ API response as JSON text content. Errors (missing API key, HTTP 400/401/402/403/422/429/5xx, network failures, timeouts) are returned as MCP tool errors (isError) with a clear message that includes the HTTP status and the API's own error detail — never your API key.

Tool	Inputs	Output
`snap_decide`	`state` (string \| JSON object \| JSON array), `questions` (map of name → typed question, 1–128), optional `images`, `model`	All answers in one call: `{ model, answers, usage }`
`snap_choice`	`state`, `instructions`, `options` (object: label → description or `null`, 2–255), optional `images`, `model`	One Choice answer under the name `answer`
`snap_score`	`state`, `instructions`, `levels` (array of level descriptions, 2–10, ordered low → high), optional `images`, `model`	One Score answer under the name `answer`
`snap_noul`	`state`, `instructions`, optional `criteria` (`{ "true": ..., "false": ... }` descriptions), optional `images`, `model`	One Noul answer (probability 0..1) under the name `answer`
`snap_list_models`	(none)	`{ object: "list", data: [{ id, name, object, created, owned_by }] }`

Question shapes for `snap_decide`

{
  "type": "choice",
  "instructions": "Which team should own this chat?",
  "criteria": { "nurse_line": "Needs a nurse today", "front_desk": null }
}

{
  "type": "score",
  "instructions": "How soon should someone respond?",
  "criteria": ["Within a week", "Within a day", "Within an hour"]
}

{
  "type": "noul",
  "instructions": "Should a nurse see this chat first?"
  // "criteria" is optional for noul and omitted when not provided
}

instructions and criteria accept structured JSON (objects/arrays) as well as strings, so a criterion can carry the data it is judged against.

Images

Any decision tool accepts an optional images array. Each image is an object with a mediaType (image/png, image/jpeg, or image/webp) and the file bytes as one line of base64 (no data: prefix — URLs and data: URLs are rejected by the API). Every question in the request sees every image, alongside the state.

{
  "state": "The number row stopped working.",
  "images": [{ "mediaType": "image/jpeg", "base64": "<base64 of the photo>" }],
  "questions": {
    "shows_keyboard": {
      "type": "noul",
      "instructions": "Does the photo show a keyboard?"
    }
  }
}

Limits from the SubQ docs:

At most 4 images per request; each at most 4 MiB decoded, and 8 MiB decoded in total. The request body can be up to 13 MiB.
The image bytes must match the declared mediaType, or the API fails the request with 422. This server checks the count, the base64 shape, and the decoded sizes before sending, so those mistakes come back as clear local errors.
Each image uses roughly 64–256 image tokens (not the base64 text), counted toward the model's 384K-token context window together with the request text.
Video is not supported; sample up to 4 frames and send them as images.
Note: SubQ stores decisions together with their images, under SubQ's data-retention policy.

Worked example

An employee reports a broken keyboard and attaches a photo. In one snap_decide call you can check the photo, classify the device, and grade its wear:

Request (tool snap_decide):

{
  "state": "The number row stopped working.",
  "images": [{ "mediaType": "image/jpeg", "base64": "<base64 of the photo>" }],
  "questions": {
    "shows_keyboard": {
      "type": "noul",
      "instructions": "Does the photo show a keyboard?",
      "criteria": {
        "true": "A keyboard is the main object",
        "false": "No keyboard is visible"
      }
    },
    "layout": {
      "type": "choice",
      "instructions": "Which keyboard layout is in the photo?",
      "criteria": {
        "full_size": "Desktop keyboard with a numeric keypad",
        "tenkeyless": "Desktop keyboard with no numeric keypad",
        "laptop": "Built into a laptop",
        "not_a_keyboard": null
      }
    },
    "wear": {
      "type": "score",
      "instructions": "How worn does the keyboard look?",
      "criteria": ["Looks new", "Everyday wear", "Replace it"]
    }
  }
}

Response (shape; exact values come from the live model):

{
  "model": "subq-snap-1.1",
  "answers": {
    "shows_keyboard": { "type": "noul", "noul": 0.98 },
    "layout": {
      "type": "choice",
      "choice": "tenkeyless",
      "probabilities": { "full_size": 0.04, "tenkeyless": 0.9, "laptop": 0.05, "not_a_keyboard": 0.01 },
      "confidence": 0.9
    },
    "wear": {
      "type": "score",
      "score": 1.35,
      "legend": { "0": "Looks new", "1": "Everyday wear", "2": "Replace it" },
      "probabilities": { "0": 0.15, "1": 0.55, "2": 0.3 },
      "confidence": 0.72
    }
  },
  "usage": { "input_tokens": 210, "output_tokens": 0 }
}

Pricing note: you pay only for input tokens (output_tokens is always 0); Snap is $0.04 per million input tokens at the time of writing.

Development

git clone https://github.com/devbux/subq-snap-mcp.git
cd subq-snap-mcp

npm install
npm run dev        # run the server from source with tsx (stdio)
npm run typecheck  # tsc --noEmit
npm test           # vitest (fake fetch — no live network calls)
npm run build      # bundle to dist/index.js with tsup
npm start          # run the built server

Project layout:

src/
  index.ts       stdio bootstrap
  server.ts      MCP server + the five snap_* tools (zod-validated)
  config.ts      environment parsing (SUBQ_*)
  snap/
    client.ts    typed SnapClient for POST /v1/systemone and GET /v1/models
    types.ts     request/response types for the SubQ API
test/
  client.test.ts SnapClient + config unit tests

Publishing

Releases are published to npm by the Publish to npm GitHub Action (.github/workflows/publish.yml):

Bump the version in package.json, update CHANGELOG.md, and push.
Create a GitHub Release for the new version tag (or run the workflow manually with workflow_dispatch).
The workflow runs typecheck, tests, and build, then publishes with npm publish --provenance --access public.

Notes:

The workflow expects an NPM_TOKEN repository secret (an npm automation token for an account/organisation that owns the @devbux scope) in this repository's settings.
Provenance is enabled (id-token: write permission + --provenance), so each published version is linked to its GitHub Actions build.
This is a scoped package (@devbux/subq-snap-mcp); publishConfig.access is set to public in package.json so releases are publicly installable.
prepublishOnly also runs typecheck, tests, and build for manual publishes.

License

Available Tools

5 tools

snap_choiceSnap: choice questionA

Ask SubQ's Snap decision model a single Choice question: pick one of 2-255 labelled options for a state. Returns the chosen option, a confidence value, and a probability for every option, under the question name "answer".

Name	Required	Description
`model`	No	Optional Snap model id override (default: subq-snap-1.1).
`state`	Yes	The situation to decide about: text, a JSON object, or a JSON array.
`images`	No	Up 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.
`options`	Yes	Object mapping each option label to a description (string, structured object/array, or null; 2-255 options).
`instructions`	Yes	What Snap should decide: plain-language text, or structured JSON.

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does usefully disclose the return shape (chosen option, confidence, per-option probabilities under the key 'answer'), but says nothing about determinism, cost, rate limits, or failure behavior for a model-inference tool.

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?

A single economical sentence with zero waste, front-loading the action and resource before the return contract. Every clause earns its place.

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?

With no output schema, the description correctly explains the return values and the answer key, and the schema fully documents the five parameters including nested image constraints. Minor gaps remain around usage differentiation and model behavior, but the essential calling information is complete.

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%, so the schema already documents state, instructions, options, images, and model. The description adds the 2-255 option-count constraint but otherwise repeats what the schema provides; 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 and resource: ask the Snap decision model a single Choice question and pick one of 2-255 labelled options. The word 'single' and 'Choice' implicitly distinguish it from multi-question or scoring siblings, but no sibling is named explicitly.

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?

Usage is only implied by the phrase 'single Choice question'; there is no explicit when-to-use, when-not, or routing to snap_decide or snap_score. An agent must infer the choice between siblings from names alone.

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

snap_decideSnap: decide (typed questions over a state)A

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.

Name	Required	Description
`model`	No	Optional Snap model id override (default: subq-snap-1.1).
`state`	Yes	The situation to decide about: text, a JSON object, or a JSON array.
`images`	No	Up 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.
`questions`	Yes	Map 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.

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.

snap_list_modelsSnap: list available modelsA

List the model IDs available to the configured SubQ API key (GET /v1/models, OpenAI-compatible shape). Use a returned id with the endpoint that supports that model; the Decisions tools in this server need a decision model such as subq-snap-1.1.

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and discloses that this is a GET to /v1/models scoped to the configured API key and returns an OpenAI-compatible model list. It does not mention error behavior, rate limits, or authentication failure modes, but it provides solid context for a read-only discovery tool.

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 two sentences and front-loads the primary purpose. The second sentence is slightly compressed but earns its place by connecting returned IDs to downstream model usage.

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?

There is no output schema, so the description must explain what comes back; it does so by saying the tool returns model IDs in an OpenAI-compatible shape. For a zero-parameter listing tool, this is nearly complete, with only minor gaps around error or empty-list behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. The description does not explicitly say no inputs are required, but the empty schema makes that clear and there are no parameter semantics to compensate for.

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 gives a specific verb and resource: list model IDs available to the configured SubQ API key, with the backing endpoint (GET /v1/models) and response shape (OpenAI-compatible). It also differentiates this tool from the Decisions siblings by noting that those tools need a decision model such as subq-snap-1.1.

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

Usage Guidelines4/5

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

It states the intended flow: call this tool to discover model IDs, then use a returned id with the endpoint that supports that model, and it calls out that the Decisions tools require a decision model such as subq-snap-1.1. It does not explicitly state when not to use it, but the usage context is clear.

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

snap_noulSnap: noul question (yes/no probability)A

Ask SubQ's Snap decision model a single Noul question: is a proposition about a state true? Returns a calibrated probability (0..1) under the question name "answer".

Name	Required	Description
`model`	No	Optional Snap model id override (default: subq-snap-1.1).
`state`	Yes	The situation to assess: text, a JSON object, or a JSON array.
`images`	No	Up 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.
`criteria`	No	Optional descriptions keyed by "true" / "false" explaining what each outcome means. Values may be strings, structured objects/arrays, or null.
`instructions`	Yes	The proposition Snap should assess: plain-language text, or structured JSON.

TDQS

A3.6/5.0

Behavior3/5

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

No annotations, so the description carries the burden, and it does disclose the return shape: a calibrated probability in 0..1 keyed under "answer" — valuable since there is no output schema. It says nothing about model defaults, cost, latency, error behavior, or whether batching is possible.

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?

Two sentences, front-loaded with the action, then the return contract. No filler and nothing repeated from structured fields.

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?

Given five parameters, nested object/array inputs, and no output schema, the description supplies the missing return-value contract and the yes/no scope. It leaves out only secondary behavioral context such as default model behavior and image handling, which the schema mostly covers.

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%, so the schema already documents every parameter including model override, images limits, and criteria keys. The description's phrase 'a proposition about a state' adds only a light conceptual gloss and no format or constraint detail beyond the schema.

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 and resource: ask the Snap decision model a single yes/no Noul question about whether a proposition on a state is true. The word 'single' implicitly separates it from sibling multi-question tools like snap_choice, but no sibling is named explicitly.

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?

Usage is only implied by 'single Noul question' and the yes/no framing. With four siblings (snap_decide, snap_choice, snap_score, snap_list_models) in the catalog, an explicit 'use snap_choice for multi-option, snap_score for grading' statement is missing.

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

snap_scoreSnap: score questionA

Ask SubQ's Snap decision model a single Score question: rate a state on an ordered scale of 2-10 levels you define. Returns a probability-weighted score (it can fall between levels), the level legend, per-level probabilities, and a confidence value, under the question name "answer".

Name	Required	Description
`model`	No	Optional Snap model id override (default: subq-snap-1.1).
`state`	Yes	The situation to rate: text, a JSON object, or a JSON array.
`images`	No	Up 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.
`levels`	Yes	Ordered level descriptions, lowest to highest (2-10). Each level may be a string or a structured entry.
`instructions`	Yes	What Snap should rate: plain-language text, or structured JSON.

TDQS

A3.8/5.0

Behavior4/5

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

No annotations are present, so the description must carry behavioral context. It does well by describing the returned probability-weighted score that may fall between levels, the level legend, per-level probabilities, and confidence under 'answer'; it does not cover limits, model defaults, or error behavior.

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?

Two tight sentences with the action and return value front-loaded; no repeated or filler content.

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?

With no output schema, the description usefully explains the return payload and the between-level scoring semantics. It remains complete for core invocation, with the main gap being routing guidance against sibling Snap tools.

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%, so the schema already documents state, instructions, levels, images and model. The description reinforces the ordered scale and rating target but adds little parameter detail beyond the schema.

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?

The description states a specific verb and resource: ask the Snap model a single Score question and rate a state on a user-defined ordered scale. It clearly separates scoring from a generic decision, though it does not explicitly name sibling tools or state when to choose snap_score over snap_choice/snap_decide.

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?

Usage is implied by 'single Score question' and the 2-10 ordered levels, which suggests an ordinal rating task. However, the description gives no explicit when-to-use/when-not rules and does not mention alternatives such as snap_choice or snap_decide.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.2Oct 27, 2026

Changedsnap_choice6 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / images / items / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / instructions / anyOf

Previous value: -[
-  {
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / options / additionalProperties / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / options / 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"
+  }
+]

Changedsnap_decide6 fields changed

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"
+  }
+]

Changedsnap_noul6 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / criteria / additionalProperties / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / criteria / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
removedInput schema / properties / images / items / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / instructions / anyOf

Previous value: -[
-  {
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

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"
+  }
+]

Changedsnap_score5 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / images / items / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / instructions / anyOf

Previous value: -[
-  {
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / levels / items / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "additionalProperties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

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"
+  }
+]

5 tool updatesv0.1.0Oct 23, 2026
- First observedsnap_choice
- First observedsnap_decide
- First observedsnap_list_models
- First observedsnap_noul
- First observedsnap_score

Deploy Server

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

TDQS

A3.9/5.0

Scored 2026-10-27 08:40 across 5 tools

Disambiguation4/5

The three single-type tools target distinct question types, but snap_decide is effectively a superset that can also answer choice, score, or noul questions. The descriptions clarify the single-vs-multi-question distinction, but this overlap leaves some room for misselection.

Naming Consistency5/5

All tools share the snap_ prefix and use consistent snake_case verb/noun naming, such as snap_choice, snap_score, and snap_list_models. The domain term noul is unusual but used consistently as a question type.

Tool Count5/5

With only five tools, the surface is tightly scoped to the decision-model purpose: one general multi-question tool, three single-question conveniences, and model discovery. There is no tool bloat and the set stays easy to scan.

Completeness4/5

The set covers the core decision primitives (choice, score, noul), multi-question calls, and listing available models. Minor gaps exist around batch evaluation across multiple states or richer model metadata, but the main workflows are covered.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Seb Labs A
dev.seblabs
Typed AI decisions for agents: classify, route, screen evidence, score and batch-label text.
AI & Machine Learning Autonomous Agents
51
https://mcp.seblabs.dev/mcp
Hunch A
app.hunchsheet
Calibrated judgments for text: yes/no probabilities, picks from your options, or scores.
AI & Machine Learning
81
https://hunchsheet.app/mcp/try
ARBITER A
fyi.grip
Deterministic contextual decision arbitration and action routing for autonomous software. Takes current state, context, or intent plus caller-supplied candidate actions, state transitions, routes, refusals, escalations, tools, or models and returns a deterministic ordered candidate field. Also provides persistent machine representations for memory, retrieval, indexing, and downstream coherence measurement.
Agent Orchestration Autonomous Agents Knowledge & Memory
21
https://api.grip.fyi/mcp
DatagoatOAuth
io.datagoat
Governed decision engine: yes/no, score, choice and rank answers about cases, from past outcomes.
Product Management Research & Data
1
https://api.datagoat.io/mcp

Related MCP Servers

jev-mcp
AI & Machine Learning Autonomous Agents
blakestone-x
A
license
A
quality
D
maintenance
Enables agents to perform typed judgments—classify, score, check, match, and screen—over closed answer sets with confidence scores, without text generation.
Updated a month ago (2026-09-16 20:49 UTC)
7
25
MIT
jev
AI & Machine Learning Autonomous Agents
nandansrikrishna
A
license
Not graded
quality
C
maintenance
Enables agents to evaluate single records or batches with dynamically authored typed questions, returning structured decisions and probabilities.
Updated a month ago (2026-09-19 00:38 UTC)
25 PyPI
MIT
Jev MCP Server
AI & Machine Learning Developer Tools
MattiooFR
A
license
A
quality
A
maintenance
Enables MCP clients to classify, score, and evaluate content with structured typed decisions via a single generic tool.
Updated 6 days ago (2026-10-21 08:13 UTC)
1
15 npm
2
MIT
jevjam
AI & Machine Learning Autonomous Agents
beremaran
A
license
Not graded
quality
A
maintenance
Enables agents and services to ask small decision models typed questions about text, JSON, images, or video, returning labels, scores, or yes/no answers over MCP tools or a Jev-compatible HTTP API.
Updated 23 days ago (2026-10-04 13:33 UTC)
Apache 2.0

subq-snap-mcp

What is Snap?

Requirements

Install & run

npx (Node)

bunx (Bun)

Global install (npm)

Global install (Bun)

Getting an API key

MCP client configuration

Generic (mcpServers JSON)

Claude Code

Cursor / VS Code

Configuration

Tools

Question shapes for snap_decide

Images

Worked example

Development

Publishing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Generic (`mcpServers` JSON)

Question shapes for `snap_decide`