ToolsConnector
Jev
Score hundreds of rows or profiles with one rubric and get typed answers with probabilities, a yes or no, a choice or a point on a scale, from Claude or ChatGPT through Tulina's own MCP server.
Official site: typesafe.ai
What it can do
2 read
- 01Read
Typed answers with probabilities on one record, a yes or no, a choice among options or a position on a scale
- 02Read
Score a whole table in the background with one rubric, resumable, the confidence written next to each answer
Jev answers closed questions about a record you hand it, and nothing else: a yes or no with a probability, a choice among options, or a position on an ordered scale. No prose, no justification. It is built for the moment a process has three hundred companies or profiles and one rubric to run them through, where a chat model would write three hundred paragraphs and a person would read none of them. Put the whole rubric in one call, with only the fields the judgement needs, and every question is answered in parallel with a probability next to it.
A probability near one half means "as likely as not", never "medium", so a rubric is read with two thresholds: what is clearly in, what is clearly out, and a middle band that goes to a person or a stronger model. The answer names the exact model snapshot that gave it, which is what makes a threshold reproducible across runs. Only the input is billed, a table row costs a fraction of a cent, and a whole table can be judged in the background, slice by slice, with a job to follow and stop. The record goes to a third party to be judged, so a process sends the fields that matter and never a whole document.
Does Jev have an MCP server?
Jev is reached through Tulina's own MCP server, so the same connection that carries every other tool carries this one, in Claude and ChatGPT alike. It is a TypeSafe model served through OpenRouter: the key is an OpenRouter key with its own spend cap, set once for the workspace. A process asks one question of one record to tune its rubric, then sends the batch, then reads the answers and their probabilities back into the table it is working from, which is where the two thresholds and the middle band are applied.
Why through Tulina
The connection was never the hard part.
Most systems now publish their own way for a model to reach them, and that is good: it is what Tulina connects to. The hard part is deciding who may use it, what it is allowed to return, and what the model knows before it asks.
The keys stay in one place
YouTeamOrganisation
Connect Jev once. The credential is encrypted in a vault, never held in clear, and never pasted into a chat or a workflow file. A person uses their own key where they have one, their team's where they do not, the organisation's after that, so nobody is blocked and nobody holds more access than they need. Revoke it once and everything running on it stops.
What leaves is filtered before it leaves
fields droppedmasked or hashedpseudonymised
Roles decide who can reach Jev at all. Beyond that, a policy on the connector itself decides what comes back. The data is minimised at the source rather than after it has already reached a model.
Every call is on the record
whatwhowhen
Runs are logged for the organisation. That is what makes an automated action reviewable after the fact, and it is what a security review asks for first.
The run starts knowing your company
namingkey accountsdecisions
A direct connection gives a model access. It does not tell it how your company names things, which accounts matter, or what was decided last quarter. Tulina carries that across every tool, so the same request against Jev returns something usable instead of something generic.
