Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

jev_ask

Ask Jev typed questions about one state and get answers with probabilities.

Jev is not a chat model: it returns a typed answer per question and nothing else — no prose, no justification, no tool calls. It pays off on BATCHES — many rows or profiles to triage with the same rubric (see jev_items). A single case you can judge yourself does not need Jev.

⚠️ The state is sent to a third party (OpenRouter, which passes it to TypeSafe): put in it only the fields the judgement needs, never a whole record or document.

Put the WHOLE rubric in one call: the questions of one call are answered in parallel, each extra question costs about 48 input tokens, and the state is charged once. They cannot see each other's answers, so a question that depends on another's answer needs a second call.

Returns — {model, answers, usage}: answers[name] is {type: "noul", noul: 0.96}, or {type: "choice", choice, probabilities, confidence}, or {type: "score", score, probabilities, legend, confidence}. model names the exact snapshot that answered — store it next to the answer, it is what makes a threshold reproducible. usage carries input_tokens, output_tokens (free) and cost in USD.

A probability near 0.5 means "as likely as not", never "medium": pick two thresholds and leave the band between them to a human or to a stronger model.

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": "jev_ask"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
modelNoanother model id (default: the pinned dated snapshot).
stateYeswhat Jev judges — a flat or nested object (`{"title": …, "company": …}`), at most 16 KB of JSON. Send the fields that matter, not the whole record: the state is billed per token.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
questionsYes`{name: {type, instructions, criteria}}`. `noul` — criteria `{"true": …, "false": …}`, both described; `choice` — one entry per option, each described; `score` — an ORDERED list of levels, low to high. `criteria` is required.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.9/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it discloses third-party data transmission (OpenRouter/TypeSafe) with a minimization warning, per-question token cost and that state is charged once, parallel non-communicating questions, and the exact return envelope including `usage.cost` and the `model` snapshot for reproducibility. It even explains how to read a ~0.5 probability.

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?

Front-loaded with the one-line purpose, then differentiation, then the privacy warning, then the return contract and interpretation guidance. Every block is dense and load-bearing, and the ⚠️ marker surfaces the highest-risk sentence.

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

Completeness5/5

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

With 8 parameters, nested objects, and no output schema, the description supplies what the structured fields cannot: the return shape per answer type, cost accounting, model-pinning for reproducible thresholds, and the 16 KB state guidance. Nothing an agent needs to call this correctly is missing.

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; the description still adds meaning beyond the schema by explaining that questions are answered in parallel and cannot see each other, and that each extra question costs about 48 input tokens while state is billed once. It does not elaborate on the `model` override or the `_org`/`_run_id` scoping params, which remain schema-only.

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?

States a specific verb and resource ('Ask Jev typed questions about one state and get answers with probabilities') and immediately characterizes what Jev is not ('not a chat model... no prose, no justification, no tool calls'). It also routes the agent away from itself for single cases and toward `jev_items` for batches, which separates it from its siblings.

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 when-to-use (many rows or profiles with the same rubric), explicit when-not ('A single case you can judge yourself does not need Jev'), and a named alternative (`jev_items`). It further tells the agent to put the whole rubric in one call and that cross-dependent questions require a second call.

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

All Tulina toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources