ZeroWidth

Create a Caliper eval

caliper_evals_create

Binds a dataset + rubric to something under test as a repeatable eval — THE LAST SETUP STEP before scoring. Two targets: a Workbench flow (pass flowId; Caliper runs inference itself, then caliper_evals_run scores it), or 'external' (target: 'external'; the user's own model runs elsewhere and their script submits outputs through the public API, usually from CI — see the docs guide 'Run evals in CI'). For an external eval, hand back the eval id and tell the user to create a workspace API key with the ci_evals preset in their workspace settings; keys can't be minted from here. flowStage 'draft' evals the live draft (pre-publish); 'published' (default) evals the latest published revision at run time, or one pinned with flowRevisionId. Reuse an existing rubric from caliper_rubrics_list when one already scores this job.

Input Schema

Name	Required	Description
`title`	Yes	Eval name (2-120 chars).
`flowId`	No	Workbench flow id to evaluate. Required unless target is 'external'.
`target`	No	'workbench_flow' (default; needs flowId) or 'external' (the user's own model; outputs arrive through the public API).
`rubricId`	Yes	Rubric the judge scores with.
`datasetId`	Yes	Dataset of test items.
`flowStage`	No	Which stage to run against. Use 'draft' while iterating pre-publish. Default 'published'.
`workspace`	No	Workspace slug override.
`approvalId`	No	Approval id from a prior needs_confirmation response. Omit on the first call.
`scenarioId`	No	Workbench-flow evals: run every item as this scenario (one of the flow's, from workbench_flows_scenarios_list), so the flow's variables hold that person's values. A run can pick another with caliper_evals_run's scenarioId. Without one, variables run empty unless an item sets them.
`visibility`	No	Who can see it: PRIVATE (only the user), WORKSPACE (every member, the default), or SHARED (specific people, granted afterwards). Say 'make it private' → PRIVATE.
`description`	No
`externalLabel`	No	External evals only: what produces the outputs, e.g. 'CI' or 'prod pipeline'. Free text, shown on the eval.
`flowRevisionId`	No	Published-stage evals only: pin to one published revision (id from workbench_flows_revisions_list). Omit to always eval the latest published version at run time.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / scenarioId

Added value: +{
+  "description": "Workbench-flow evals: run every item as this scenario (one of the flow's, from workbench_flows_scenarios_list), so the flow's variables hold that person's values. A run can pick another with caliper_evals_run's scenarioId. Without one, variables run empty unless an item sets them.",
+  "type": "string"
+}

First observedOct 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare it a non-read-only, non-destructive write. The description adds real behavioral context beyond that: on an external eval the agent must return the eval id and instruct the user to mint a ci_evals API key in workspace settings because keys cannot be created here — a genuine auth prerequisite. It also explains that 'published' resolves the latest revision at run time unless pinned.

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-loads the core purpose and the two target modes, and the em-dash setup framing is efficient. It is dense but every clause (external key handoff, flowStage semantics, rubric reuse) contributes, though it runs long enough that a couple of clauses could be trimmed.

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 13-parameter mutation with no output schema, the description covers the decisive paths: target selection, stage semantics, and the external-key follow-up. It stops short of describing the approvalId confirmation flow or visibility defaults at the level the schema does, but nothing critical to correct invocation 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 92%, so the schema carries most parameter meaning and the baseline would be 3. The description still adds interpretation beyond the schema: flowStage draft vs published timing, the scenarioId-at-create vs run-time override relationship, and rubric reuse. This is a modest but real lift over an already well-described schema.

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 precise verb+resource ('binds a dataset + rubric to something under test as a repeatable eval') and positions it as a setup step before scoring, which cleanly distinguishes it from caliper_evals_run and caliper_evals_list. It also names the two supported targets, so the agent knows the shape of what it creates.

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?

Explicitly branches on target ('workbench_flow' with flowId vs 'external' via public API/CI), states flowStage 'draft' for pre-publish iteration vs 'published' default, and routes to caliper_rubrics_list when a rubric already exists. When/when-not and alternatives are all present.

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

All ZeroWidth tools Inspect

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

Need Help?