clef-mcp

Overview Schema Source Related Servers Discussions Admin

Decide

decide

Read-only

Classify, route, triage, moderate, or grade text, JSON, or images by asking an Ollama decision model structured choice, yes/no, or score questions in one call; it returns probabilities you can threshold.

Instructions

Ask an Ollama decision model to answer one or more structured questions about a state, in a single call. Answers are probabilities, never free text, so you can threshold them.

Inputs:

state: what to judge. Non-empty text, or a JSON object or array (sent as JSON text).
questions: map of question name to question. 1 to 64 questions. Names are 1-100 characters of ASCII letters, digits, "_", "." or "-".
images (optional): up to 4 images as raw base64 strings (no data: URLs, no http URLs).

Every question has a type, instructions (text, or a JSON object or array, explaining what to decide) and criteria:

choice: pick exactly one label. criteria is required: an object mapping 2-26 label keys to a description string or null. Answer: choice (the winning key), probabilities (one per key, summing to 1) and confidence (0-1).
noul: a yes/no judgement. criteria is optional: exactly {"false": "...", "true": "..."} describing each side. Answer: noul, the probability from 0 to 1 that the statement is true. It is not a boolean and has no confidence field.
score: place the state on an ordered scale. criteria is required: an array of 2-10 level descriptions ordered from lowest to highest. Answer: score, the probability-weighted mean of the zero-based level index (for example 1.84 on a 0-2 scale; not rounded), legend (index to description), probabilities (per index) and confidence (0-1).

Use it for classification, routing, triage, moderation and rubric grading. Do not use it to generate text.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "state": "<state>",
      "questions": "<questions>"
    },
    "name": "decide"
  }
}

Input Schema

Name	Required	Description
`state`	Yes	The input to judge: non-empty text, or a JSON object or array (sent as JSON text).
`images`	No
`questions`	Yes

Output Schema

Name	Required	Description	Default
`model`	Yes
`usage`	Yes
`answers`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint and openWorldHint, and the description goes well beyond them: it discloses hard limits (1-64 questions, up to 4 images, raw base64 only, no data: or http URLs), the thresholdable probability output, and type-specific answer shapes. It does not cover failure modes, latency/cost of the model call, or that images require a vision-capable model, which keeps it below 5.

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?

Front-loaded purpose sentence followed by a clearly bulleted Inputs section and a per-type breakdown, so scanning is easy. Slightly long and some lines duplicate schema constraints (character classes for question names), but nothing is filler prose.

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 deeply nested three-parameter tool this covers the nested union shapes well and even anticipates the common confusion that noul is a probability rather than a boolean. Since an output schema exists, the answer-field detail is redundant rather than necessary, and error/permission behavior for the model call is left unstated.

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?

At 33% schema description coverage the description must compensate, and it does: it explains state's accepted forms, the questions map's key rules, and critically the meaning of instructions and criteria per type (choice needs 2-26 labels, noul criteria optional with exactly false/true, score needs an ordered 2-10 level array). Some of this merely restates schema constraints (name pattern, min/max counts), but the semantic explanation of what each type decides is genuine added value.

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?

"Ask an Ollama decision model to answer one or more structured questions about a state, in a single call" names the specific verb, resource, and batching scope, and the follow-up sentence pins down the output nature (probabilities, not free text). An agent immediately knows this is a structured-judgment endpoint, not a chat/generation endpoint.

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?

Explicit positive cases ("classification, routing, triage, moderation and rubric grading") and an explicit exclusion ("Do not use it to generate text"). With no siblings present, there is no alternative tool to route to, so the when/when-not pair is sufficient.

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

decideA