Skip to main content
Glama
okareo-ai

Okareo MCP Server

Official
by okareo-ai

Create or Update Check

create_or_update_check
Idempotent

Create or update a named quality check (upsert) for model-based, code-based, or audio evaluation, with pass/fail, score, or analysis output types.

Instructions

Create or update a quality check by name (upsert). Supports model-based, code-based, and audio checks.

    Saving to an existing name creates a new version of that check (see
    get_check's "available_versions"). Before writing a prompt_template or
    code_contents from scratch, fetch a worked example with get_templates:
    "boolean_check_prompt", "score_check_prompt", "analysis_check_prompt",
    or "check_code".

    Args:
        name: Unique name for the check.
        description: What the check evaluates.
        check_type: "model" (an LLM judge driven by prompt_template) or
            "code" (a deterministic Python class in code_contents).
        output_type: "pass_fail" (boolean verdict), "score" (numeric, e.g.
            a 1-5 rubric), or "analysis" (free-form qualitative feedback;
            only valid with check_type="model"). For check_type="code" the
            server infers pass_fail vs score from the value evaluate()
            returns (bool vs int/float) — output_type is used only to
            validate the request, not sent to the server. Note: list_checks
            and get_check report this as output_data_type in the server
            vocabulary, where "bool" means pass_fail and "int" means score.
        prompt_template: Required when check_type="model". The judge
            prompt. Inject the runtime data the judge needs with these
            placeholders:
            - {model_output}: the model output being evaluated. In a
              multi-turn conversation this is ONLY the final assistant
              message, not the full conversation.
            - {scenario_input}: the scenario input / source text.
            - {scenario_result}: the reference/expected output.
            - {model_input}: what was sent to the model (prompt or
              messages).
            - {message_history}: the full multi-turn conversation — the
              model_input messages plus the assistant's model_output. Use
              this when the check must judge the whole conversation.
            - {tool_calls}: the tool/function calls the model just made.
            - {tools}: the tool definitions/schema available to the model.
            - {model_output_metadata}: metadata attached to the most
              recent model output.
            - {simulation_message_history}: full conversation history
              reconstructed from trace metadata. Only populated for traced
              (ingested) conversations; for simulations and evaluations
              use {message_history}.
            The legacy {generation} placeholder is deprecated — use
            {model_output} instead.
        code_contents: Required when check_type="code" (output_type
            "pass_fail" or "score" only). Python source defining
            `class Check(CodeBasedCheck)` with a
            `@staticmethod def evaluate(...) -> CheckResponse` method.
            Start from `from okareo.checks import CodeBasedCheck,
            CheckResponse`. evaluate() may declare any subset of these
            parameters: model_output, scenario_input, scenario_result,
            metadata, model_input. Return CheckResponse(score=...,
            explanation=...) where score is a bool for pass_fail or an
            int/float for score. See get_templates("check_code") for
            complete examples.
        is_audio: Set to true for audio/voice evaluation. Only valid with
            check_type="model".
        tags: Optional list of string tags to organize the check. Tags are
            stored with the check and returned by get_check.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
tagsNo
is_audioNo
check_typeYes
descriptionYes
output_typeYes
code_contentsNo
prompt_templateNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

While annotations already indicate idempotency (idempotentHint=true), the description adds crucial behavioral nuances: saving to an existing name creates a new version, output_type for code checks is only validated client-side and not sent to the server, and the server-side vocabulary difference (output_data_type) is explained. It also notes the deprecated placeholder, providing transparency beyond what annotations offer.

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?

The description is long but exceptionally well-structured. It leads with the main purpose, then organizes parameter details in an 'Args' block with clear formatting. The extensive placeholder list and code examples are essential for a tool with this complexity, and every section carries meaningful information without repetition.

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?

Given the tool's complexity (8 parameters, model vs code check variants, audio support, placeholder injection), the description is remarkably complete. It covers prerequisites (get_templates), versioning behavior, parameter interdependencies, code class structure, and server-side nuances. Since an output schema is present, the absence of return-value explanation is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by explaining each parameter in depth. It details valid values, dependencies (e.g., prompt_template required for model checks), placeholder semantics for prompt_template, and the expected Python structure for code_contents. This far exceeds the schema's bare type definitions.

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?

The description opens with a specific verb and resource: 'Create or update a quality check by name (upsert).' It clearly distinguishes from siblings like get_check, delete_check, and generate_check by focusing on the creation/update operation. The scope (model, code, audio) is explicit.

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?

The description provides clear context for when to use this tool and when to consult alternatives. It explicitly directs users to get_templates for worked examples before writing prompt_template or code_contents from scratch, and references get_check's 'available_versions' for versioning behavior. It does not explicitly exclude alternative tools like generate_check, but the contextual guidance is strong.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/okareo-ai/okareo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server