Skip to main content
Glama
okareo-ai

Okareo MCP Server

Official
by okareo-ai

List Checks

list_checks
Read-onlyIdempotent

Browse available quality checks grouped by category to find the right evaluation for chat or voice simulations. See each check's name, description, and output type (pass/fail or scored).

Instructions

List available quality checks, grouped by category.

    Returns checks (both built-in and custom) available in your Okareo
    account, organized into `checks_by_category` using the platform's
    `__category:<Category>` tags; checks with no category appear under
    `uncategorized`. Select checks from the category matching your task
    AND modality: voice-specific categories (e.g. voice/audio quality)
    apply to voice simulations, while checks outside voice-specific
    categories are generally useful for both chat and voice. A check
    carrying multiple categories appears under each of them.

    Each check has a name, description, and output_data_type.
    output_data_type uses the server vocabulary: "bool" is a pass/fail
    check and "int" is a scored check — these correspond to output_type
    "pass_fail" and "score" in create_or_update_check and generate_check.
    Use these check names with run_test to evaluate model quality.

    Args:
        limit: Maximum number of checks to return (default 20), applied to
            the total before grouping. Use 0 for no limit.
        all_versions: When false (default), returns only the latest version of
            each check. When true, returns the full version history of every
            check, each entry annotated with its version number.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
all_versionsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description reveals key behavioral details: grouping by `__category:<Category>` tags, handling of uncategorized checks, duplicate entries for multi-category checks, the meaning of output_data_type values ('bool', 'int') and their mapping to output_type, and version behavior controlled by all_versions. This adds significant value beyond the structured annotations.

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?

The description is long but well-structured with clear paragraphs and an Args section. The first sentence captures the core purpose. Each subsequent sentence adds necessary context about grouping, output semantics, and parameters. It is appropriately verbose for the tool's complexity.

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 an output schema present, the description doesn't need to detail return fields, but it still explains the `checks_by_category` organization, uncategorized fallback, and output_data_type semantics. It also covers edge cases like multi-category checks and version history. The tool is fully specified for an agent.

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?

The input schema has no property descriptions, so the description carries the full burden. The Args section thoroughly explains `limit` (default, semantics of 0, application before grouping) and `all_versions` (latest vs full history, version annotation). This exceeds what the schema provides.

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 'List available quality checks, grouped by category', clearly identifying the action (list) and resource (quality checks). It distinguishes itself from sibling tools focused on creating, updating, or deleting checks.

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 guidance on how to choose checks: 'Select checks from the category matching your task AND modality' and explains that voice-specific categories apply to voice simulations. It also directs the user to use check names with run_test, establishing the tool's role in the evaluation workflow. While it doesn't explicitly contrast with sibling tools, the context is sufficient.

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