Skip to main content
Glama

AI SENSE Free Public Tools

Decide from rules or a model

decide
Read-only

Omit model or use rules for the existing yes_no, choice and scale rule engine with probability, confidence and action. Use model clef, nimble or tev1 for noul, choice and score questions with instructions and criteria. tev1 is the smallest and fastest, tested by its maker in English only, and suits short, direct questions. Model mode processes the submitted state and questions and returns structured answers without an automatic action or rule trace. Model requests allow up to 8 KiB of JSON, 3 KiB for tev1, 4 questions and 8 choices per question, and have their own usage limit of 60 per minute and 1000 per UTC day per IP. Refusals may carry Retry-After. Do not retry automatically. state holds the facts. For rules, each rule is {"if": condition, "weight": number}, where a condition tests a field of state with eq, ne, gt, gte, lt, lte, in, exists, prefix or contains, combined with any and not. Request and answer bodies are not stored by this API. Usage counters are stored. Do not send credentials or sensitive personal data. The full format is at https://aisense.no/free-public-api-decide-api-endpoint. No API key, no account and no sign up: call it directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoOptional. rules (default), clef, nimble or tev1. Unknown models are refused.
stateYesThe facts the rules test, or the input sent to the selected model.
questionsYes1 to 64 named rule questions, or up to 4 model questions under the default model limits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / model / description
      Previous value: -"Optional. rules (default), or a configured model such as clef. Unknown models are refused."New value: +"Optional. rules (default), clef, nimble or tev1. Unknown models are refused."
  2. Changed3 schema fields changed
    • addedInput schema / properties / model
      Added value: +{
      +  "description": "Optional. rules (default), or a configured model such as clef. Unknown models are refused.",
      +  "maxLength": 32,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / properties / questions / description
      Previous value: -"1 to 64 named questions."New value: +"1 to 64 named rule questions, or up to 4 model questions under the default model limits."
    • changedInput schema / properties / state / description
      Previous value: -"The facts the rules test."New value: +"The facts the rules test, or the input sent to the selected model."
  3. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations declare read-only, open-world, non-idempotent, but the description adds substantial context the annotations cannot: request/answer bodies are not stored while usage counters are, exact size limits (8 KiB, 3 KiB for tev1), question/choice caps, per-minute and per-day rate limits, Retry-After semantics, and a 'do not retry automatically' warning. This is exactly the kind of operational detail an agent needs.

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

Conciseness3/5

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

The content is valuable but delivered as a long, run-on block mixing modes, limits, rule syntax, and privacy notes without clear structure. It is front-loaded on the mode choice, but the density makes it harder to scan than necessary; some clauses could be tightened or grouped.

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 carries the return-value burden and does so partially, stating that model mode returns structured answers without an automatic action or rule trace. Combined with the rule format, limits, and no-key/auth info, an agent has enough to invoke correctly, though the exact response shape for rules mode is left to the linked docs.

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?

Schema coverage is 100% so the baseline is 3, but the description goes further by documenting the rule DSL: each rule is {"if": condition, "weight": number} with operators eq/ne/gt/gte/lt/lte/in/exists/prefix/contains combined via any and not, and clarifies that state holds the facts. That meaningfully enriches the otherwise opaque nested-object parameters.

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 names a specific verb (Decide) and clearly distinguishes two modes: the rules engine (yes_no, choice, scale) and model mode (clef, nimble, tev1). It explains what each mode does, though the opening sentence is dense and slightly awkward to parse. It does not name a sibling tool, but none of the listed siblings are near-neighbors for this capability.

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 gives explicit routing: omit model/use rules for the rule engine, use clef/nimble/tev1 for noul/choice/score questions with instructions and criteria. It even characterizes tev1 as smallest, fastest, English-only, suited to short direct questions. No explicit 'when not to use' or alternative tool is named, but the mode-selection guidance is strong.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.