Skip to main content
Glama

jev_rows

Qualify a table's rows with Jev ON THE SERVER: rows are read, judged and written back here, and no row data passes through you. Write the rubric; review the sample.

Each row's state_fields are sent with the same questions; each answer is written to its output column, its confidence to <column>_p (choice and score), and the model snapshot to model_column. A noul writes its probability; a score writes the expected level (e.g. 3.34). A row Jev can never answer as is (state too large, or refused upstream as too long) or whose answer the table refuses to store gets jev_error: <reason> in model_column. A row whose state fields are all empty is counted in empty_state and left undecided: fill it, then re-run. Missing output, <column>_p and model_column columns are created, typed from the questions (choice → enum of its criteria); existing ones are never changed. The key and the rubric are checked before anything is created or written.

Only undecided rows are taken (model_column empty) unless overwrite=true, so a re-run resumes and never pays twice. Rows leased by another run are skipped, and a row changed since it was read is never overwritten.

A whole table: background=true (after a dry run). The call returns a job_id at once and the server judges every matching row itself — no cursor loop, and a dropped connection doesn't stop it. Follow it with jev_job(op='status'), stop it with jev_job(op='cancel'). The key, the write right and the quota are checked again before every slice: a revoked key or a spent quota stops the job, and what was already judged stays written and billed. One active job per table and model_column. A job keeps _run_id and bills its slices under it.

Without background, one call judges what fits in its time window (~100 rows): loop on next_cursor until done, then finish with one pass WITHOUT cursor to pick up skipped rows. Nothing reserves rows between two calls: do not run two at once on the same rows.

Any other upstream refusal (key, credits, a malformed request) stops the batch: what was already judged stays written and billed, and the error says how much.

Run dry_run=true on known cases before a full run. Jev sees only the state and the questions: put client context (ICP, offer) in the criteria or the state. Rows with a thin state score low for lack of evidence (thin_state counts them). No bucketing here: thresholds belong to you. Validate fit against known outcomes before trusting it; combine Jev's answers with structured fields in plain code.

⚠️ Each state goes to a third party (OpenRouter, then TypeSafe). Billed on real cost, about 50 µ$ per row for 3 questions and a 500-character description.

Returns — {decided, jev_errors, empty_state, skipped_leased, skipped_changed, errors, error_count, low_confidence, thin_state, created_columns, next_cursor, remaining, done, cost, model, sample}. errors and sample name rows by _id with codes and what was written — never a value read from the table. dry_run returns rows (each judged row's _id and answers) and would_create_columns, and writes nothing. background returns {job_id, status, remaining, created_columns}.

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": {
      "datastore": "<datastore>",
      "questions": "<questions>",
      "state_fields": "<state_fields>",
      "output": "<output>",
      "model_column": "<model_column>"
    },
    "name": "jev_rows"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
limitNomax rows judged in this call (default and max 500; dry run max 20). Ignored with `background`: the job takes every matching row.
modelNoanother model id (default: the pinned dated snapshot).
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
cursorNo`next_cursor` from the previous call (not with `background`).
filterNo`data_rows` filter grammar.
outputYes`{question: column}`; choice → text/enum, score and noul → number. Missing columns are created.
_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.
dry_runNojudge and return, write nothing (still billed).
filtersNo`data_rows` multi-column clauses.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
parallelNorows in flight (default 25, max 50).
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
datastoreYesthe table number (ns_id) or `slot:<name>`.
overwriteNoalso re-judge rows that already have an answer.
questionsYesthe rubric, same shape and rules as `jev_ask`; `criteria` required.
backgroundNorun the whole table as a server job; returns a `job_id`.
model_columnYestext column for the model snapshot or `jev_error`; required (created if missing).
state_fieldsYescolumns to send, each a name or `{name: max_chars}`.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does: it discloses writes and column creation (existing columns never changed), per-row error handling via `jev_error`, leasing and changed-row protection, resume semantics, job-level key/quota re-checks, third-party data exposure (OpenRouter, TypeSafe) and approximate cost per row. Failure modes—partial writes stay billed, revoked key stops a job—are spelled out.

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 with the core operation and then organized by mode (row semantics, background job, cursor loop, errors, cost, returns). It is long but mostly earns its length; some duplication ('what was already judged stays written and billed' appears twice) and unexplained jargon like `noul` cost it a point.

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?

For a 19-parameter mutation tool with no annotations and no output schema, the description supplies a full return-key inventory, dry-run and background return shapes, error codes, and cost model. An agent can call it, paginate it, resume it, and interpret its results without further context.

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 schema baseline already documents each parameter; the description adds cross-parameter meaning the schema lacks, such as `background` ignoring `limit`/`cursor`, `dry_run` still billing and writing nothing, `output` typing rules per question type, and `state_fields` max_chars semantics. It stops short of explaining `parallel`, `filter`/`filters` grammar or `model` fallback behavior beyond the schema text.

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 in the first clause—'Qualify a table's rows with Jev ON THE SERVER'—and immediately names the key differentiator (no row data passes through the agent), which separates it from jev_ask and jev_items. The write-back targets (output column, `<column>_p`, `model_column`) make the effect concrete.

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 routing: use `dry_run=true` on known cases first, `background=true` for a whole table (after a dry run), `next_cursor` looping without background, `jev_job(op='status')`/`op='cancel'` to follow or stop a job. It even states a prohibition—'do not run two at once on the same rows'—and explains when overwrite is and is not applied (only undecided rows by default).

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.

Resources